IBM Security Verify

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

    Posted Tue May 24, 2022 04:19 PM

    Hello,

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

    [oauth]
    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
    https://www.linkedin.com/in/piyush-norway/
    Gjensidige Norway
    ------------------------------



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

    Posted 24 days ago

    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:

    importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Group);

    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
    IBM
    ------------------------------



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

    Posted 22 days ago
    @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 22 days ago
    Edited by Shane Weeden 22 days ago
    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"]));

    success.setValue(true);


    You can find the documentation (it's subtle) for this here: https://www.ibm.com/docs/en/sva/10.0.3?topic=policies-authentication-policy-parameters-credentials

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


    [local-apps]
    cred-viewer = ivcreds

    And a kickoff URL:

    https://www.myidp.ibm.com/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:testinfomap&Target=https://www.myidp.ibm.com/ivcreds

    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
    IBM
    ------------------------------



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

    Posted 16 days ago
    @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

    Posted 16 days ago
    The group1 and group2 groups have been pre-created in ISVA, but have ZERO members. It's dynamic in the sense that the session credential that is built for that EAI login has the (non-existent in the ISVA registry) not_an_isam_user as a member of those groups for that session only. You can use whatever ISVA groups you have created yourself, and the logic in your own infomap can decide what groups you want the session credential to include. That is what dynamic group membership means to me.

    I do not believe you when you say the pdweb.snoop trace did not contain EAI headers. That is simply impossible if you ended up with a session credential that looked like the one I showed in the example. Here's what I see after beautifying the pdweb.snoop trace:

    2022-06-09-05:11:10.201+10:00I----- thread(7) trace.pdweb.snoop.jct:1 /build/isam/src/i4w/pdwebrte/webcore/amw_snoop.cpp:166: 

    ----------------------------------------

    Thread 140080955680512; fd 258; local 127.0.0.1:29110; remote 127.0.0.1:443

    Receiving 967 bytes

    HTTP/1.1 200 OK

    X-Frame-Options: SAMEORIGIN

    am-eai-xattrs: AUTHENTICATION_LEVEL,tagvalue_user_session_id,tagvalue_session_index,authenticationMechanismTypes,tagvalue_max_concurrent_web_sessions,tagvalue_login_user_name,authenticationTypes

    authenticationTypes: urn:ibm:security:authentication:asf:testinfomap

    tagvalue_session_index: 905bb796-e75e-11ec-a592-000c29a20bf3

    AUTHENTICATION_LEVEL: 2

    authenticationMechanismTypes: urn:ibm:security:authentication:asf:mechanism:testinfomap

    tagvalue_max_concurrent_web_sessions: unset

    tagvalue_login_user_name: not_an_isam_user

    am-eai-redir-url: https://www.myidp.ibm.com/ivcreds

    am-eai-ext-user-groups: group2, group1

    tagvalue_user_session_id: bG9jYWxob3N0LWRlZmF1bHQA_YqDz+wAAAAIAAAAw+/OgYphCDyxnfwAAU0duT0lDNmk0d1BvZmJDVVZKQWVITHlSeWNFUTM4U3pBY0ZSRktMM0k5bE9Kc0xu:default

    am-eai-ext-user-id: not_an_isam_user

    Content-Language: en-US

    Content-Length: 0

    Connection: Close

    Date: Wed, 08 Jun 2022 19:11:10 GMT


    ------------------------------
    Shane Weeden
    IBM
    ------------------------------