In 2009, Shane Weeden posted an article about using WebSEAL without a user registry.
The article made use of a number of components, including TFIM as a mechanism to generate an ISAM credential and return that to WebSEAL to build a session.
This pattern is particularly useful in scenarios where the users are stored in a different kind of registry, for example a database or supplied via some kind of federation.
In ISAM v8.0.0.4, a new feature has been added that allows users to be supplied via an EAI that aren’t in the local ISAM user registry, simply by returning their username. This greatly simplifies the pattern as TFIM is no longer required to generate a credential, and a WS-TRUST client is no longer required in the EAI order to complete the authentication and make a callout to the Secure Token Service (STS).
Rather than supplying an ISAM credential back in the EAI header, it’s possible to return a user in the newly available headers described in the WebSEAL configuration below:
# EAI external USER ID header names # The eai-ext-user-id-header takes precedence over the eai-user-id-header. # If the authentication data that is presented to WebSEAL includes both headers, # WebSEAL will process it as an authentication for an external user. eai-ext-user-id-header = am-eai-ext-user-id eai-ext-user-groups-header = am-eai-ext-user-groups
Here is a sample EAI that I use for testing/developing.
EAI Sample App
This EAI application will simply return an authenticated user “emily”.
Emily can be supplied as a standard (fully featured) ISAM user when the header
“am-eai-user-id” is used, or it will use Emily as an external user, when
supplying the “am-eai-ext-user-id” header in the EAI response.
If using the standard ISAM user, emily MUST exist in the ISAM user registry
otherwise an error will be generated. If using the external user, emily doesn’t
have to exist in ANY user registry.
Note: The header names are all fully configurable, and are all detailed under the [eai] stanza in the ISAM for Web Reverse Proxy configuration file. If you are using older versions of ISAM 8, or have configured your ISAM for use with TFIM, then the headers may have changed from their default, where an ‘fim’ has been added into some of them. From ISAM 9, they should now all remain their default values, and I’ve changed the example below to use them as per their defaults.
eaiapp.jsp
<%@page import="java.text.SimpleDateFormat"%>
<%@page import="java.text.DateFormat"%>
<%@page import="java.util.Date"%>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
<META name="RESULT" content="IBM Software Development Platform">
</HEAD>
<BODY>
<h2>EAI Sample App</h2>
<p>This EAI application will simply return an authenticated user "emily".
Emily can be supplied as a standard (fully featured) ISAM user when the header
"am-eai-user-id" is used, or it will use Emily as an external user, when
supplying the "am-eai-ext-user-id" header in the EAI response. </p>
<p>If using the standard ISAM user, emily MUST exist in the ISAM user registry
otherwise an error will be generated. If using the external user, emily doesnt
have to exist in ANY user registry.</p>
<%
/*
EAI and groups:
- if setting the internal user-id "am-eai-user-id", webseald
will build the rest of the cred (including ldap attributes) and will
populate iv-groups based on the registy groups, and will ignore the
asserted "am-eai-ext-user-groups" (i.e. it will not "merge" both
registry and eai provided groups
- if setting user-id with external user "am-eai-ext-user-id", webseald
will not build the rest of the cred and will not pull in registry
attributes (e.g. mail) but will populate iv-groups with the
"am-eai-ext-user-groups" supplied.
- essentially, if using "am-eai-ext-user-id", you must provide all extended
attributes
- suggest using internal id: "am-eai-user-id" and asserting roles in
"am-eai-xattrs"
*/
//Standard EAI User response:
/* response.setHeader("am-eai-user-id", "emily"); */
//External EAI User Response:
response.setHeader("am-eai-ext-user-id", "emily");
//External EAI Group Memberships, these
//must exist as ISAM groups for authorization.
response.setHeader("am-eai-ext-user-groups", "eaiGroup");
//Other EAI Reponse attributes
response.setHeader("am-eai-auth-level", "2");
response.setHeader("am-eai-xattrs",
"tagvalue_level1,tagvalue_level2,tagvalue_role,tagvalue_xattr,tagvalue_securitylevel,mobileNumber");
response.setHeader("tagvalue_level1", "1100");
response.setHeader("tagvalue_level2", "10000");
response.setHeader("tagvalue_securitylevel", "2");
response.setHeader("tagvalue_role", "admin,olb");
response.setHeader("tagvalue_xattr", "xattr_value_from_eai");
response.setHeader("mobileNumber", "1234567890");
//Optional Redirect URL after successful authentication
response.setHeader("am-eai-redir-url", "/demo");
%>
</body>
</html>
This EAI is particularly useful for returning extended attributes, that can be used to test HTTP Tag Values that can be used in Context Based Access Authorization rules.
If you don’t want/need the prefix of ‘tagvalue_’ in your attributes, then set the following item in your WebSEAL configuration file:
force-tag-value-prefix = no
If not – be sure to at least understand the ramifications if you ARE using extended attributes.
Philip Nye 
Hi Philip,
I have followed Shane Weeden’s article for without a User Registry. Just because we are on ISAM 7.0.0.
It’s working fine as expected except failover case. In case of failover i see webseal2 is checking user existence in user registry and redirect to login page. If user exist it goes through.
I see below error on webseal2-
HPDIA0219W An unknown user, abcd123@abc.com, was presented to Security Access Manager.
0x38CF0803 webseald ERROR wwa cdsso AMWFailoverCookieCutter.cpp 1096 0x0001cecf
DPWWA2051E An authentication system failure has occurred: error: HPDIA0202W An unknown user name was presented to Security Access Manager. (pd / ias) (error code: 0x132120ca).
0x132120DB webseald WARNING ias authsvc pdauthn.cpp 1487 0x0001cfd0
Highly appreciate if you could provide any pointers/suggestion/comment to resolve this issue on ISAM 7.0.0
Thanks!
LikeLike
Hi Yogesh,
This is a limitation in the failover cookie, this will not restore the credential, but rather attempt to rebuild it based on its UserID.
For what you’re proposing you will either need to reauthenticate against the server that identified them, the EAI? Or Consider the use of the DSC for credential storage across ISAMs.
LikeLike