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