Migrating Your Authentication Profiles

You need to migrate authentication profiles that you set up in iChain. If you only set up one LDAP profile for secure name and password, this method is set up by default and you can continue with Migrating the User Store Configuration. If you set up multiple LDAP profiles, Radius (tokens), mutual SSL (X509 certificates), or NMAS, you need to migrate these profiles.

iChain supports the ORing of profiles; a user can authenticate using one of two methods. The Identity Server does not support ORing of profiles. When you examine your iChain profiles, you need to decide whether to change the ORing to ANDing or to use just one method.

LDAP Authentication Profiles

Examine your iChain LDAP profiles (Web App > Configure > Authentication > [Name of LDAP Profile] > Modify). If you created multiple iChain authentication profiles for the same LDAP store by using a different LDAP context or LDAP search base, you need to decide how you are going to migrate these profiles. Select one of the following methods:

SSL Mutual Authentication

If you used SSL mutual authentication in iChain, you need to configure the Identity Server for this method. Examine your SSL authentication profiles in iChain (Web App > Configure > Authentication > [Name of SSL Profile] > Modify).

To migrate this configuration to the Identity Server, see Setting Up Mutual SSL Authentication in the Novell Access Manager 3.0 SP4 Administration Guide.

RADIUS (Token) Authentication

If you used RADIUS authentication in iChain, you need to configure a contract for this method. Examine your RADIUS authentication profile in iChain (Web App > Configure > Authentication > [Name of Radius Profile] > Modify).

For Identity Server configuration information, see Creating a RADIUS Authentication Class in the Novell Access Manager 3.0 SP4 Administration Guide.

Migrating the User Store Configuration

Enabling the User Stores for Authentication Methods

Migrating Custom Login Pages

If you used custom login pages in iChain, you need to convert the HTML login page to a JSP page, then associate the JSP page with a class or method that is used to create a contract. You then select this contract for a protected resource, and on first access to that resource, the custom login page is displayed to the user.

You add this property to either the class or to the method derived from the class. For its value you use the filename of the custom login page you created. If you set the property on the class, you need to create a method that uses the class, then a contract that uses the method.

For more information, see Creating Custom Login Pages in the Novell Access Manager 3.0 SP4 Administration Guide.

Network Settings

This section describes the differences between network settings for iChain and Access Gateway and the paths to access the following settings:

DNS Servers

Both products have the same options. You can add up to three DNS servers that the machine can use to resolve names. You can also configure the same advanced options that control the caching of DNS names.

Gateways

Both products have the same gateway options. The NetWare Access Gateway does not support SOCKS clients. The Linux Access Gateway does.

Telnet

set listener telnet enable=yes

Telnet is inherently non-secure because everything is transmitted in clear text. If you have enabled Telnet in iChain, we recommend that you disable it in Access Gateway and use SSH instead, which supports data encryption. You enable SSH on the Console Access page of the NetWare Access Gateway. The Linux Access Gateway does not support the Telnet and SSH options.

IP Addresses

Both products allow you to add IP addresses to existing adapters and configure their subnet masks and options for speed and duplexing. The biggest difference is in how the TCP™ options are configured.

System Settings

In iChain, you could configure the following settings from system settings: Timezone, Date/Time, Actions, SNMP, Import/Export, Upgrade, Alerts, and Admin ACL. The Access Gateway does not support the Import/Export option or the Admin ACL option. Access Manager does allow you to back up the complete configuration and restore it. See Backing Up and Restoring Components in the Novell Access Manager 3.0 SP4 Administration Guide.

Both products allow you to configure the following system settings:

Date & Time

Both products allow you to set the date and time, set up an NTP server, and configure the time zone. Time synchronization is critical if you have installed the Identity Server and the Access Gateway on separate machines. The authentication process, which relies on the exchange of credentials and authentication assertions, fails when the two have a time discrepancy of more than one minute. We recommend that you set up both machines to use NTP and that you verify the time zone of each.

Upgrade

Both iChain and the NetWare Access Gateway have the same options. You can enter the URL where the upgrade files are located and then select to upgrade immediately or schedule the upgrade for a later date. You can also back up to the previous version.

The Linux Access Gateway uses a script to download the upgrade RPMs from a server and upgrade the gateway. See Section 8.3, Upgrading the Linux Access Gateway.

Actions

Both products support actions that purge the cache and restart or shut down the machine. Most of these options are not configurable; you need to learn the new location and the new names.

Alerts

Both products have the same options. You can configure Access Gateway to use a Syslog server, send e-mail notifications to a specified list of users, and select the same types of alerts.

SNMP

Both products have the same options. You can allow the community Read access to monitor the state of the Access Gateway, allow the community Write access to the control states of the Access Gateway, and allow traps to be sent.

Setting Up Certificates

To enable SSL for Access Gateway connections (from the browser to Access Gateway and from Access Gateway to the Web servers), you need to provide certificates:

Migrating the Parent Accelerator

A parent accelerator is an accelerator in iChain that has a unique DNS name:

To migrate a parent accelerator:

Migrating the Path-Based Multi-Homing Accelerators

Path-based multi-homing accelerators are migrated as proxy services of the reverse proxy that specifies the DNS name.

Migrating the Protected Resources

In iChain, the ISO object holds the protected resources. You use ConsoleOne to manage the ISO object. You can configure each protected resource to be public, restricted, or secure. iChain could additionally use LDAP information to authorize access.In Access Gateway, protected resources are not global like iChain; they are assigned to a specific proxy service (which is like an iChain accelerator). Novell Access Manager centralizes the authorization policies and authentication procedures, which can then be assigned to specific protected resources. These policies are greatly expanded and can do much more than the iChain policies. In addition, you do not need to change tools. You configure everything in Novell Access Manager with the Administration Console. In particular, you configure both the protected resources and the policies in the Administration Console.

Because iChain protected resources are global and associated with a DNS name, you need to migrate all the protected resources associated with a DNS name at the same time. The following sections describe how to migrate the protected resources:

Examine your iChain protected resources, and then select the appropriate migration strategy for that resource. If possible, we suggest you migrate a public resource, then a restricted resource. After you have seen the process work for these types of resources, you can migrate your secure resources. The policies that make these resources secure must be re-created in the Administration Console.

Migrating a Public Resource

A public resource is a resource that requires no login procedures or authorization policies.

To migrate these protected resources:

Migrating a Restricted Resource

A restricted resource is a resource that requires a login procedure but not an authorization policy. In iChain, these are the resources you configured with ConsoleOne.

To migrate these protected resources:

Migrating a Secure Resource

A secure resource is a resource that requires a login procedure and an authorization policy. The authorization policy can specify Form Fill parameters, information to be injected into the HTML header (called OLAC in iChain), or additional criteria the user must match to access the resource (called ACLCheck in iChain). See Section 10.3.7, Migrating Resources with Special Configurations.

Testing the Migrated Resources

Enabling User Access to the Migrated Resources

If you want to create a single sign-on environment, you need to create an accelerator in iChain that protects the Identity Server. See Section 10.3.6, Enabling Single Sign-On between iChain and Access Manager.

If you are going to install an L4 switch so you can create a cluster of Access Gateways, you might want to install it before allowing public access to the migrated resource. You can use the L4 switch to determine which IP address the DNS name resolves to. The public DNS server resolves the DNS name of the migrated resource to the L4 switch, and the L4 switch determines whether that DNS name is sent to iChain or to the Access Gateway.

If it is acceptable for your users to authenticate to iChain for iChain resources and to use a separate authentication to access the resources migrated to the Access Gateway, complete the following steps:

Using Form Fill instead of OLAC for Single Sign-On

You can use Form Fill instead of OLAC to provide the authentication information. Your Form Fill policy should look similar to the following:

<urlPolicy>
   <name>Identity Provider login</name>
   <url>ncsles9.suse.de/nidp/idff/sso</url> 
   <formCriteria> 
      <title>Access Manager 3.0 Login</title> 
   </formCriteria> 
   <javaScript></javaScript> 
   <scriptForPost></scriptForPost> 
   <actions> 
      <fill>
         <input name="Ecom_User_ID" value="~cn"> 
         <input name="Ecom_Password" value="~password">   
     </fill> 
     <post/> 
   </actions> 
</urlPolicy>

You need to modify the domain name (ncsles9.suse.de) of the <url> element to match the domain name of your Identity Server.

In addition to the Form Fill policy, you need a Login Failure policy. The Login Failure policy should precede the Form Fill policy in the XML file.

<urlPolicy>
   <name>IDP Failure</name>
   <url>ncsles9.suse.de/nidp/idff/sso</url>
   <formCriteria>Login failed, please try again. If you continue
      to be unable to login, please contact your system
      administrator.</formCriteria>
   <actions>
      <deleteRemembered>Identity Provider login</deleteRemembered>
      <redirect>ncsles9.suse.de/nidp/idff/sso</redirect>
   </actions>
</urlPolicy>

The <deleteRembered> element should only be used if you are using shared secrets. The value of this element is the name of the Form Fill policy (in this example, Identity Provider login). If you are using some other mechanism such as LDAP attributes instead of shared secrets, the <redirect> element should be used to redirect your users to your password management URL.

The domain name of the Identity Server (ncsles9.suse.de) needs to be replaced and match the domain name of your Identity Server in the <url> and <redirect> elements.

Limitations of the Forward Authentication Method

Enabling the Forward authentication information to web server option has the following limitations:

These limitations, if your iChain resources use other authentication methods, impose the following restrictions on your migration plans.

URLs Requiring Form Fill

There is no tool to convert the XML files for iChain Form Fill policies to Access Gateway policies. The tables below explain where the information in the iChain policy should be entered in the Access Gateway policy.

<formName> 

<formNum>

<cgiCriteria>

<formCriteria>

<input name="">

<select name="">

<input type=""> 

<select type="">

<input value=""> or 
<select value="">

<input ff_lower_upper
="">
<select ff_lower_upper
="">

<injectStaticValue>

<debugPost/>

<maskedPost/>

<javaScript>

<scriptForPost>

<errorRedirect>

<urlPolicy>

<url>

<formName>

<formNum>

<cgiCriteria>

<formCriteria>

<redirect>

<deleteRemembered>

<urlPolicy>

<url>

For more information, see Creating Form Fill Policies in the Novell Access Manager 3.0 SP4 Administration Guide.

URLs Requiring OLAC

OLAC is called identity injection in Novell Access Manager. Information can be injected in one of several ways: authorization header, custom header (name/value pairs), custom headers with tags (tag name-value pairs), or query strings. iChain has the ability to inject constants and authentication profiles from the authenticated directory user. Access Gateway has the ability to inject these and other new types of data.

Identity injection allows you to add information to the HTML header or to the query string of the URL before the request is sent to the Web server. The Web server can use this information to create dynamic pages customized to the user or to determine whether the user should have access to the resource. The Web server determines the information that you need to inject. The following sections provide the information you need to migrate your OLAC policies to Access Manager.

Policy Comparison between iChain and Access Gateway

The following table lists the iChain feature and the equivalent Access Gateway feature.

As you can see from the table, Access Gateway supports all the iChain OLAC policies. However, the table doesn’t show you all of the new types of data you can inject into the authentication header, the HTTP header, or the URL query string. You can also inject the following types of information:

For more information, see Creating Identity Injection Policies in the Novell Access Manager 3.0 SP4 Administration Guide.

Migrating a Policy for the Authorization Header

Migrating a Policy for Custom Header Variables

In iChain, an automatic X- prefix was added to all custom header variables. Some Web servers do not require the X- prefix to identify custom header variables. To accommodate these servers, Access Gateway does not add a X- prefix to the custom names. If your Web server requires the prefix, you need to add the prefix when you define the name in the Access Gateway policy.

Migrating a Policy for a Query String

Some Web servers require custom information in a query string of the URL. The Inject into Query String option allows you to inject this information without prompting the user for it.

Configuring a Resource to Use an Identity Injection Policy

Policies are independent of resources. After a policy is created, it can be assigned to multiple protected resources.

URLs Requiring ACLCheck

In iChain, you set up an ACLCheck rule based on the user’s LDAP attributes, objects in the user’s dn, and group memberships, and you then assigned the rule to a protected resource. The Access Manager policies are more flexible, and each rule can be implemented in multiple ways. The following migration instructions explain how to use role policies to implement the same functionality you had with ACLCheck. Creating a role policy adds another configuration task, but it also exposes some of the power available in the Access Manager policy engine. After you have created a role and enabled it on the Identity Server, you can use the role in multiple authorization and identity injection policies.

Another option is to create an authorization policy using the LDAP attributes that you specified in the ACLCheck rule as the conditions of the authorization policy. See LDAP Context Policies in the Novell Access Manager 3.0 SP4 Administration Guide. For other methods, see Creating Access Gateway Authorization Policies in the Novell Access Manager 3.0 SP4 Administration Guide.

To migrate an ACLCheck rule using Access Manager roles, you first create a role policy based on the LDAP attributes you specified in the ACLCheck rule. This role policy is then used to create an authorization policy, which specifies the credentials the user requires to gain access to the resource. This authorization policy is then assigned to the protected resource.

This process is described in the following sections:

Migrating an ACLCheck Rule to a Role Policy

To use roles in migrating existing ACLCheck rules:

Creating an Authorization Policy with an Allow and a Deny Rule

If you want to allow access to a resource when users meet a certain condition, and deny access to all users who do not meet that condition, one method is to create a policy with an Allow rule and a Deny rule. The policy engine in Access Gateway is flexible enough to allow many designs for a policy. The instructions in this section describe how to create a policy with an Allow rule and a Deny rule. For other ideas see Creating Access Gateway Authorization Policies in the Novell Access Manager 3.0 SP4 Administration Guide.

In iChain, the default behavior for secure resources was to deny access unless an ACLCheck rule allowed access. The behavior is different in Access Gateway. After a user has authenticated, the default behavior is to allow access to resources. Therefore, to restrict access to a resource, you need to create a policy that allows access to the users who meet the conditions and denies access to everyone else.

The following instructions explain how to create a rule that grants access to a URL when the user matches the sales role condition and denies access when the user doesn’t match the condition.

Protecting the Resource with the Authorization Policy

To apply the authorization policy to a protected resource:

URLs Requiring HTML Rewriting

If you created custom rewriter files for iChain or modified the configuration for the internal rewriter (the sys:/etc/proxy/rewriter.cfg file), you must enter the data from these files into an Access Gateway rewriter profile. You can create such a profile for each proxy service you configure.

To access the HTML rewriting policy page in the Administration Console, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML Rewriting.

Table 10-5 shows where to place the information from the iChain file in the Access Gateway profile.

[Name]

[Extension]

[Alias Host Names]—internal rewriter only

[URL]

[Exclude]

[Mime Content-type]

[Javascript Variables]

[Javascript Calls]

[Replace]

Migrating Citrix Clients

The Access Gateway can be configured to provide single sign-on for Citrix clients. The iChain configuration for accommodating the Citrix clients cannot be migrated, because the Access Gateway uses an entirely different process and requires a different type of Form Fill policy. See Configuring SSL VPN for Citrix Clients in the Novell Access Manager 3.0 SP4 Administration Guide.

Migrating Protected Resources for J2EE Servers

If you have created protected resources in iChain for J2EE servers, you should use the J2EE Agent, which hooks into JACC and JAAS rather than migrating these resources to the Access Gateway as protected Web servers. The J2EE Agent allows you to protect specific Web application pages and Java Enterprise Bean interfaces and methods, and you can create a customized authorization policy for each resource.

The J2EE Agent uses the Identity Server for authentication, so single sign-on is enabled between the Access Gateway protected resources and the J2EE Agent protected resources.

For more information, see the Novell Access Manager 3.0 SP4 Agent Guide.

Migrating Protected Non-HTTP Applications

If you have created protected resources in iChain for non-HTTP applications, you should use the SSL VPN server rather than migrating these resources to the Access Gateway as protected resources.

The SSL VPN server uses the Identity Server for authentication, so single sign-on is enabled between the Access Gateway protected resources and the SSL VPN protected resources.

For more information, see SSL VPN Gateway Configuration in the Novell Access Manager 3.0 SP4 Administration Guide.

Migrating Custom OLAC Drivers

Instead of migrating custom OLAC drivers, you can create the functionality of these drivers with Access Manager policies. For example, the LDAP OLAC driver could retrieve an LDAP attribute, such as employeeID, from eDirectory and inject the attribute and its value into the HTTP header or query string for the Web server requiring it. In Access Manager, you can accomplish all of this with an identity injection policy. For more information, see Creating Identity Injection Policies in the Novell Access Manager 3.0 SP4 Administration Guide.

If the user values you need to inject are not stored in an LDAP directory, you can create a secret store, prompt the users to enter the required values the first time they access the Web server requiring the values, store them in the secret store, and then inject the values when the user accesses the page requiring them. For more information, see Creating and Managing Shared Secrets, Creating Form Fill Policies, and Creating Identity Injection Policies in the Novell Access Manager 3.0 SP4 Administration Guide.

Changing the Address of an Identity Server, J2EE Agent, or SSL VPN Server

Changing the IP Address of an Access Gateway

If the new IP address is in the same subnet, see Changing the IP Address of the Access Gateway in the Novell Access Manager 3.0 SP4 Administration Guide for instructions.

If the new IP address is in a different subnet:

If your Access Gateway stops reporting to the Administration Console after completing these steps, you need to trigger an auto-import. See Section A.1.2, Triggering an Import Retry.