Original Message:
Sent: Thu June 09, 2022 06:09 AM
From: Jonatan Wålegård
Subject: MMFA for External as well as internal users
@Shane Weeden
Yeah sorry it has gotten to a point where I don't quite understand fully.
I am a colleague of Piyush and since he is very busy I am trying to approach this on my own.
As he mentioned in the initial post, the setup is based on the other forum thread that he linked to (where you have been making some posts as well).
I have too little history and experience with our particular environment for all the customizations that have been done but I have a scheduled meeting with Piyush and hopefully we can put the last pieces together.
I can not see in any of our mapping rules that we are using the UserLookupHelper other than in the PreToken, but it requires true for those:
if (request_type == "access_token" && grant_type == "password")
Thanks so far though, really Appreciate you trying to assist me!
------------------------------
Jonatan Wålegård
Original Message:
Sent: Thu June 09, 2022 05:02 AM
From: Shane Weeden
Subject: MMFA for External as well as internal users
Sorry, this is not making sense. If you want a user's actual groups, why not return the real ISVA username, and use the point of contact type: "Access Manager Username and extended attributes"?
If there is some other motivator for having to have it set to "Non-Access Manager Username, Access Manager groups and extended attributes", such as some of the users are real ISVA users and some are not, then for those that are real, use the UserLookupHelper class, to figure out their real groups, and return them in the manner I have previously described. For example this worked for me (user testuser exists in my user registry and is a member of group1 only):
// testuser is a real user - look up their groups
let realuser = "testuser";
let ulh = new UserLookupHelper();
// use ISAM RTE - requires bind-dn and bind-pwd in ldap.conf
ulh.init();
let u = ulh.getUser(realuser);
if (u != null) {
let groups = u.getGroups();
if (groups != null && groups.length > 0) {
context.set(Scope.SESSION, "urn:ibm:security:asf:response:token:attribute", "group", groups);
} else {
IDMappingExtUtils.traceString("User: " + realuser + " does not appear to be in any groups");
}
} else {
IDMappingExtUtils.traceString("Unable to lookup user: " + realuser);
}
------------------------------
Shane Weeden
IBM
Original Message:
Sent: Thu June 09, 2022 04:17 AM
From: Jonatan Wålegård
Subject: MMFA for External as well as internal users
@Shane Weeden
Ah ok, thanks for the clarification!
In our case we don't want dynamic groups, we want to be able to fetch real membership from ISVA and add it to the session.
Yes you are correct, it does contain EAI headers but very limited.
Here is what a successful MMFA transacation looks like with Point of Contact with Access Manager Username and extended attributes
pdweb.snoop.jct:1 /build/isam/src/i4w/pdwebrte/webcore/amw_snoop.cpp:164:remote 127.0.0.1:8443HTTP/1.1 200 OKmmfa.authenticationTransactionId: *am-eai-xattrs: AUTHENTICATION_LEVEL,tagvalue_user_session_id,tagvalue_session_index,authenticationMechanismTypes,mmfa.success.authenticationMechanismTypes,mmfa.authenticationTransactionId,tagvalue_max_concurrent_web_sessions,tagvalue_login_user_name,tagvalue_credattrs_firstname,authenticationTypes,tagvalue_credattrs_lastname,SMS_SESSION_REALMServer: *AUTHENTICATION_LEVEL: 3tagvalue_max_concurrent_web_sessions: unsettagvalue_login_user_name: *am-eai-ext-user-groups: *tagvalue_user_session_id: *X-Frame-Options: SAMEORIGINtagvalue_credattrs_firstname: *tagvalue_credattrs_firstname: *authenticationTypes: *tagvalue_session_index: *Cache-Control: no-cacheauthenticationMechanismTypes:.urn:ibm:security:authentication:asf:mechanism:*authenticationMechanismTypes:.urn:ibm:security:authentication:asf:mechanism:*authenticationMechanismTypes:.urn:ibm:security:authentication:asf:mechanism:*am-eai-ext-user-id: *tagvalue_credattrs_lastname: *mmfa.success.authenticationMechanismTypes: urn:ibm:security:authentication:asf:mechanism:mobile_user_approval:fingerprintSMS_SESSION_REALM: ISAM-Distributed-Session-CacheContent-Type: application/jsonContent-Language: en-USSet-Cookie: *
And here it is with Non-Access Manager Username, Access Manager groups and extended attributes
pdweb.snoop.jct:1 /build/isam/src/i4w/pdwebrte/webcore/amw_snoop.cpp:164:remote 127.0.0.1:8443HTTP/1.1 200 OKX-Frame-Options: SAMEORIGINmmfa.authenticationTransactionId: *am-eai-xattrs: mmfa.authenticationTransactionId,authenticationTypes,AUTHENTICATION_LEVEL,authenticationMechanismTypes,mmfa.success.authenticationMechanismTypesauthenticationTypes: *Cache-Control: no-cacheServer: *AUTHENTICATION_LEVEL: 3authenticationMechanismTypes:.urn:ibm:security:authentication:asf:mechanism:*authenticationMechanismTypes:.urn:ibm:security:authentication:asf:mechanism:*authenticationMechanismTypes:.urn:ibm:security:authentication:asf:mechanism:*am-eai-ext-user-id: *mmfa.success.authenticationMechanismTypes: urn:ibm:security:authentication:asf:mechanism:mobile_user_approval:fingerprintContent-Type: application/jsonContent-Language: en-USTransfer-Encoding: chunkedConnection: Close
If it would return am-eai-ext-user-groups: * like it does in the working example then we could add it to the session. But it is not there.
------------------------------
Jonatan Wålegård
Original Message:
Sent: Wed June 08, 2022 03:13 PM
From: Shane Weeden
Subject: MMFA for External as well as internal users
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
Original Message:
Sent: Wed June 08, 2022 04:55 AM
From: Jonatan Wålegård
Subject: MMFA for External as well as internal users
@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
Original Message:
Sent: Thu June 02, 2022 07:21 AM
From: Shane Weeden
Subject: MMFA for External as well as internal users
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:
------------------------------
Shane Weeden
IBM
Original Message:
Sent: Thu June 02, 2022 05:02 AM
From: Jonatan Wålegård
Subject: MMFA for External as well as internal users
@Shane Weeden
You can use stsuu like that in infomap?
Wouldn't it just return undefined?
------------------------------
Jonatan Wålegård
Original Message:
Sent: Tue May 31, 2022 06:30 AM
From: Shane Weeden
Subject: MMFA for External as well as internal users
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
Original Message:
Sent: Tue May 24, 2022 04:19 PM
From: Piyush Agrawal
Subject: MMFA for External as well as internal users
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
------------------------------