I recently had a requirement to propagate a third party session ID (set by an EAI server) from one ISAM system to another, so that a user can be automatically logged in to the target third party system based on its session ID. So ECSSO sounded like an ideal solution. But I hit some challenges when setting this up so I thought that it would be worth sharing some of the lessons I learned in the process.

The first challenge is that for ECSSO to work the user needs to exist in the user repository of the target system, or ‘an identity that can be mapped into a valid account in each of the participating remote domains’. If this is not the case, authentication will fail and the WebSEAL log will show ‘HPDIA0114E Could not acquire a client credential’. (In fact that manual states this just for CDSSO, but it is clearly the case for ECSSO as well.) This was the first problem as the users did not exist within an ISAM user registry, but instead the EAI server was setting am-eai-ext-user-id. So the decision was taken to create a generic user in the ECSSO target’s user registry, and create a mapping rule to map all users to this generic user.

Then I had assumed that it should just be a matter of creating the required entries in the [ecsso-token-attributes] and [ecsso-incoming-attributes] stanzas to propagate the required tag-value data in the ECSSO vouch-for assertion. However it turns out that when using a combination of ECSSO and user name mapping the tag-value attributes do not get copied across automatically, and so need to be specified explicitly in the user name mapping file.

After a fair amount of fiddling about I developed this procedure, which will map all users to a generic user ‘myappgenericuser’ on the ECSSO target and propagate the attribute ‘tagvalue_other_sessionid’:

1. Create a user ‘myappgenericuser’ on the ECSSO target WebSEAL. This needs to be set as ‘Account Valid’, but it does not need to have ‘Password Valid’.

2. On the ECSSO target, under Secure Web Settings > User Name Mapping create a mapping module file containing the following:

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

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:stsuuser="urn:ibm:names:ITFIM:1.0:stsuuser" version="1.0">

<!-- Required to constrain output of rule evaluation -->
 <xsl:output method="xml" omit-xml-declaration="yes" encoding='UTF=8' indent="no"/>

<!-- Need this to ensure default text node printing is off -->
 <xsl:template match="text()"></xsl:template>

<!-- Let's make it easier by matching the constant part of our XML name -->
 <xsl:template match="/XMLUMI/stsuuser:STSUniversalUser/stsuuser:AttributeList">
 <attribute name='tagvalue_other_sessionid'><xsl:value-of select="stsuuser:Attribute[@name='attr:tagvalue_other_sessionid']/stsuuser:Value"/></attribute>
 <identity>myappgenericuser</identity>
 </xsl:template>

</xsl:stylesheet>

This will return a fixed username, ‘myappgenericuser’, and will also place an attribute in the cred named ‘tagvalue_other_sessionid’ whose value has been propagated from the ECSSO source WebSEAL.

3. In target WebSEAL configuration file, in the [user-map-authn] stanza, set:

rules-file = <name of mapping module file>

After this, ECSSO should work even for users who do not exist in the ECSSO target user registry.

4. To propagate tagvalue_other_sessionid from the initial WebSEAL to the ECSSO target WebSEAL:
(a) Create an entry in the ECSSO source WebSEAL configuration file, in the [ecsso-token-attributes] stanza, similar to one of the following:

<default> = tagvalue_other_sessionid
<domain name> = tagvalue_other_sessionid

where ‘<domain name>’ is the domain name of the ECSSO target WebSEAL. (Check in the manual for details. If specifying ‘<default>’ it really is ‘<default>’.)

(b) Create an entry in the ECSSO target WebSEAL configuration file, in the [ecsso-incoming-attributes] stanza, similar to the following:

tagvalue_other_sessionid = preserve

(Actually this last step is optional. Again, check in the manual for details.)

After completing these steps, ‘tagvalue_other_sessionid’ should appear in the credential on the ECSSO target.

(It’s also useful to know that when experimenting with mapping rules you can set ‘debug-level = 9’ in the WebSEAL configuration file.)

Like all these things it’s easy when you know how, but I went through a fair amount of pain to get to the desired result!

Vaughan

Tagged IBM Security Access Manager, ISAM, WebSEAL