IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
Back to discussions
Expand all | Collapse all

Adding AD attritutes to the SAML token

  • 1.  Adding AD attritutes to the SAML token

    Posted Mon July 01, 2019 11:06 AM
    I am trying to pass information from AD -> ISAM -> IBM CLoud Identity -> Office 365. For this to work I need to add custom attributes values to the SAML2 token.

    I am struggeling finding information for that. I already added a fixed value attribute on the ISAM to "Secure Federation / Attribute Souce" but it doesn not show up in the XML (intercepted with the SAML-tracer for Firefox).

    What am I doing wrong?

    ------------------------------
    Maarten Loor
    ------------------------------


  • 2.  RE: Adding AD attritutes to the SAML token

    Posted Mon July 01, 2019 04:55 PM
    You will need to do a couple things to have the additional attributes sent in the SAML assertion to Cloud Identity:

    1. Configure your ISAM reverse proxy instance to add the additional attributes to the user credential generated when the user authenticates.  Edit the reverse proxy configuration file, look for the [TAM_CRED_ATTRS_SVC:eperson] stanza, and add the additional attributes:  

    [TAM_CRED_ATTRS_SVC:eperson]

    emailAddress = mail

    mobileNumber = mobile

    commonName = cn

    familyName = sn

    description = description

    2. Configure the ISAM mapping rule for your ISAM to Cloud Identity federation and insert the relevant additional attributes in this JavaScript mapping rule.  An example ISAM - Cloud Identity mapping rule can be found here:  http://ibm.biz/BdZBhm
    You can either replace your existing federation mapping module with this one or just add the relevant lines to your existing one.  You will need to edit your federation to find out the name of your existing mapping rule.

    ------------------------------
    Mike Book
    Identity and Access Management CyberSecurity Specialist
    IBM
    St. Louis MO
    ------------------------------

    Original Message


  • 3.  RE: Adding AD attritutes to the SAML token

    Posted Tue July 02, 2019 02:09 AM
    Thanks Mike.

    I have added a custom parameter like this to the reverse proxy configuration:

    [TAM_CRED_ATTRS_SVC:eperson]
    emailAddress = mail
    mobileNumber = mobile
    commonName = cn
    familyName = sn
    description = description
    sometest = sometest

    Should the "sometest" attribute show up (with an empty value) in the XML token using the SAML-tracer? because it doesn't :(

    I had to add the emailAddress and mobileNumber as well. They do not show up either.

    ------------------------------
    Maarten Loor
    ------------------------------

    Original Message


  • 4.  RE: Adding AD attritutes to the SAML token

    Posted Tue July 02, 2019 05:49 AM
    Edited by Jon Harry Tue July 02, 2019 06:21 AM
    Hello Maarten,

    You didn't mention whether you updated the Federation mapping rule which would usually be required to get the attributes from the credential into the generated SAML token.

    In addition, there is one other step not mentioned above (if you want to use the mapping rule provided without modification).  Update the Reverse Proxy configuration file so that it doesn't force custom attributes to start with "tagvalue_":

    force-tag-value-prefix = no

    You might also find this cookbook helpful: http://ibm.biz/cloudid-sam-id-source-cookbook

    Cheers... Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 5.  RE: Adding AD attritutes to the SAML token

    Posted Tue July 02, 2019 05:57 AM
    Edited by Maarten Loor Tue July 02, 2019 06:01 AM
    Somehow my last update is not visible in the thread...


    I manged to add values by adding them to the "ibmci" mappings javascript. It fails whenever I try to use a "new" attribute which is not mentioned in the javascript which was already there. But it does show up in the SAML xml.

    Fails:
    var immutableid = stsuu.getAttributeContainer().getAttributeValueByName("objectGUID");

    Works:
    var immutableid = stsuu.getPrincipalName();
    finalAttrs.push(new Attribute("immutableid", "urn:oasis:names:tc:SAML:2.0:attrname-format:basic", immutableid));


    [TAM_CRED_ATTRS_SVC:eperson]
    immutableid = objectGUID

    I'll try to update the config with "force-tag-value-prefix = no" and see what happens.

    ------------------------------
    Maarten Loor
    ------------------------------

    Original Message


  • 6.  RE: Adding AD attritutes to the SAML token

    Posted Wed July 03, 2019 08:50 AM

    IMO the objectGUID from AD is a binary attribute. In order to use it for further processing, you have to tell webseal to base64 encode it:

    ldap.conf:
    [ldap]
    binary-base64-attr = objectGUID



    ------------------------------
    Frank Thurau
    ------------------------------

    Original Message


  • 7.  RE: Adding AD attritutes to the SAML token

    Posted Wed July 03, 2019 08:50 AM
    IMO objectGUID is a binary AD attribute, which has to be b64 encoded by changing the webseal's ldap.conf:

    [ldap]
    binary-base64-attr = objectGUID

    ------------------------------
    Frank Thurau
    ------------------------------

    Original Message


  • 8.  RE: Adding AD attritutes to the SAML token

    Posted Wed July 03, 2019 09:07 AM
    I also tried something really simple like "mobileNumber" which is in the [TAM_CRED_ATTRS_SVC:eperson] stanza, but it throws the same error:

    (from federation/messages.log):
    Caused by: org.mozilla.javascript.EvaluatorException: The choice of Java constructor com.tivoli.am.fim.trustserver.sts.uuser.Attribute matching JavaScript argument types (string,string,null) is ambiguous; candidate constructors are:
    Attribute(java.lang.String,java.lang.String,java.lang.String[])
    Attribute(java.lang.String,java.lang.String,java.lang.String)
    Attribute(java.lang.String,java.lang.String,java.util.List)
    Attribute(java.lang.String,java.lang.String,org.w3c.dom.Node[]) (ibmci#66)
    at org.mozilla.javascript.DefaultErrorReporter.runtimeError(DefaultErrorReporter.java:77)

    ------------------------------
    Maarten Loor
    ------------------------------

    Original Message


  • 9.  RE: Adding AD attritutes to the SAML token

    Posted Wed July 03, 2019 10:29 AM
    Edited by Jon Harry Wed July 03, 2019 10:29 AM
    Maarten,

    The error:
    com.tivoli.am.fim.trustserver.sts.uuser.Attribute matching JavaScript argument types (string,string,null) is ambiguous
    implies that the value you're passing into the new Attribute constructor is null.  If you got that value by reading an attribute, it probably means that attribute doesn't exist in the credential.

    If it fails for mobileNumber, but you have mobileNumber = mobile in the Reverse Proxy configuration, then this implies that the user has no value associated with the mobile attribute in Active Directory.  Looking at a list of AD LDAP attributes, I don't see that as a commonly used attribute.

    If your AD user has an e-mail address defined, maybe test with that?   Make sure you have emailAddress = mail in the Reverse Proxy configuration and then use

    var immutableid = stsuu.getAttributeContainer().getAttributeValueByName("emailAddress");

    in your mapping rule.

    To prevent the exception, you could also check for the null value before you try to create the attribute:

    if (immutableid != null) {
      finalAttrs.push(new Attribute("immutableid", "urn:oasis:names:tc:SAML:2.0:attrname-format:basic", immutableid));
    }

    Once you can get *something* from AD-->credential-->SAML Token then at least you know the theory is good.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 10.  RE: Adding AD attritutes to the SAML token

    Posted Tue July 02, 2019 06:24 AM

    Hi Maarten,

    any attribute which is not found in the LDAP will not be added to the credential and is therefore not available in the mapping rule or SAML token. 

    In the following Cookbook from Jon Harry you can also find additional information on how to manage the SAML token mapping and how to call a second STS to make LDAP lookup calls against attribute sources. But if all attributes you want to add are in the ISAM LDAP anyway, you should not need this. 

    https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20Security%20Federated%20Identity%20Manager/page/Federation%20Cookbook/comment/3ab86bb5-7930-479c-b6c5-85c28141aaa3


    Note: I'm unaware if there is any newer version out there but the SAML setup has not really changed since 9.0.3. 

    Regards,

    Philipp



    ------------------------------
    Philipp Klueter
    ------------------------------

    Original Message


  • 11.  RE: Adding AD attritutes to the SAML token

    Posted Tue July 02, 2019 10:14 AM
    Thanks Philipp,

    The problem with pointing to documentation or cookbooks is that they contain so much information that is not relevant to the goal I want to archive, I get lost in "terms". I am not that familiar with ISAM that I can simply get the information I need from that kind of documentation.

    I still am not any futher passing anything from AD to the XML. I am also not sure why I need to fill out the reverse proxy section [TAM_CRED_ATTRS_SVC:eperson]. It does not seem to matter if I add it or not.

    The information I need is in the LDAP of AD. Whenever I use the stsuu.getAttributeContainer().getAttributeValueByName("attributename"); function the ISAM just throws an error:

    SAML 2.0 authentication failed

    /sps/ibmci/saml20/auth
    2019-07-02T14:12:36Z

    Error details

    FBTSML225E Token exchange failed.

    Stack trace
    (so no stack trace indeed)




    ------------------------------
    Maarten Loor
    ------------------------------

    Original Message


  • 12.  RE: Adding AD attritutes to the SAML token

    Posted Tue July 02, 2019 10:49 AM
    Edited by Philipp Klueter Tue July 02, 2019 10:50 AM

    Hi Maarten, 

    so the  [TAM_CRED_ATTRS_SVC:eperson] stanza is used to add data of the ISAM user registry to the user session. It can subsequently be accessed in the mapping rule.  More Information on this : https://www.ibm.com/support/knowledgecenter/en/SSPREK_9.0.7/com.ibm.isam.doc/wrp_config/task/tsk_spec_attr_add_crdl.html

    The error shown looks like an Javascript error in your mapping rule. You can trace your mapping rule using the runtime tracing under > Monitor > Logs > Runtime Tracing  you can find the files under  Monitor > Logs > Application Log Files > federation > runtime > trace.log 

    A good trace level to start is "com.tivoli.am.fim.trustserver.sts.utilities.*=ALL" this traces the IDMappingExtUtils.traceString() function. With 

    IDMappingExtUtils.traceString("idp mapping rule called with stsuu: " + stsuu.toString()); 
    you can trace the whole stsuu. Do not forget to import the package: 
    importPackage(Packages.com.tivoli.am.fim.trustserver.sts.utilities);
    I think this should be enough to get you started with getting your ready to modify your mapping rules. Though I still think reading through the cookbook will help you to get more information. 
    Regards 
    Philipp 


    ------------------------------
    Philipp Klueter
    ------------------------------

    Original Message


  • 13.  RE: Adding AD attritutes to the SAML token

    Posted Thu August 01, 2019 03:15 AM
    Hello Philipp,

    I have implemented the debug trace which returned the following:

    <?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="UTF-8"?><stsuuser:STSUniversalUser xmlns:stsuuser="urn:ibm:names:ITFIM:1.0:stsuuser"> <stsuuser:Principal> <stsuuser:Attribute name="name"  type="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> <stsuuser:Value>email@address.nl</stsuuser:Value> </stsuuser:Attribute> </stsuuser:Principal> <stsuuser:AttributeList> <stsuuser:Attributename="groups" type="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <stsuuser:Value>SugarCRM Test</stsuuser:Value> <stsuuser:Value>Office365</stsuuser:Value> <stsuuser:Value>Box</stsuuser:Value> </stsuuser:Attribute> <stsuuser:Attribute name="AuthnContextClassRef" type="urn:oasis:names:tc:SAML:2.0:assertion"> <stsuuser:Value>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</stsuuser:Value> </stsuuser:Attribute> </stsuuser:AttributeList> <stsuuser:RequestSecurityToken/> <stsuuser:ContextAttributes/> <stsuuser:AdditionalAttributeStatement/></stsuuser:STSUniversalUser>

    So the attributes I added in the proxy config ("mobileNumber = mobile" or "commonName = cn") are not present in the trace.

    I think only the attributes in the integrated LDAP (Policy administration) may be passed and everything I add in the [TAM_CRED_ATTRS_SVC:eperson] stanza is ignored.

    I have looked at the cookbooks paragraphs about mapping rules (6.2.x) but what is described there has been done.

    Maybe it has something to do with the federated directory?

    Best regards,
    Maarten Loor






    ------------------------------
    Maarten Loor
    ------------------------------

    Original Message


  • 14.  RE: Adding AD attritutes to the SAML token

    Posted Fri August 02, 2019 02:44 AM
    I found the problem!

    The default ibmic script collects information form the stsuu object and puts them in variables. Next it clears the whole object using "stsuu.clear();". No wonder I could not retrieve any attributes after that. I moved my code to collect the attributes before the clear command, now it works.

    Thanks everyone!


    ------------------------------
    Maarten Loor
    ------------------------------

    Original Message


Related Content