IBM Security Verify

 View Only
  • 1.  MMFA for External as well as internal users

    Posted Tue May 24, 2022 04:19 PM


    we are on ISVA 10.0.3 and running with following oauth Config on boht DMZ and MMFA proxy

    external-user-identity-attribute = username
    user-identity-attribute = ext-username
    external-group-attribute : groups

    And Secure Federation - Global Settings - Point of Contact has "Non-Access Manager, Access Manager Groups and extened attributes"selected

    This webseal config is based on OAuth for External Users | IBM Security Verify

    We have added MMFA with separate proxy and wants to have possiblity that both type of users are able to enroll and user their MMFA device 

    With trying Access token request on www.* and mmfa.* with resource,userinfo, introspection I am able to see session are built correctly ang groups are there.

    But as soon as I user MMFA to login session is always built with External User and without groups.

    On Federation I has option to use oidc_rp to map userinfo response from Identity provider to credentials on Relying party but I don´t know how and where we need to chagne to add extra groups provided by MMFA login.

    Piyush Agrawal
    Gjensidige Norway

  • 2.  RE: MMFA for External as well as internal users

    Posted Tue May 31, 2022 06:30 AM

    In your MMFA request policy (the browser channel policy), add an Infomap after the MMFA Authenticator mechanism. In the server-side JS for that Infomap you can modify the stsuu to add groups, which will in turn result in EAI response headers to the webseal (web reverse proxy) containing the access manager group names. This allows the WRP to build a session credential based on an external username (not an ISVA user), and ISVA group names.

    Try something simple like this for the infomap (modify the group name as required). No page template for the infomap mechanism is required:


    stsuu.addGroup(new Group("isvaGroup","",null));

    Turn on pdweb.snoop tracing on the Web Reverse Proxy so that you can manually inspect the EAI response headers that are returned on completion of MMFA login - this will allow you to see what the AAC authentication service is actually returning. Make sure the header names being returned line up with what is set in the [eai] stanza in the WRP config file.

    Hopefully thats enough to get you pointed in the right direction - at least to test out the pattern. 

    Of course in a real implementation of the infomap you'd want to decide what ISVA groups to add the external user to - based on information that you can access or infer, but that is out of scope for this question.

    Shane Weeden

  • 3.  RE: MMFA for External as well as internal users

    Posted Thu June 02, 2022 05:02 AM
    @Shane Weeden

    You can use stsuu like that in infomap?

    Wouldn't it just return undefined?​

    Jonatan Wålegård

  • 4.  RE: MMFA for External as well as internal users

    Posted Thu June 02, 2022 07:21 AM
    Edited by Shane Weeden Thu June 02, 2022 04:58 PM
    Jonatan - you're absolutely correct, what I provided is not Infomap code, it's what you would use in a JS mapping rule in a federation context like SAML SP or OIDC RP. That said, you can do it in Infomap, and as penance for making such a silly mistake, I sat down and wrote out and tested a working sample Infomap that allows you to dynamically set groups for a user that's not in ISAM when the POC type is set to:

    Non-Access Manager Username, Access Manager groups and extended attributes

    I pre-created groups in ISAM for group1 and group2.

    Here it is:


    // A simple test Infomap that logs in using a canned ID that is not in the ISVA user registry

    // and includes ISVA groups that are in the registry. Designed to be tested with the POC

    // configuration: Non-Access Manager Username, Access Manager groups and extended attributes


    function jsToJavaArray(jsArray) {

    var javaArray = java.lang.reflect.Array.newInstance(java.lang.String, jsArray.length);

    for (var i = 0; i < jsArray.length; i++) {

    javaArray[i] = jsArray[i];


    return javaArray;


    // These look backward - the plural 'attributes' is used to set a single value, and the singular 'attribute' is used

    // when you have multiple values. The product has been like that since the feature was originally added and we just live with it. 

    context.set(Scope.SESSION, "urn:ibm:security:asf:response:token:attributes", "username", "not_an_isam_user");

    context.set(Scope.SESSION, "urn:ibm:security:asf:response:token:attribute", "group", jsToJavaArray(["group1","group2"]));


    You can find the documentation (it's subtle) for this here:

    I tested it using the built-in credential viewer app with the following setting in my WRP:

    cred-viewer = ivcreds

    And a kickoff URL:

    The resulting cred with a non-ISAM user and ISAM groups is shown:

    The advice about using pdweb.snoop tracing to observe eai response headers if there were issues would still be applicable.

    Shane Weeden

  • 5.  RE: MMFA for External as well as internal users

    Posted Wed June 08, 2022 04:55 AM
    @Shane Weeden

    That's great thanks! But how is it dynamically ​set when you're explicitly targeting the groups here:
    context.set(Scope.SESSION, "urn:ibm:security:asf:response:token:attribute", "group", jsToJavaArray(["group1","group2"]));

    It looks static to me.

    In our case, we checked the snoop and the group is nowhere to be found there. No EAI headers as well.
    But if we change the Point of contact to an Access Manager user instead, the snoop will show the group membership + the EAI headers.

    So adding the group to the session is one thing, but it has to be fetched from somewhere.

    Jonatan Wålegård

  • 6.  RE: MMFA for External as well as internal users