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 v126.96.36.199, 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.
<%@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.