What you can use is the Authenticated User Mechanism (https://www.ibm.com/support/knowledgecenter/SSPREK_10.0.0/com.ibm.isva.doc/wrp_config/concept/con_user_mapping_usr_map.htm) allowing to insert a full-dn (can be a new attribute which is inserted into the credential).
The authenticated user mapping can make calls to the Directory server . See
https://www.ibm.com/support/knowledgecenter/SSPREK_10.0.0/com.ibm.isva.doc/wrp_config/reference/ref_user_mapping_eg_usr_map.htmIn a customer engagement I have used this mechanism to extract a identity from a certificate , together with a LDAP lookup and used this info together with other info to build a DN.
Below is my working example . Hope it helps
<?xml version="1.0" encoding='UTF-8'?>
<!--
This XSLT file is used to control the mapping of an authenticated user to an
ISAM user identity.
The input into the rule evaluation will be an XML representation of the
authentication data, i.e.
<?xml version="1.0" encoding='UTF-8'?>
<XMLUMI>
<stsuuser:STSUniversalUser xmlns:stsuuser="urn:ibm:names:ITFIM:1.0:stsuuser">
<stsuuser:Principal>
<stsuuser:Attribute name="name">
<stsuuser:Value>
- authenticated user identity -
</stsuuser:Value>
</stsuuser:Attribute>
</stsuuser:Principal>
<stsuuser:AttributeList>
<stsuuser:Attribute name="-attrname-">
<stsuuser:Value>-attrvalue-</stsuuser:Value>
</stsuuser:Attribute>
...
</stsuuser:AttributeList>
</stsuuser:STSUniversalUser>
</XMLUMI>
At a minimum the '-attr-name-' can be one of the following:
* address
* qop
* browser
* method
Additional attributes can be provided dependent on the authentication
mechanism. Refer to the documentation for a complete list of supplied
attributes.
The output from the rule will be:
- an optional identity element: <identity>{value}</identity>
- 0 or more attribute elements: <attribute name={name}>{value}</attribute>
The {value} can be either:
- Free form text, which can also include elements from the source XML
- An LDAP search, the result of which will be used as the real value. This
will have the format of:
<userreg base='%base%' attr='%name%'>%ldap-search-filter%</userreg>
-->
<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:Principal/stsuuser:Attribute [@name='name']">
<attribute name='acrealm'>
<xsl:call-template name="tokenize">
<xsl:with-param name="csv" select="stsuuser:Value" />
</xsl:call-template>
</attribute>
</xsl:template>
<xsl:template name="tokenize">
<xsl:param name="csv" />
<!-- Version 1.0 does not support upper-case(), this is a work-around -->
<xsl:variable name="smallcase" select="'abcdefghijklmnopqrstuvwxyz'" />
<xsl:variable name="uppercase" select="'ABCDEFGHIJKLMNOPQRSTUVWXYZ'" />
<xsl:choose>
<!-- In case csv contains ',' (comma). This means that there are more tokens embedded in csv. -->
<xsl:when test="contains($csv, ',')">
<xsl:variable name="token" select="normalize-space(substring-before($csv, ','))" />
<xsl:if test="contains($token, 'DC=')">
<xsl:value-of select="concat(translate(substring-after($token, '='),$smallcase, $uppercase), '.')" />
</xsl:if>
</xsl:when>
<xsl:otherwise>
<!-- In case there are no ',' (comma). This is the last token -->
<xsl:value-of select="translate(substring-after($csv, '='),$smallcase, $uppercase)" />
</xsl:otherwise>
</xsl:choose>
<!-- If there are DC attributes in csv, then tokenize to retrieve the corresponding value -->
<xsl:if test="contains($csv, 'DC=')">
<xsl:call-template name="tokenize">
<xsl:with-param name="csv" select="substring-after($csv,',')" />
</xsl:call-template>
</xsl:if>
</xsl:template>
<xsl:template match="/XMLUMI/stsuuser:STSUniversalUser/stsuuser:AttributeList">
<xsl:variable name="value" select="stsuuser:Attribute[@name='x509.ext.X509v3 Subject Alternative Name']/stsuuser:Value" />
<attribute name='ackerberosrealm'><userreg base='o=ac' attr='ackerberosrealm'>
(mail=<xsl:value-of select="substring-after($value, 'mail:')"/>)
</userreg></attribute>
</xsl:template>
</xsl:stylesheet>
Kind regards,
Serge Vereecke
------------------------------
Serge Vereecke
------------------------------
Original Message:
Sent: Thu December 10, 2020 12:13 PM
From: sudhir kapu
Subject: IAG & LTPA junction
Thanks Scott - any input on this is appreciated.
------------------------------
sudhir kapu
Original Message:
Sent: Wed December 09, 2020 04:51 PM
From: Scott Exton
Subject: IAG & LTPA junction
Sudhir,
The LTPA cookie is being created from the value contained within the AZN_CRED_REGISTRY_ID credential attribute. This should be a full DN, but in the case of IAG is not. IAG simply creates the credential attributes from the claims which are provided by the OP. At the moment the Verify Access OP is setting the AZN_CRED_REGISTRY_ID claim as the user identity instead of the full DN. It should be possible to change the Verify Access OP configuration so that the full DN is used, but I am not 100% sure of the best way to do this. Hopefully someone else will be able to provide this information to you.
Thanks.
Scott A. ExtonSenior Software Engineer
Chief Programmer - IBM Security Verify AccessIBM Master Inventor
Original Message:
Sent: 12/9/2020 1:17:00 PM
From: sudhir kapu
Subject: IAG & LTPA junction
Hello,
I have configured IAG to authenticate with ISAM version 9.07 as the OIDC provider. This instance of IAG contains an LTPA junction to a back end websphere server. After successful authentication, accessing the LTPA junction fails with IAG displaying an error page:
The Application Gateway could not complete your request due to an unexpected error.
Error code: 0x38cf025f
DPWWA0607E Received basic authentication challenge for junction where filtering is being applied
On the backend websphere server, I see the following exception:
SECJ0373E: Cannot create credential for the user <null> due to failed validation of the LTPA token. The exception is com.ibm.websphere.wim.exception.InvalidUniqueNameException: CWWIM1011E The '201AT0949' unique name is not valid.
ISAM 9 documentation does specify that -
For single signon to succeed, WebSEAL and the LTPA enabled authentication server must share the same registry information.
How will this work for IAG which does not have a registry?
Also, looking at the credential viewer app in IAG:
AZN_CRED_AUTHNMECH_INFO OIDC Authentication
AZN_CRED_AUTHZN_ID 201AT0949
AZN_CRED_REGISTRY_ID 201AT0949
while the credential viewer infomap in ISAM 9.07 has:
AZN_CRED_AUTHNMECH_INFO LDAP Registry
AZN_CRED_AUTHZN_ID CN=201AT0949,OU=Staff,DC=uat,DC=test2,DC=org
AZN_CRED_REGISTRY_ID CN=201AT0949,OU=Staff,DC=uat,DC=test2,DC=org
The existing LTPA junction from ISAM 9.07 to websphere works fine.
Thanks,
------------------------------
Sudhir Kapu
------------------------------