Configuring Novell iChain® for Novell exteNd™ Portal

Amber Hardy

exteNd Engineering

Novell, Inc.

Dale Maughan

System Test

Novell, Inc.

Barry Bradshaw

System Test

Novell, Inc.

Agenda

iChain Overview and Capabilities

Tips and Tricks

Q & A

1

2

3

iChain Overview and Capabilities

Suggested Versions

exteNd 5.2 or higher

iChain 2.3 SP2 or higher

What is iChain?

iChain encompasses the following core components:

iChain Proxy Server

iChain Authorization Server

Novell eDirectory™

iChain Benefits

iChain provides the following benefits:

Controls access to web servers and web applications

Accelerates access to web servers and web applications

Secures data sent from the browser to your network

Increases the overall security of a web server

Reduces firewall administration costs

Simplifies management and administrative duties

iChain Features

iChain provides the following features:

Reverse HTTP proxy cache

Authentication support

URL-based access privileges

Identity-based access control

User convenience of web single sign-on

Dynamic data encryption

Secure access to Citrix thin-client services

iChain Rewriter – Why and When?

The iChain internal rewriter is used to accomplish the following:

iChain can usually be dropped into an existing web infrastructure or web configuration without the need to change existing URLs, since they will be rewritten.

To rewrite URL references with the proper scheme and/or port (HTTP or HTTPS).

To rewrite URL references that contain private IP addresses or private DNS names with the public DNS name of the iChain accelerator.

To rewrite the Host header in incoming HTTP packets to the name expected by the internal web server.

Sample Configuration

DMZ

Client

Client

Client

Client

Router

Router

exteNd

Director™

Portal

exteNd

Composer™

Database

LDAP Store

iChain

GroupWise, eGuide,

NetStorage, etc.

(Content Web Server)

Content

Web Server

Single Sign On (SSO)

Note:

With exteNd 5.0, Forward Authentication was broken because of an exteNd issue. This issue was fixed in exteNd 5.2. The previous workaround was to use OLAC or Form Fill, but Forward Authentication will now work.

Forward Authentication

Form Fill Authentication

Object Level Access Control (OLAC) Authentication

iChain can provide single sign-on behavior for exteNd in several ways:

SSO – Forward Authentication

Forwards user's proxy login credentials to the exteNd server inside the HTTP Authorization header.

HTTP Authorization header is populated with a Base 64 encoded representation of the user's LDAP formatted name and password.

Easiest and most common method.

Requires LDAP authentication to be enabled on the exteNd server.

What it does:

Setup:

exteNd Director™ LDAP Setup

Under section “Deploying an exteNd Director project:”

For LDAP setup, see Chapter 20 of the Novell exteNd Director 5.2 documentation:

http://www.novell.com/documentation/extend52/Docs/help/Director/books/cdDeploy.html

LDAP predeployment tasks (eDirectory only)

Configuring and using SSL for LDAP connections

SSO – Forward Authentication

In the iChain admin tool, go to Configure -> Modify

SSO – Forward Authentication

Select Authentication Options -> Select option:

“Forward authentication information to web server.”

What it does:

SSO – OLAC Authentication

LDAP attribute data is injected into HTTP Authorization header and/or query string of packets sent to exteNd.

LDAP attribute data is stored in eDirectory.

More flexible than Forward Authentication because any attribute can be used to populate the HTTP Authorization header.

Setup

More difficult to setup than Forward Authentication, but more flexible.

To populate the HTTP Authorization header when using OLAC, you also need to enable Forward Authentication.

SSO – OLAC Authentication

In the iChain admin tool, go to Configure -> Access Control -> Select option:

“Enable Object Level Access Control.”

SSO – OLAC Authentication

In the iChain admin tool, go to Configure -> Modify

Note: These steps are only needed if you need to populate the HTTP Authorization header.

SSO – OLAC Authentication

Select Authentication Options -> Select option:

“Forward authentication information to web server.”

SSO – OLAC Authentication

Add an OLAC entry like the following example:

Select the desired Protected Resource -> Click the OLAC button on the right side to add an OLAC entry.

In ConsoleOne®, go to the iChain ISO object -> Properties -> Protected Resource tab

Name = ICHAIN_UID

Data Source = ldap

Value = uid

(This example will cause the HTTP Authentication header to be populated with the user's simple name and password.)

SSO – OLAC Authentication

SSO – OLAC Authentication

What it does:

SSO – Form Fill Authentication

Requires creation and maintenance of a script using ConsoleOne® for each URL and form.

Populates HTML login forms on behalf of the user.

Login credentials are stored in eDirectory or Novell SecretStore®.

Setup:

<urlPolicy>

<name>DirectorLoginFail</name>

<url>external.bigmoe.novell.com/ExpressPortal/portal/portlet/LoginPortlet</url>

<formCriteria>

<title>LoginPortlet</title>

Invalid user or password

</formCriteria>

<actions>

<deleteRemembered>DirectorLogin</deleteRemembered>

</actions>

</urlPolicy>

<urlPolicy>

<name>DirectorLogin</name>

<url>external.bigmoe.novell.com/ExpressPortal/portal/portlet/LoginPortlet</url>

<formCriteria>

<title>LoginPortlet</title>

</formCriteria>

<actions>

<fill>

<input name="uid" value="~">

<input name="pwd" value="~">

</fill>

<post/>

</actions>

</urlPolicy>

SSO – Sample Form Fill Policy

SSO – Form Fill Authentication

SSO – Form Fill Authentication

In the iChain admin tool, go to Configure -> Access Control -> Select option: “Enable Form Fill Authentication.”

SSO - Scoped Paths

Scoped paths allow credentials to be shared between the portal and the portlets once a user is authenticated to the portal.

Note:

Scoped Paths are new with exteNd 5.2 and had several defects. Fixes for these will be in exteNd 5.2.1.

exteNd Director™ provides a set of predefined scopes with path syntax based on standard file access and XPath.

SSO - Scoped Paths

Require User Authentication in the SMC

Forward Authentication with iChain

OLAC Authentication with iChain

Note:

${Request/api/getUserID} fetches the users full LDAP DN: cn=huey,ou=users,o=novell

Use ${Request/api/getUserID} and ${Request/api/getPassword} when not logging in via the Login Portlet. Such as:

SSO - Scoped Paths

Browser accessing the Login Portlet directly

Form Fill Authentication with iChain

Use ${Application/login-user} and ${Application/login-pass} when accessing the Login Portlet. Such as:

Note:

${Application/login-user} fetches the users simple name: huey

SSO - Scoped Paths

Some portlets do not like a LDAP DN for the username, but prefer an eDirectory DN or simple name, such as:

cn=huey,ou=users,o=novell vs huey.users.novell

vs huey

Use ${User/canonical} or ${User/attr/uid} in conjunction with ${Request/api/getPassword} in LDAP/iChain enabled environments when the eDirectory DN or simple name is needed.

Note: See exteNd 5.2 Release Notes for exporting LDAP uid in Director projects. The scoped path ${User/canonical} is new to exteNd 5.2.1 and should be used for the Network File portlet when configured with the NJCL provider.

SSO - Scoped Paths

Web Content and Portlet Behavior

Portlet connections consist of one of the following:

Combination of both

browser to content web server

portal server to content web server

Web Content and Portlet Behavior

For proper configuration of iChain with exteNd, it is very important to understand the behavior of portlets and other content.

Ask the following questions:

If so, use a URL that does NOT put iChain in the path between the servers.

Does the portlet use a portal server to content web server connection?

Web Content and Portlet Behavior

Does the portlet use a single URL for both a portal server to content web server connection and to redirect the browser to the content web server?

If so, use a URL that will:

Allow a portal server to content server connection to occur directly

Allow iChain to rewrite appropriately from private URLs to public URLs (using scheme, port, name) when an accelerator is providing access to the content server.

Web Content and Portlet Behavior

The following portlets use browser to content web server connections AND portal server to content web server connections:

GroupWise™ Mail

GroupWise Calendar

GroupWise Mail-Calendar

GroupWise WebAccess

eGuide

NetStorage

NetMail®

Web Content and Portlet Behavior

The following portlets use ONLY portal server to content web server connections:

Web Mail

Network File

Secure Exchange

Scenario 1:

Secure Exchange enabled only between iChain and the browser

Used when a secure connection between iChain and the portal or other content web server is not required.

Removes the overhead of doing SSL from the portal or other content web server.

Secure Exchange

Scenario 2:

Secure Exchange enabled on both sides of iChain

Used when a secure connection between iChain to both the browser and the content web server are desired.

Requires configuration of SSL certificates on content web server (self-signed certificates cannot be used).

Must configure iChain to trust the CA of the SSL certificates used by the content web server.

Secure Exchange – exteNd Setup

Under section “Setting Up Security:”

For security setup, see Chapter 9 of the Novell exteNd AppServer 5.2 documentation:

http://www.novell.com/documentation/extend52/Docs/help/AppServer/books/admSecurity.html

Using certificates

If Secure Exchange is enabled between iChain and the exteNd Portal server do the following.

Secure Exchange – iChain Setup

In the iChain admin tool, go to Configure -> Modify

Secure Exchange – iChain Setup

Select Enable Secure Exchange -> Select Secure Exchange Options (Note: This enables Secure Exchange between iChain and the browser.)

Secure Exchange – iChain Setup

Select option: “Enable secure access between the iChain Proxy and the Origin Web Server.” (Note: This enables Secure Exchange between iChain and the content web server.)

Secure Exchange – iChain Setup

The Trusted Root Container setting in the ISO object is used to locate the trusted root objects needed for doing SSL. (Note: This is only needed if using Secure Exchange between iChain and the web content server.)

Secure Exchange – iChain Setup

The trusted root objects are stored inside the Trusted Root Container.

Tips and Tricks

Multi-Home Accelerators

Domain-based multi-homing:

Uses the DNS name to determine which content web server will fill requests.

iChain Multi-homing provides the ability to use a single IP address and port to access multiple content web servers. A Multi-homing accelerator can be configured to provide Domain-based multi-homing or Path-based multi-homing. With Multi-homing you do not need separate IP addresses for each accelerator.

Multi-Home Accelerators

Path-based multi-homing:

Uses the sub-path specified in the URL to determine which content web server will fill requests. The sub-path can be specified ONLY for use in determining the correct origin web server (option Remove sub-path from URL is enabled), or it can be an actual path that is used by the web server (option Remove sub-path from URL is NOT enabled).

Caution:

There are several problem areas when using Path-based multi-homing with exteNd if the option “Remove sub-path from URL” is enabled. This configuration should not be used.

Setup:

Simultaneous Logout

Configure exteNd to use an iChain Logout page

Configure iChain to forward it's cookie to exteNd

exteNd can detect the presence of an iChain cookie so a logout from exteNd will also log the user out of iChain.

Simultaneous Logout – exteNd Setup

Edit the following two properties in the config.xml file for the Directory subsystem: (/library/ConfigService/DirectoryService-conf/config.xml)

com.sssw.fw.directory.ICSLogoutEnabled

(set to true)

com.sssw.fw.directory.ICSLogoutPage

(specify URL for the iChain logout page)

1

2

Simultaneous Logout – exteNd Setup

Simultaneous Logout – iChain Setup

In the iChain admin tool, go to Configure -> Modify

Simultaneous Logout – iChain Setup

Select Authentication Options -> Select option:

“Forward iChain Cookie to web server.”

iChain Protected Resources

If Accelerator Authentication is enabled, then protected resources need to be defined in ConsoleOne.

Restricted: Access is allowed or denied based on user authentication to iChain.

Secure: Access is allowed or denied based on user authentication to iChain and on access control rules.

Note:

Make sure to add a /* to the end of the resource path to include everything under directory.

Protected Resources

Determining Scoped Path Values

When debugging Forward Authentication or OLAC, it is often useful to use a Base64 decoder to see what is being passed in the HTTP Authorization header.

Add the Message portlet to a Personal or Shared Page and insert the scoped path of choice into the portlet's Message preference.

Use the Message portlet to determine scoped path values

Base64 Decoder

http://david.carter-tod.com/base64/default.asp

When debugging Forward Authentication or OLAC, it is often useful to use a Base64 decoder to see what is being passed in the HTTP Authorization header.

A good one to use is:

Cookies

If the cookie domain cannot be the same, then the Cross-domain Authentication feature is an alternate method.

Accelerators can all share the same cookie if they are configured in the same cookie domain.

iChain is cookie-based, so each accelerator requires a cookie domain setup.

Configuring Portal URLs

Keep internal connections internal.

Be careful with having the portal server resolve DNS names back to the iChain proxy server when accessing local content.

If a DNS name is used, and the portlets use a portal server to content web server connection, then the portal server needs to resolve to the content web server instead of to the iChain proxy server.

IE Security Patch

Microsoft security patch MS04-004 disables the clear-text authentication feature, which breaks the following portlets

exteNd 5.2 or later includes added support for forms-based authentication for:

iFrame

Shortcut

iFrame

Shortcut

NetMail®

Notes

IE Security Patch

To disable the security patch in Internet Explorer v6.0/SP2:

Create a key structure like the following if it doesn't already exist:

HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE

Then add two DWORD values each named iexplore.exe and explorer.exe with a value of 0.

Create a key structure like the following if it doesn't already exist:

HKEY_CURRENT_USER\Software\Microsoft\Internet

Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE

Then add two DWORD values each named iexplore.exe and explorer.exe with a value of 0.

Q&A

2003-12-08T12:43:39