10.2 Planning the Migration

Planning the migration is a three-step process.

10.2.1 Possible Migration Strategies

The following sections describe several types of iChain configurations and propose a migration strategy for each. These configurations build upon each other. They assume that you will first set up Access Manager independent of your iChain installation and then progressively configure Access Manager to assume responsibility for protecting iChain resources. Such a configuration requires the users to authenticate to both iChain and to Access Manager while the process takes place. If you need to preserve single sign-on while resources are migrated to Access Manager, you can use the phased migration strategy before migrating any important protected resources. If your iChain configuration includes L4 switches for fault tolerance and load balancing, you need to consider the third configuration, which describes how to cluster the various Access Manager components behind an L4 switch. You might also need to set up Access Manager in a staging environment, and when everything is working, transition the machines into your production environment. The staged migration describes some of the issues with this approach.

A Simple Migration

A simple migration works well in the following network environment:

  • You use iChain to protect a few Web servers with only one or two applications each.

  • The policies that control single sign-on and access are simple.

  • If all resources cannot be moved at the same time, you have no problems with requiring your users to authenticate to both iChain and Access Manager:

    • They can log in to iChain for the resources you haven’t migrated.

    • They can log in to Access Manager for the resources you have migrated.

You might also use this type of migration when you want to use Access Manager to protect new resources and applications and to use iChain to protect already configured resources. Older resources can be migrated, as time permits, from iChain to Access Manager.

In this type of migration, you set up the Access Gateway independent of iChain. Your network configuration would look similar to the following:

Figure 10-1 Network Setup for a Simple Migration

In this scenario, when a user requests a resource that has not been migrated, the user is prompted to log in to iChain. When a user requests a resource that has been migrated to Access Gateway, the user is prompted to log in to the Identity Server. Both logins are required until all resources have been migrated and iChain has been removed.

Requirements

The following requirements assume that you have users outside your firewall that need access to the protected Web servers.

  • The Access Gateway needs its own public IP address and DNS name, and the Access Gateway needs to be accessible through your firewall.

  • The Identity Server needs its own public IP address and DNS name, and it needs to be accessible through your firewall.

  • You need new hardware for the Access Gateway machine and the Identity Server. For more details, see Installation Requirements.

  • You need to configure your firewall to allow access to the Access Manager components. See Setting Up Firewalls in the Novell Access Manager 3.0 SP4 Setup Guide.

Major Tasks

A Phased Migration

You can use a phased migration if iChain is protecting multiple resources that require Form Fill policies, SSL methods, and access control methods. While migrating these more complex resources, we recommend that you set up both iChain and Access Manager on your network. This allows an incremental migration of your resources. When your users access a migrated resource, they are directed to the Access Gateway, and they shouldn’t notice any difference.

Your users will have the same iChain experience with your resources until you have successfully migrated all of them to Access Manager. You can then disable the iChain system. The only differences users should experience are Access Manager login and error pages rather than iChain login and error pages.

Figure 10-2 illustrates the network layout for this type of migration.

Figure 10-2 Network Setup for a Phased Migration

The phased migration uses iChain for authentication and single sign-on to the Identity Server. To do this, you configure the Identity Server to be a restricted resource of iChain, and you configure the Access Gateway to trust the Identity Server as its identity provider. The Access Gateway communicates with the Identity Server to obtain authentication credentials before allowing access to any resources it is protecting.

For resources that haven’t been migrated, the browsers are directed to iChain to fulfill the Web resource requests. iChain prompts the user for login credentials, validates them, and if valid, grants access to the requested resource.

As you migrate resources, the Access Gateway is configured to use the same DNS names as you used for the iChain accelerators. As long as your DNS server is configured to resolve these DNS names to the iChain machine, your users access the resources through iChain. When you have completed the migration for one DNS name and have tested the results, you modify the record on the DNS server to resolve the DNS name to the IP address of the Access Gateway, rather than iChain. Your users are redirected to Access Gateway, and they shouldn’t notice any differences. Figure 10-3 illustrates this flow. The dotted lines represent redirected requests.

Figure 10-3 The Flow of a Client Request to a Migrated Resource

  1. The user sends a request for a protected resource that has been migrated to the Access Gateway. The DNS server directs the request to the Access Gateway.

  2. The Access Gateway determines that the user needs to be authenticated and directs the request to the Identity Server. Because the Identity Server is a restricted resource of iChain, the request is redirected to iChain

  3. iChain prompts the user for login information and validates the user’s login credentials with the LDAP user store.

  4. To enable single sign-on, iChain uses OLAC to forward a basic authentication header to the Identity Server, and the Identity Server is configured to accept the basic authentication header instead of a name and password for authentication. (Form Fill could be used instead of OLAC and basic authentication.)

  5. The Identity Server validates the name and password with the LDAP user store.

  6. The Access Gateway is sent the credential artifact.

  7. The Access Gateway sends the artifact to the Identity Server and uses it to retrieve the authentication information and policy information specific to that user.

  8. If the user’s credentials match the requirements, the Access Gateway grants the user access to the protected resource.

Requirements and Restrictions

Hardware: This migration strategy has the following minimum hardware requirements:

  • Identity Server machine

  • Access Gateway machine

  • Administration Console machine (unless the Administration Console is installed with the Identity Server)

The Identity Server and the Access Gateway should be installed on separate machines.

IP Addresses: This migration strategy has the following IP address requirements:

  • A new public DNS name and IP address for the iChain accelerator that is protecting the Identity Server.

  • A DNS name and IP address for the Identity Server. During migration, the IP address and DNS name could be an internal address and name, accessible only behind your firewall.

  • One new public IP address for the Access Gateway.

With this type of configuration, you can test your migrated resources, change the DNS name of the migrated resources to resolve to the Access Gateway, and not modify your iChain configuration. As soon as the DNS name change is propagated, users start accessing the resource through the Access Gateway. If you encounter problems, you can change the record on the DNS server to resolve to the iChain machine while you fix the problems.

Restrictions: This migration strategy has the following restrictions:

  • If you are using path-based multi-homing, you must migrate all accelerators (parent and child) for a specified DNS name at the same time. If you have multiple accelerators that use different DNS names, the migration can be done one accelerator at a time.

  • You cannot use any external identity providers for authentication until iChain is removed from the configuration.

If you need fault tolerance, you can set up clustering any time during the migration process.You can wait until you have migrated a few resources, or you can set up fault tolerance before migrating any resources. See A Phased Migration with an L4 Switch.

Major Tasks

A Phased Migration with an L4 Switch

If you have configured iChain behind an L4 switch, you need to set up a similar configuration for your Identity Server and Access Gateway machines. This can be done before you migrate any resources from iChain to the Access Gateway or after you have migrated some.

Figure 10-4 Network Setup for a Migration with an L4 Switch

The L4 switch determines which iChain, Identity Server, or Access Gateway machine the user accesses. After you have set up this type of configuration, you then migrate your resources using the same processes as you would use if the servers were not grouped or clustered.

Major Tasks

A Staged Migration

Many companies have a staging area for deploying new products. The new products are configured and tested in this controlled environment. When the configuration meets the required needs, the machines are moved into the production environment and assigned new IP addresses. You can create such an environment for all components of the Access Manager except for the Access Manager Administration Console. It must be installed where it is going to be used; its IP address cannot change, because that is what all the other components use to trigger auto import and to establish communications with the Administration Console.

If staging is a requirement, you should not install the Administration Console and the Identity Server on the same machine. The Identity Server can be set up in a staged environment and then moved to a production environment and assigned a new IP address. For these same reasons, the Administration Console and the Linux Access Gateway should not be installed on the same machine.

NOTE:By adding a second Administration Console with the IP address you want to use in a production environment, making it the primary Administration Console, then removing the first Administration Console, you can overcome the IP address limitation. You can then perform a reinstall on the first Administration Console and change its IP address. Rather than performing these steps, we highly recommend that you install your Administration Console using the IP address that it needs in a production environment.

10.2.2 Outlining the Migration Requirements for Each Resource

Before you migrate your resources from iChain to Access Gateway, you need to know exactly how iChain was configured to protect your resources. You should export and have available the following iChain files:

  • .nas file

  • Any custom rewriter files

  • XML files for Form Fill policies and the source code of the associated HTML pages

  • Certificates used for SSL

With the aid of these files, determine how you have configured the following:

Proxy Server

List how you have configured the proxy server for the following features:

  • Time zone

  • Caching (pin lists and purge lists)

  • Log pushing

  • Alerts (system and Novell® auditing)

  • Tunneling

  • FTP

  • Telnet

  • Custom login, logout, and error pages

  • Network settings: IP addresses of DNS servers and the gateway (router)

Accelerator

For each accelerator, list how you have configured it for the following features:

  • SSL or mutual SSL and the certificates used

  • DNS name and IP address

  • Logging

  • If you use path-base multi-homing in iChain, list the child accelerators for each parent.

Protected Resources

Make a list of the resources the accelerator protects, and by each resource, list how the resource is being protected and how communication between the accelerator and the resource is enabled.

  • DNS name. All protected resources that share the same DNS name must be migrated at the same time.

  • Whether the hostname was forwarded

  • Login required (authentication) or public

  • URLs

  • OLAC

  • ACLCheck

  • Access Control Rules

    Access Manager currently caches policy data for the lifetime of that user’s session. iChain allows you to exempt a policy from caching, by defining a dynamic rule with a time to live (TTL) in seconds, which causes the policy to be re-evaluated when the TTL associated with that rule expires. This feature is often used to grant users entitlements when they purchase a product, and these new rights are granted without forcing the user to log out and then log in. Access Manager does not currently support this feature.

  • Form Fill

  • SSL or mutual SSL (and the certificates used)

  • Custom HTML rewriter

  • rewriter.cfg entries

You might want to use an LDAP browser to view the ACL objects in your directory. If you do not have an LDAP browser, free ones are available for download from the Internet.

Applications

For each protected application, determine the following:

IMPORTANT:Support for NetIdentity authentication has been removed from Access Gateway. If your iChain environment uses NetIdentity authentication to support ZENworks® for Desktops or simple background authentication for proxy login, you’ll need to remove the NetIdentity dependencies before migrating to Access Gateway. If you are using NetIdentity only for background authentication to a back-end NetStorage server, this functionality will continue to work.