cisco ace xml gateway migration guide

8/2/2019 Cisco ACE XML Gateway Migration Guide

http://slidepdf.com/reader/full/cisco-ace-xml-gateway-migration-guide 1/36

i

Version 1.0

Cisco ACE XML Gateway(AXG) to Layer 7 GatewayMigration Guide



Copyright © 2005-2011 Layer 7 Technologies Inc.

The Layer 7 Installation and Maintenance Manuals, the Layer 7 Policy Manager User Manual, theLayer 7 Policy Authoring User Manual, the SecureSpan™ XML VPN Client User Manual, and the Layer 7

Enterprise Service Manager User Manual are the copyright of Layer 7 Technologies Inc. All rights

reserved.

SecureSpan and CloudSpan are trademarks of Layer 7 Technologies Inc. (registration pending), and is

protected by law in Canada, the United States, and other countries.

All other trademarks and tradenames belong to their respective owners.

Layer 7 Technologies Inc. reserves the right to change the information in this Manual without notice.

The content in this Manual is confidential. No part of this Manual may be copied, transmitted, or saved

for non-personal purposes without the written permission of Layer 7 Technologies Inc.



i

Contents

List of Figures ............................................. ........................... ........................... ................... ii

List of Tables ....................................................................................................................... ii Chapter One: Introduction ............................................ ........................... ........................... . 1

Background ..................................................................................................................................... 1 About Layer 7 Technologies ........................................................................................................... 1 Why Layer 7? ................................................................................................................................... 1

Chapter Two: Mapping AXG Handlers, Routes, and Service Descriptors ......... ..... ..... ..... .... 3

Introduction ..................................................................................................................................... 3 Understanding Published Services ......................................................................................... 3 Understanding Policies ............................................................................................................ 3

Creating a Virtual Service ............................................................................................................... 4

Request Message Specification ..................................................................................................... 7 Transformation Extensions ............................................................................................................. 9 Response Message Specification .................................................................................................. 9

Chapter Three: Identity and Access Control ....................................... ........................... ... 11

Chapter Four: Using the AXG to L7 Migration Utility ............................................. ............ 13

Technical Overview ....................................................................................................................... 13 Dependencies ................................................................................................................. 13

Installing the Migration Utility ....................................................................................................... 13 Preparation ............................................................................................................................. 14

Using the Migration Utility ............................................................................................................. 15

Using a Browser ..................................................................................................................... 15

Using the Command Line ...................................................................................................... 17 Migration Utility Specifics ............................................................................................................. 18 Sample Policy After Migration ...................................................................................................... 23

Chapter Five: Migration Methodology ......................... ........................... .......................... 25

Step 1: Capture requirements ............................................................................................... 25 Step 2: Deploy the Layer 7 Gateway ..................................................................................... 25 Step 3: Install the AXG migration utility ................................................................................ 25 Step 4: Export target AXG configuration ............................................................................... 26 Step 5: Run the Migration Utility with the AXG export.......................................................... 26 Step 6: Review services created ........................................................................................... 26 Step 7: Test ............................................................................................................................ 26 Step 8: Migrate to production ............................................................................................... 26 Step 9: Monitor and report .................................................................................................... 26

Chapter Six: Additional Information ......................... ........................... ........................... ... 27 Contacting Layer 7 Technologies ................................................................................................. 27 Other Layer 7 Resources .............................................................................................................. 27

User Documentation .............................................................................................................. 27



Contents

ii

Support Portal ........................................................................................................................ 28 Solutions Architects ............................................................................................................... 28 Professional Services ............................................................................................................ 29 Sample Policies ...................................................................................................................... 29

Index ................................................................................................................................. 31

List of FiguresFigure 1: Types of services you can publish ......................................................................................... 5 Figure 2: Allowing requests for operations not in the WSDL ............................................................... 5 Figure 3: Setting a custom resolution path .......................................................................................... 6 Figure 4: Associating a port with a specific service .............................................................................. 7 Figure 5: Manage Global Resources dialog .......................................................................................... 8

Figure 6: Compare Expression assertion .............................................................................................. 8 Figure 7: Apply XSL Transformation assertion .......... ........... ........... .......... ........... .......... ........... .......... .. 9 Figure 8: Route via HTTP(S) assertion ................................................................................................ 10 Figure 9: Using the Access Control assertions ................................................................................... 11 Figure 10: Accessing the migration utility from a browser ................................................................ 15 Figure 11: Authenticating a user ......................................................................................................... 15 Figure 12: Cisco AXG configuration export ......................................................................................... 15 Figure 13: Migration results ................................................................................................................ 16 Figure 14: Reviewing global resources ............................................................................................... 17 Figure 15: Using the cURL command ................................................................................................. 17 Figure 16: Review migration results (command line) ........................................................................ 17

Figure 17: Sample policy after migration .......... .......... ........... .......... ........... .......... ........... .......... ......... 23

List of TablesTable 1: Contacting Layer 7 Technologies .......................................................................................... 27 Table 2: Layer 7 Documentation ......................................................................................................... 27



Cisco AXG Gateway to Layer 7 Gateway Migration Guide, v1.0

Chapter One: Introduction 1

Chapter One: Introduction

BackgroundOn August 1, 2010, Cisco announced the end-of-sale and end-of-life dates for the

Cisco ACE XML Gateway:http://www.cisco.com/en/US/prod/collateral/contnetw/ps5719/ps7314/end_of_lif

e_c51_609816.html

A couple of important dates to note:

• As of January 30, 2011, the Cisco ACE XML Gateway is no longer for sale from

Cisco.

• Cisco will no longer provide maintenance releases or bug fixes after January 30,

2012.

Additional details and other important dates are available from Cisco at the link

above.

About Layer 7 TechnologiesLayer 7 is a leading provider of API security and governance for SOA, web- and cloud-

oriented integration. The Layer 7 SecureSpan Gateway helps organizations control

how they expose their data and applications to other divisions, partners, third-party

developers and cloud services. Layer 7 customers include leading companies in the

insurance, banking and telecom industries, as well as large public sector

organizations.

Why Layer 7?Layer 7 offers a proven migration path for existing users of the Cisco ACE XML

Gateway. We have helped many customers move their Cisco policies to the fully-

supported, industry-leading Layer 7 SecureSpan Gateway. The Layer 7 solution

enables customers to:

• Choose the form factor that is best suited to their deployment environment

• The Layer 7 SecureSpan Gateway is available in multiple form factors:

hardware appliance, software, virtualized appliance (VMWare, Amazon

Machine Image, Xen, etc.)

http://www.cisco.com/en/US/prod/collateral/contnetw/ps5719/ps7314/end_of_life_c51_609816.html








2 Chapter One: Introduction

• Quickly create and more easily maintain new policies

• The Layer 7 SecureSpan Gateway includes a Policy Manager that provides adrag-and-drop editor to compose and maintain policies to shared services.

• These policies serve to:• Establish trust and identity sources with existing infrastructure

• Implement authentication & authorization

• Ensure message confidentiality, and data integrity

• Enforce SLA conformance and service availability

• And much more …

• The Layer 7 SecureSpan Gateway supports a wide variety of built-in policy

assertions, as well as an extensible custom assertion API, to handle anypolicy requirement that an organization may have.

• Migrate policies according to their own project schedules

• The Layer 7 SecureSpan Gateway can be deployed alongside existing CiscoACE XML Gateways allowing customers to gradually migrate policies, thereby

minimizing any disruptions to services.




Chapter Two: Managing AXG Handlers, Routes, and Service Descriptors 3

Chapter Two: Mapping AXG Handlers, Routes,

and Service Descriptors

IntroductionThis chapter describes how AXG concepts such as virtual service, handler, route,

service descriptors map to the Layer 7 Gateway solution. The following are two

fundamental Gateway equivalents:

• published services

• policies

Understanding Published ServicesIn the Layer 7 Gateway, a published service is similar to a virtual service in the AXG. A

published service contains properties that are used by the Gateway at runtime to

determine which service an incoming message should use. A key property of a

published service is a policy . Each published service can have only one policy, but apolicy can include other policies.

Understanding PoliciesThe Layer 7 Gateway is a Policy Enforcement Point. At runtime, the Layer 7 Gateway

receives messages and applies applicable policies as it processes the messages. ALayer 7 Gateway policy contains policy assertions that are organized in a logical tree

structure that is evaluated sequentially based on the outcome of previous assertions.

The Layer 7 Policy Manager provides a graphical environment to make policy

construction as easy as drag-and-drop. But at their core, policies are simply XML files

that you can share, export, import, or manipulate programmatically.

Layer 7 policies define the behaviour to be used for message validation, access

control, routing, transformation, rate limiting, encryption, signatures, and any other

aspect of runtime message processing.

There are five types of policies:

• Service Policy: This is the main policy associated with a published service. Each

published service has one and only one service policy. For more information, see

Working with Service Policies in the Layer 7 Policy Authoring User Manual .

• Policy Fragment: This is a policy that can be inserted into other policies in any

published service. A policy fragment can be thought of as a boilerplate to save




4 Chapter Two: Managing AXG Handlers, Routes, and Service Descriptors

time and help maintain consistency when authoring a policy. For more

information, see Working with Policy Fragments in the Layer 7 Policy Authoring User Manual .

• Global Policy: These are policies that are always run before or after every service

policy. They can be used to configure global behaviours such as auditing or

logging. Similar to policy fragments, global policies can help ensure consistency

and reduce errors. For more information, see Working with Global Policies in the

Layer 7 Policy Authoring User Manual .

• Audit Sink Policy: This is a special policy that can be configured to direct audit

messages to an external database, message queue, or other location. It is

created by enabling the audit sink. For more information, see Working with the Audit Sink Policy in the Layer 7 Policy Manager User Manual .

• Internal Use Policies: This is a special preconfigured policy designed for a special

purpose. Currently, there are three prepackaged internal use policies. For more

information, see Working with Internal Use Policies in the Layer 7 Policy Authoring User Manual .

Creating a Virtual ServiceThe Layer 7 Gateway distinguishes between two types of published services:

• SOAP Web Services

• REST, Web API, or Other Services.

The main distinction between these two types of services is that the first one has a

WSDL property while the second does not. The WSDL document associated with a

SOAP Web Service is used for message classification at runtime and to return WSDL

documents to front-end requestors. Note that the Layer 7 Gateway can still process

SOAP messages from a published service of type REST, Web API, or Other Service.





Figure 1: Types of services you can publish

As AXG does not easily process existing WSDLs when creating virtual services, it is

common for AXG users to create a virtual service for a SOAP service but without using

the WSDL of that service. To achieve the same approach in the Layer 7 Gateway, you

can use either Publish REST, Web API or Other Service or Create WSDL , then

complete the wizard without providing WSDL elements. This will leave you with a

“placeholder” WSDL associated with the published service. To prevent resolution

failures caused by this placeholder WSDL, ensure that the [ Allow requests intendedfor operations not supported by the WSDL ] check box is selected in the service

properties:

Figure 2: Allowing requests for operations not in the WSDL





The exposed local path of a virtual service is specified in the service properties in the

Custom resolution path field as shown in Figure 3. Note that you can assign

resolution paths that include the ‘ * ’ wildcard character to allow one service to be

resolved for a number of different entry point URIs. This is especially relevant to REST

services but can also be useful in grouping together SOAP entry points in one virtualservice that should be processed using similar rules. These are examples of valid

custom resolution paths:

/servicename/* /*/something

Figure 3: Setting a custom resolution path

The resolution path is only one of the criteria used by the classification process to

determine which virtual service to use for an incoming message. The Gateway alsouses the following to resolve the service:

• service OID

• URI (e.g., custom resolution path)

• SOAPAction

• SOAP payload namespace

If more than one service has an identical combination of these four criteria, then a

resolution conflict occurs. This classification behaviour is customizable.

• To learn more about the classification logic used by the Gateway, please refer to

Understanding the Service Resolution Process in the Layer 7 Installation andMaintenance Manual.

• To learn how to customize the classification logic, refer to Managing ServiceResolution in the Layer 7 Policy Manager User Manual.

Note that the port that a service receives requests on is not a property of the service

itself. Instead, ports are globally declared at the Gateway level. If a port is configured

to receive service message traffic, all published services on the Gateway have the

ability to receive message from this port by default. You can change this default

behaviour in two ways:





In the [Advanced] tab of the Listen Port Properties, you can create a fixed association

between the port and a specific service.

Figure 4: Associating a port with a specific service

In the service policy, you can validate which port the request came from and enforce

that a specific port be used. This lets you restrict the use of a specific service from

one or many ports without reserving a port to a single service.

For more information on publishing virtual services using the Layer 7 Policy Manager,

see Chapter 5, “Working with Services” in the Layer 7 Policy Manager User Manual .

Request Message SpecificationHow a request message is validated by the Layer 7 Gateway is determined by the

policy associated with the service. If a WSDL document is associated with the

service, then validations for SOAP version, SOAPAction, and SOAP body message

name and URI are performed automatically. If no WSDL document is associated with

a service or if additional validations are required, you can add the appropriate

validation assertions using the Layer 7 Policy Manager.

For example, to validate an XML Schema, use the Validate XML Schema assertionand set the target message to “Request”. XML Schemas that have dependencies canbe imported from file or URL and their dependencies are automatically imported in

the global resources table of the Layer 7 Gateway. The links between those global

resources are automatically resolved and can be viewed using the Manage GlobalResources task in the Policy Manager.





Figure 5: Manage Global Resources dialog

You can also use context variables to validate properties of the incoming request. For

example, to validate that the SOAPAction HTTP header of the incoming request has a

specific value, you can use the variable ${request.http.header.soapaction} in theCompare Expression assertion as illustrated below.

Figure 6: Compare Expression assertion

In Figure 6, “MySOAPAction” is the SOAPAction header value that is being validated

against the incoming request. Consult the Layer 7 Policy Authoring Manual for

additional information on validating any aspect of requests and responses.





Transformation ExtensionsTransformation extensions on both request and response messages are achieved in

policy. For example, to transform a request message, you would add the Apply XSLT Transformation assertion, specify the XSL transformation to apply, and thenassociate it with the request. The same can be done to a response message by

adding the assertion after a routing assertion (doing this normally populates the

response context).

Figure 7: Apply XSL Transformation assertion

Response Message SpecificationInteraction with the endpoint of a backend service is also described in policy through

one of the routing assertions. You use a routing assertion to send a message to that

endpoint (typically the incoming request message) and optionally receive a responsemessage from that endpoint. For example, for a backend HTTP-based service, you

would use the Route via HTTP(S) assertion. In the assertion properties, you will define

the backend target to communicate with: URL, timeout values, last mile security,

injection of additional HTTP headers, etc. You can also specify multiple endpoints in

the properties and set the Gateway to load-balance between those backendendpoints.





Figure 8: Route via HTTP(S) assertion

Once this assertion is executed, the transaction context has a response and you can

add validations to the response messages (for example, using the Validate XMLSchema assertion). All assertions located below the routing assertion in a policy will

have access to the response message for validation purposes.




Chapter Three: Identity and Access Control 11

Chapter Three: Identity and Access Control

The Layer 7 Gateway is configured with one or more identity providers that can be

used to control access to services based on the requestor’s identity. The built-in

Internal Identity Provider (IIP) can be used to manage information about identities

such as shared secrets, certificates and attributes.

In addition to the IIP, you can use the Layer 7 Policy Manager to configure external

identity providers using LDAP and PKI. For more information, refer to the following

topics in the Layer 7 Policy Manager User Manual :

LDAP Identity Providers

Federated Identity Providers

Also available from Layer 7 are custom plug-in modules for proprietary Identity and

Access Management solutions such as Oracle Access Manager, CA/NetegritySiteMinder, OpenSSO, and more. For more information on these, please contact

Layer 7.

To control access to a service or service operation, use the assertions from theAccess Control category of the Policy Manager. These assertions allow you to specify

the access control mechanism, which identity provider to use, test group

memberships, test identity attributes to use, etc. You can combine these assertions

to achieve specific behaviours based on different identity attributes as illustrated

below.

Figure 9: Using the Access Control assertions

For more information, see Chapter 4, “Access Control Assertions” in the Layer 7Policy Authoring User Manual.




12 Chapter Three: Identity and Access Control




Chapter Four: Using the AXG to L7 Migration Utility 13

Chapter Four: Using the AXG to L7 Migration Utility

Layer 7's Cisco AXG Migration Utility can automate some migration of Cisco AXG

configuration to the Layer 7 Gateway. Some manual configuration of the Gateway will

still be necessary after running the utility.

The Cisco AXG Migration Utility can be customized to meet a broad range of customer

needs. Please contact Professional Services at Layer 7Technologies to discuss your

specific Cisco AXG configuration and migration requirements.

Technical OverviewThe migration utility is deployed as a service on the Gateway, with a migration policy

that is imported to the service. The policy publishes a web form that can be used to

upload an export of Cisco AXG configuration to the service. Exports can also be

posted to the service from the command line (e.g., using cURL, or a similar command

line utility). The policy parses the uploaded export and uses the Gateway

Management Service to create Gateway service proxies for each Cisco AXG virtual

service (i.e., a handler and one or more related service descriptors) contained in the

export. The policy also imports any XML schemas contained in the Cisco AXG exportto the Gateway’s global resource repository.

The Gateway service proxies that are created will have active policies that include

functional policy assertions that directly support Cisco AXG capabilities configured in

the export. The policies will also include informational comments that describe the

migrated virtual services and actionable comments that describe configuration that

may still need to be done.

Dependencies

The migration utility requires the For Each Loop modular assertion, which is availablefrom Layer 7 Technical Support.

Installing the Migration Utility1. Contact Layer 7 Technical Support for the For Each Loop modular assertion and

Cisco AXG Migration Utility . This can be done via email: [email protected] .

2. Deploy the For Each Loop modular assertion to the target Gateway.

a. Use SFTP to move the For Each Loop assertion to the target Gateway as the

ssgconfig user.




14 Chapter Four: Using the AXG to L7 Migration Utility

b. Using a privileged shell, copy the For Each Loop assertion from the

/home/ssgconfig directory to the /opt/SecureSpan/Gateway/runtime /modules/assertions directory. For more information on the privileged shell,

see Using the Privileged Shell in the Layer 7 Installation and Maintenance

Manual .

c. Change the ownership of the For Each Loop assertion in the assertions

directory with this command:

c h o wn l a y e r 7 . l a y e r 7 *

d. Restart the Gateway process with this command:

s e r v i c e s s g r e s t a r t

3. Publish the Gateway Management Service on the target SSG.

a. Connect to the target Gateway using the Layer 7 Policy Manager.

b.

Start the Publish Internal Service Wizard . For information on the differentways to start this wizard, see Publish Internal Service Wizard in the Layer 7Policy Manager User Manual.

c. Choose Gateway Management Service from the drop-downlist and then click

[Finish ].

4. Publish a REST service on the target Gateway.

a. Start the Publish REST, Web API, or Other Service Wizard. For information on

the different ways to start this wizard, see Publish REST, Web API, or Other

Service Wizard in the Layer 7 Policy Manager User Manual.

b. In the Service Name field, enter AXG Migration .

c. In the Gateway URL field, enter axg/migration .

d. Click [ Finish ] to close the wizard.

5. Import the Cisco AXG Migration Utility policy to the published REST service.

a. On the Policy Editor toolbar, click .

b. Navigate to the Cisco AXG Migration Utility policy that you received from

Layer 7 Technical Support.

c. On the Policy Editor toolbar, click .

PreparationIn preparation for using Layer 7's Cisco AXG Migration Utility, you should export and

uncompress your Cisco AXG configuration. The current version of the utility wastested against exports of entire Cisco AXG sub-policies containing multiple handler

groups and handlers.

Note: Do not select the option to export configuration as WS-Policy.





When exporting Cisco AXG configuration, a file with a .ppf extension is created. This is

a compressed file that contains XML. This file must be uncompressed using an

industry standard compression utility (for example, 7-Zip).

Using the Migration UtilityThe Cisco AXG Migration Utility can be run from either a web browser or from a

command line.

Using a Browser1. In the browser, navigate to your migration service on the target Gateway.

Figure 10: Accessing the migration utility from a browser

2. Provide basic authorization credentials for an administrative user in the target

Gateway’s Internal Identity Provider,

Figure 11: Authenticating a user

3. Browse for the uncompressed Cisco AXG configuration export prepared above.

Figure 12: Cisco AXG configuration export





4. Click {Submit ] and review the migration results:

Figure 13: Migration results

5. Review the service proxies associated policies that were created by the migration

(click on the toolbar, if necessary).

6. Review the global XML schema resources that were imported by the migration,

using the Manage Global Resources task. For details, see Managing GlobalResources in the Layer 7 Policy Authoring User Manual.





Figure 14: Reviewing global resources

Using the Command Line1. Open a command shell (for example, the Privileged Shell from the Gateway main

menu—see Using the Privileged Shell in the Layer 7 Installation and Maintenance

Manual).

2. Navigate to the directory containing the uncompressed Cisco AXG configuration

export prepared above.

3. Using cURL (or a similar command line utility), execute the following command

(or a similar command):

c u r l - k - u a d mi n : 7 l a y e r - - d a t a - b i n a r y @s a mp l e _ e x p o r t . x ml - H " Co n t e n t -T y p e : t e x t / x ml " h t t p s : / / d e v . l 7 t e c h . c o m: 8 4 4 3 / a x g / mi g r a t i o n >r e s u l t s . h t ml

Figure 15: Using the cURL command

4. Review the migration results (piped to file with the above command).

Figure 16: Review migration results (command line)





5. Review the service proxies associated policies that were created by the migration

(click on the toolbar, if necessary).

6. Review the global XML schema resources that were imported by the migration,

using the Manage Global Resources task. For details, see Managing GlobalResources in the Layer 7 Policy Authoring User Manual

Migration Utility SpecificsThe following is a detailed description of what the Cisco AXG Migration Utility will do:

1. Extract and load each XML schema found in the Cisco AXG export to the

Gateway’s global resource repository.

• The source URL (a.k.a. System ID) will be set to: axg/<AXG XSD bundlename>/<AXG original file name>/<index position in AXG XSD bundle>

Note: The Layer 7 Gateway expects that every global XML schemaresource has a unique target namespace. If the Cisco AXG exportcontains redundant XML schemas, you will need to manually resolvetarget namespace conflicts using the Manage Global Resources taskafter migration is complete. Alternatively, you may contact Layer 7 tocustomize the migration utility to only import one XML schema for agiven target namespace.

2. Create a SOAP or REST proxy for each handler found in the Cisco AXG export

using these settings:

• Name set to: axg_ <AXG handler name>

• Proxy disabled

• URI set to: <AX G handler transport URI>

• Allowed HTTP methods set to: <AXG handler transport method>

• For a SOAP proxy, the WSDL is set to a default WSDL as a place holder for

when an actual WSDL is made available for the service

• For a SOAP proxy, allow requests intended for operations not supported by

the WSDL is selected

• For a SOAP proxy, the SOAP version is set to: <AXG handler transport SOAP

version>

Note: Many Cisco AXG environments contain a handler per each distinctoperation of a service. By comparison, the Layer 7 Gateway normallycreates one proxy and conditional policy for all operations of a service.When replacing Cisco AXG, it is recommended that you considercollapsing the many proxies per handler that are created by themigration utility to fewer proxies per service.





3. Create an active policy for each proxy.

a. Informational comments will be added for:

• AXG handler's sub-policy

• AXG handler's group

• AXG handler's name

• AXG handler's default service descriptor's name

• Whether the AXG handler has branched routing to multiple service

descriptors (i.e., dynamic routing)

b. Actionable comments (i.e. TODO comments) will be added for:

• AXG handler's default log level

• Name of any access provisions attached to the AXG handler

• Whether inbound request and/or outbound response schema validation

exists

• Whether dynamic routing exists

• Whether dynamic route selectors must be configured

• Whether dynamic route stop processing assertions must be removed

• Whether HTTP route passwords must be set

c. If the AXG handler is set to log request messages on error:

i. An Audit Messages in Policy assertion is added to the beginning of the

policy (after comments):

• Audit level is set to WARNING

• Save request = Always

ii. An Audit Messages in Policy assertion will be added to the end of the

policy:

• Audit level is set to INFO

• Save request = Never

d. For a SOAP proxy, policy assertions will be added to check the SOAP version

of the request.

Note: Once a valid WSDL has been added to the SOAP proxy, theseverifications are done automatically and this part of the policy is nolonger necessary.

e. For a SOAP proxy, policy assertions will be added to check the SOAP action of

the request.





Note: Once a valid WSDL has been added to the SOAP proxy, theseverifications are done automatically and this part of the policy is nolonger necessary.

f. If the AXG handler is configured to perform XML schema validation of theinbound request:

i. Informational comments will be added for:

• The name of the element to be schema validated (normally theroot element of the message body).

• The namespace of the element.

• The name of the AXG XSD bundle resource containing the rootschema and dependencies.

• The original file name of the AXG root schema.

ii. A Validate XML Schema assertion will be added:

• Targeting the request message

• Configured to select the previously uploaded root schema from

the Gateway’s global resource repository.

Note: The migration utility does not currently check for outboundrequest schema validation configured in one or more of the AXGhandler's associated service descriptors. This capability can beadded through customization of the migration utility.

g.

Route via HTTP to backside service(s).i. If the AXG handler included branched routing to multiple service

descriptors:

a) Conditional logic folders will be added to evaluate routing toeach non-default service descriptor.

1) Informational comments will be added for the name of the

AXG service descriptor.

2) Actionable comments will be added for :

• The AXG route's selector configuration.

• Whether HTTP route passwords must be set.

• To remove the Stop Processing assertion.

3) A Stop Processing assertion is added to ensure this route is

not selected until appropriate selector logic has beenadded to policy.





4) An assertion will be added to make sure that routing has

not already been attempted and failed for an earlier route

destination.

5) A Route via HTTP(S) assertion will be added configured as

follows:

• Target URL set to the AXG service descriptor's back

side endpoint

• Connection and read timeouts set to the AXG service

descriptor's timeout

• Basic authorization user name set, if set in Cisco AXG

• Pass-through of all HTTP request headers, if set in

Cisco AXG

b)

If no non-default service descriptor was selected, requests willbe routed based on the default service descriptor's AXG

configuration.

1) An assertion will be added to make sure that routing has

not already been attempted and failed for an earlier routedestination.

2) A Route via HTTP(S) assertion will be added configured as

follows:


side endpoint





Cisco AXG

ii. Otherwise requests will be routed based on the default service

descriptor's AXG configuration.

a) A Route via HTTP(S) assertion will be added configured as

follows:


side endpoint









Cisco AXG

h. If the AXG handler is configured to perform XML schema validation of the

outbound response:

i. Informational comments will be added for:

• Name of the element to be schema validated (normally the root

element of the message body)

• Namespace of the element

• Name of the AXG XSD bundle resource containing the root

schema and dependencies

• Original file name of the AXG root schema

ii. A Validate XML Schema assertion will be added configured as follows:

• Targets the response message.

• Configured to select the previously uploaded root schema from

the Gateway’s global resource repository

Note: The migration utility does not currently check for outboundrequest schema validation configured in one or more of the AXGhandler's associated service descriptors. This capability can beadded through customization of the migration utility.





Sample Policy After MigrationThe following is an example of a policy after the Cisco AXG Migration Utility has run:

Figure 17: Sample policy after migration




Chapter Five: Migration Methodology 25

Chapter Five: Migration Methodology

The specific methodology used to migrate an AXG deployment to the Layer 7 Gateway

is highly customizable and can be tailored to address the current use of AXG, new

use cases moving forward, and additional components that interact with the

Gateway. The following is a suggested methodology that you can use as a starting

point.

Step 1: Capture requirementsBefore you start, capture the existing behavior of the AXG devices. Some questions

you might consider:

• What services are they processing?

• What are the inputs/outputs?

• What throughput are you designed to handle?

• What external components must be integrated (LDAP, Databases, IAM, Syslog,

BI, etc)?

Described environments (Development, Staging, Production). Any new requirements

should also clearly be defined.

Step 2: Deploy the Layer 7 GatewayDeploy the Layer 7 Gateway in each environment:

• Configure network

• Configure integration with external components such as LDAP, Queue managers,

Databases, IAM, Anti-virus, etc).

• Provision administrative accounts

• Import trusted certificates, private keys

Please refer to the Layer 7 Installation and Maintenance Manual for deploymentinstructions.

Step 3: Install the AXG migration utilityThe Layer 7 Gateway solution has its own mechanism for the migration of service and

policy configurations across environments. For this reason, the AXG-L7 migration




26 Chapter Five: Migration Methodology

utility is normally installed only on the first target environment (typically a

development or staging environment).

Once the AXG configuration is migrated and tested on that environment, you can use

the Layer 7 Enterprise Service Manager to promote these services to other

environments such as production.

Step 4: Export target AXG configurationSelect the handlers that you want to migrate at this stage and export them as PPS

files.

Step 5: Run the Migration Utility with the AXGexport

If you only have a single PPS to import, you should use the web interface to feed it tothe migration utility. If you have a large number of PPS files, you can script the import

to automate this step.

Step 6: Review services createdReview created services placeholders in the Layer 7 Gateway. Review comments

produced by the utility, tweak service properties and policies as appropriate. You can

also adjust policies so that repetitive logic is moved to policy fragments to optimizemaintainability. Behaviour that is always applied can be moved to global policies. If

the number of services makes this step too tedious, consider adjusting the style

sheet used by the migration utility so that is done automatically.

Step 7: TestAt this point, you are ready to make end-to-end testing in your development

environment. Use the Layer 7 monitoring and auditing to capabilities to verify that the

defined behavior is met. If you need to make adjustments to the migration style

sheet here, you can go back to step 5. You may proceed to the next step once all yourtests come back positive.

Step 8: Migrate to productionUsing the Enterprise Service Manager, migrate the new services and policies to the

production environment.

Step 9: Monitor and reportMonitor traffic, produce reports and verify that key performance indicators stay within

defined thresholds.




Chapter Six: Additional Information 27

Chapter Six: Additional Information

Contacting Layer 7 TechnologiesAt Layer 7 Technologies, our commitment to exceptional service culminates in the

advanced level of technical support that we provide for our Layer 7 products.

Table 1: Contacting Layer 7 Technologies

Sales [email protected]

Support [email protected]

Web www.layer7tech.com

Other Layer 7 ResourcesLayer 7 Technologies provides a wealth of resources to help you:

• User Documentation

• Support Portal

• Solution Architects

• Professional Services

• Samples

User DocumentationThe Layer 7 products are supported by the following documentation:

Table 2: Layer 7 Documentation

Documentation Target Product(s) Format(s) Description

Layer 7 Installation andMaintenance Manual

Gateway, XMLVPN Client, andPolicy Manager

PDF and print Installation and upgrade information forthe Layer 7 products, including Gatewaymaintenance, operations, monitoring, andtroubleshooting information andinstructions.

There are separate editions of this manualfor the appliance (including virtual) andsoftware Gateways.




28 Chapter Six: Additional Information

Documentation Target Product(s) Format(s) Description

Policy Manager UserManual

Policy Manager PDF and print Comprehensive user instructions for thePolicy Manager.

Policy Manager HelpSystem

Policy Manager Program-based.Accessed fromthe PolicyManager [Help]menu.

Comprehensive user instructions for thePolicy Manager.

SecureSpan XML VPNClient User Manual

SecureSpan XMLVPN Client

PDF and print Comprehensive user instructions for theSecureSpan XML VPN Client.

SecureSpan XML VPNClient Help System

SecureSpan XMLVPN Client

Program-based.Accessed fromthe XML VPNClient [Help]

menu.

Comprehensive user instructions for theSecureSpan XML VPN Client.

Custom AssertionInstallation Manual

Gateway PDF Instructions for installing and configuring the optional custom assertion packages onthe Gateway. User instructions for thecustom assertions are provided in thePolicy Manager documentation.

Read Me file Gateway, XMLVPN Client, andPolicy Manager

Text file on theInstallation CD.

Release-based information. Also includes acopy of the End User license agreement.

Secure ImplementationGuide

All PDF Describes how to use the Layer 7 productsuite to comply with version 2.0 of thePayment Card Industry Security StandardsCouncil’s Data Security Standards (PCIDSS).

Support PortalThe Layer 7 support portal can be used to download virtual appliance images,

software installers, documentation, and other resources. You can access the Layer 7

support portal via http://layer7tech.com/portal/ .

Solutions ArchitectsContact your local Solutions Architect for advice on how to proceed with your AXG

replacement, to answer any technical questions about the capabilities of the Layer 7

Gateway solution, and for assistance with a pilot or POC project. You can reach your

local solutions architect by emailing [email protected] .

http://layer7tech.com/portal/



mailto:[email protected]








Chapter Six: Additional Information 29

Professional ServicesThe Layer 7 Professional Services engineers will assist you in the implementation

phase of your Layer 7 Gateway solution and for specialized training engagements.

Layer 7 Professional Services can be contacted via [email protected] .

Sample PoliciesThrough the Layer 7 support engineers and professional services, you can get a

number of sample policies and scripts to speed up the implementation of any Layer 7

Gateway implementation projects. For more information, please [email protected] .











30 Chapter Six: Additional Information




Index 31

Index

A Access control .................................. 11Audit sink policy ................ .......... ........ 4

B Browser access to utility .......... ........ 15

C Command line access to utility ....... 17Contact Layer 7 ................................ 27Creating

virtual service .......... ........... .......... ... 4

G Global policy ......... ........... .......... .......... 4

I Identity control ................................. 11Internal use policy ........... .......... .......... 4

L Layer 7 Resources

professional services ................... 29sample policies ............................ 29solutions architects ..................... 28support portal ............................... 28user documentation .................... 27

Layer 7 Technologiesabout ............................................... 1contacting ..................................... 27resources ...................................... 27why us? ............................................ 1

M Migration Utility

installing ....................................... 13methodology ................................. 25preparation ................................... 14sample policy ............................... 23specifics ........................................ 18technical overview ....................... 13

using .............................................. 15browser ..................................... 15command line .......... .......... ....... 17

P Policies ................................................ 3

audit sink policy ......... ........... .......... 4global policy .................................... 4internal use policy .......................... 4policy fragment ............................... 3service policy .................................. 3

Policy fragment ................................... 3Professional Services ................. ...... 29

Published services ............................. 3R Request message specification ........ 7Resources ......................................... 27Response message specification ...... 9

S Sample Policies ................................ 29Sample policy after migration .......... 23Service policy ...................................... 3Solutions Architects ......................... 28Specify

request message ............................ 7

response message ......................... 9Support Portal .................................. 28

T Transformation extensions ................ 9

U Understanding

policies ............................................ 3published services.......................... 3

User Documentation ................ ........ 27

V Virtual service ..................................... 4

cisco ace xml gateway migration guide

Documents