Table of Contents

1 Basic Information

Access URL's:

Default URL for the IDM Portal guest page is similar to http(s)://:8080/IDM. A Login link is available on this page.

To access the login form directly, the default URL is similar to http(s)://:8080/IDM/portal/portlet/IDMLoginPortlet.

Single Sign On (Access Gateway to Portal):

Form Fill or Identity Injection can be used to provide single sign on from the Access Gateway to the IDM Portal.

Single Sign On (within the Portal):

The Portal has its own concept of Single Sign On, sometimes referred to as "Scoped Paths”. Scoped Paths are used to share the user's authentication information within and among the portlets and content web servers. Configuration of Scope Paths is done using the Administration portlet.

Portlet Connection types:

When accessing the Portal through an Access Gateway (AG), it is important to understand the behavior of connections required by the portlets in use. Most portlets will use one of the following connection scenarios:

a) Portal Server-to-Content Web Server only

b) Browser-to-Content Web Server only

c) Portal Server-to-Content Web Server AND Browser-to-Content Web Server

Portlets that use Portal Server to Content Web Server connections only:

• Network file portlet (CIFS, NJCL, RMI)

• Webmail portlet (POP and IMAP)

Portlets that use Portal Server to Content Web Server AND Browser-to-Content Web Server connections:

• GroupWise Calendar portlet

• GroupWise mail portlet

• GroupWise mail/calendar portlet

• GroupWise WebAccess portlet

• NetStorage portlet

2 Known Issues

3 Configuration Notes

Portal features and portlets tested:

Admin portlet

Create portlet

GW Calendar portlet

GW Mail / Calendar portlet

GW Mail portlet

GW WebAccess portlet

IDM Challenge Response

IDM Change Password

IDM Forgot Password

IDM Hint Definition

IDM Login Portlet

JSP-Edit Availability

JSP-Proxy Mode

JSP-My Delegated Assignments

JSP-My Proxy Assignments

JSP-My Requests

JSP-My Tasks

JSP-Request Resource

JSP-Request Team Resource

JSP-Team Availability

JSP-Team Delegate Assignments

JSP-Team Proxy Assignments

JSP-Team Requests

JSP-Team Tasks

Detail Portlet

NetStorage Portlet

Network File Portlet

Org Chart Portlet

Scoped Paths

Search List Portlet

WebMail Portlet

NAM features tested:

SSL: disabled both sides, enabled Public side only, and enabled both sides of proxy

Web Server Host Name: different than Published DNS name of accelerator

Modified rewriter profile for use with pbmh accelerator

Single Sign On using Formfill with local secrets and Novell SecretStore

Single Sign On using Identity Injection

Protected resource with IDP authentication

Simultaneous logout

Accelerator types tested:

Non multi-home:

No problems specific to this configuration were noted. Protected resource path is /IDM/*.

Domain-based multi-home:

No problems specific to this configuration were noted. Protected resource path is /IDM/*.

Path-based multi-home with option "Remove Path on Fill” disabled:

No problems specific to this configuration were noted. Sub-path match string is "/IDM”, protected resource path is /IDM/*.

Path-based multi-home with option "Remove Path on Fill” enabled:

This configuration is problematic and is not recommended with NAM 3.0.

Single Sign On (Access Gateway to Portal):

Either Identity Injection or Form Fill can be used to provide single sign on from Access Gateway to the IDM portal.

Identity Injection:

1. Configure an Identity Injection policy to populate the Authorization headers sent from the Access Gateway to Portal with the username and password that was used for user authentication to the Access Gateway/IDP:

• In iManager/DevMan, select the Policies link under the Access Manager task

• In the Policy List, click New. Provide a name. In the Type drop-down list, select Access Gateway: Identity Injection. Press OK.

• On the Edit Policy page, click New under the Actions section. Select "Inject into Authentication Header” from the drop-down list.

• From the "User Name: drop-down list, select the source of the username. For example, "Credential Profile”. A second drop-down list will now appear next to User Name:. Select an appropriate value from the list. For example, if Credential Profile was chosen as the username source, selecting LDAP Credentials->LDAP User DN will populate the Authorization header's username with the LDAP fdn of the user.

  From the "Password:” drop-down list, select the source of the password. For example, "Credential Profile”. A second drop-down list will now appear next to Password:. Select an appropriate value. For example, if Credential Profile was chosen as the password source, selecting LDAP Credentials->LDAP Password will populate the Authorization header's password with the password used for Access Gateway authentication.

• Press OK and Apply Changes to save the policy

2. Enable the Identity Injection policy on the Portal accelerator's protected resource

• On the Protected Resource page of the Portal accelerator, click "[None]” under the Identity Injection column of the protected resource defined for the Portal.

• In the "Identity Injection Policy List”, select (check) the Identity Injection policy created above, then click "Enable” in the menu. Press OK, then Apply changes in the usual way.

Formfill:

Form Fill can also be used to provide single sign on and simultaneous logout to/from the Portal.

On the last pages of this document is a sample Form Fill policy for Portal which includes actions for login success, login failure, and simultaneous logout. This policy can be imported directly into iManager/Devman. After importing, be sure to edit the URL's in the policy as appropriate for the customer environment, modify the Fill Options, and enable the policy on the Portal accelerator's protected resource for the IDM Portal.

Steps below:

1. Create the Form Fill policy

• Copy the sample Form Fill policy shown at the end of this document to a .txt file

• In iManager/DevMan, select the Policies link under the Access Manager task

• In the Policy List, click Import. Browse to the .txt file created above, then OK to import the policy.

• Click the link to open the policy. Under each action, edit the "Redirect to URL:” field as appropriate for the environment.

• Edit the "Fill Options” section of the login action with appropriate values. This example policy uses "Shared Secret” as the storage location. After importing, "[invalid value]” will likely be displayed. Select the drop-down list to select or create a new Shared Secret and key name for each input field.

• Press OK and Apply Changes to save the policy

2. Enable the Form Fill Policy on the Portal accelerator's protected resource

• On the Protected Resource page of the Portal accelerator, click "[None]” under the Form Fill column of the protected resource defined for the Portal.

• In the "Form Fill Policy List”, select (check) the Form Fill policy created above, then click "Enable” in the menu. Press OK, then Apply changes in the usual way.

Single Sign On (within the Portal):

While the Access Gateway can be configured to use Form Fill or Identity Injection to provied single sign on for user authentication to the IDM Portal, the Portal must also be configured to provide its own form of single sign on among the portlets and content web servers. Single sign on behavior within the portal itself and to its content web servers is sometimes referred to as "Scoped Paths” in the IDM documentation, sometimes simply as single sign on.

How Scoped Path's are configured and used depends on how the user initially gets authenticated to the portal (i.e. through manual logins, Form Fill, Identity Injection, etc), and on the credential format requirements of the individual portlets being used (simple name, LDAP name, etc).

General guidelines for using Scoped Paths with Identity Injection and Form Fill:

When using Identity Injection to provide single sign on to the portal, the following scoped path entries are available

• ${Application/login-pass} returns user's password

• ${Application/login-user} returns user's name in the format present in the Authorization header as populated by Identity Injection. For example, if the Identity Injection policy uses Credential Profile->LDAP Credentials->LDAP User DN for the username, the username in the Authorization header forwarded to the Portal will be similar to"cn=user1,ou=users,o=novell”, and that would be the name returned by scoped path ${Application/login-user}.

  If the policy uses Credential Profile->LDAP Credentials->LDAP User Name, the username in the Authorization header will be similar to "user1”.

• ${User/canonical} returns dot-delimited name, ex. "user1.users.novell”

• ${User/simpleid} returns simple name, ex."user1”

When using Form Fill to provide single sign on to the Portal, use the following scoped path entries:

• ${Application/login-pass} returns user's password

• ${Application/login-user} Returns user's name in the format entered into the IDM Login form. For example, if the initial user login to Portal is done using a fully distinguished name like "user1,ou=users,o=novell”, scoped path ${Application/login-user} will return that name. If the login is with a simple name like "user1”, ${Application/login-user} returns"user1”.

• ${User/canonical} returns dot-delimited name, ex. "user1.users.novell”

• ${User/simpleid} returns simple name, ex."user1”

  To determine which scoped path to use for specific portlets, see the IDM Documentation "Accessory Porlet Reference Guide.

Simultaneous Logout:

The Portal can be configured to detect the presence of an Access Gateway session cookie for the purpose of performing simultaneous logout . An Identity Injection policy can be configured to include the session cookie in the Cookie: header of packets being sent to the Portal. Steps below:

1. Create the Identity Injection policy to forward the AG session cookie:

• In iManager/DevMan, select the Policies link under the Access Manager task

• In the Policy List, click New. Provide a name. In the Type drop-down list, select Access Gateway: Indentity Injection. Press OK.

• On the Edit Policy page, click New under the Actions section. Select"Inject into Cookie Header” from the drop-down list.

• Press OK and Apply Changes to save the policy

2. Enable the policy on the Portal accelerator's protected resource

• On the Protected Resource page of the Portal accelerator, click"[None]” under the Identity Injection column of the protected resource defined for the Portal.

• In the "Identity Injection Policy List”, select (check) the Identity Injection policy created above, then click "Enable” in the menu. Press OK, then Apply changes in the usual way.

3. Enable Portal to detect the presence of the session cookie

• On the Portal server, run /novell/idm/configupdate.sh to launch the User Application Configuration tool.

• Press the "Show Advanced Options” button

• Scroll down to section "iChain Settings”

• Select checkbox "ICS Logout Enabled”

• In the ICS Logout Page field, enter the URL of the Portal acceleratorwith path /cmd/ICSLogout (ex: http:///cmd/ICSLogout).

• Click OK to save and redeploy the updated WAR.

4 Miscellaneous

Sample Form Fill policy for Portal (import into iManager/Devman):

<
?xml version="1.0" encoding="UTF-8"?>