We are trying to move to a SSO-SAML solution using AZURE AD and no LDAP Server ( we still will have to figure out how to manage the console without an LDAP server as the Fileregistry is not a solution for us )
Until now, we have been able to make it work without any LDAP Server ( except the FileRegistry ). We are grabbing all the information form the SAML Response ( Claims ). It is working with the "snoop" servlet ( using claims found in the response and applying multiple options in the role mapping ) as well as another home "application". So this means that we are using in the TAI the option "IdAssertion" and the realm is pointing to the default one ( sso_1.sp.useRealm=defaultWIMFileBasedRealm). There are also other parameters in the TAI that I am not displaying here ( groupMap, principalMap ..... )
But once, we try it with the portal app ( whose url is part of the filter ), it is not working anymore. Based on the "trace", it seems that it is not using the "idAssertion" or that it is doing another kind validation ( not sure that this one is )
I have looked at the "IBM" classes ("LDAPHelper" ... ), but it didn't help.
Any suggestions ?
The error message in the attachment
ERRORSAMFORUM.txt
Portal will always attempt a lookup of the user in the registry regardless of the SAML TAI setting. We do have functionality in Portal - called transient users - which handles this scenario.
The following article was written with OpenIDConnect TAI + transient users, however, the same concepts apply for SAML TAI + transient users:
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0084411
Please try implementing and let us know how it goes. If difficulties persist, can you past a bit more of the full stacktrace in use? Right now I'm assuming coming from Portal code, but if no luck with the transient users implementation, definitely want to see full stacktrace to narrow down where its coming from. Thanks.
-Travis
Hello Travis,
thanks a lot for your prompt response.
I have forgotten one information : we are still suing 8.5 ... migrating to 9.5.
WAS : 8.5.5.12
WPS : 8.5.0.20171201_1518 ( Fixpack 15 )
I have followed the instructions as per the PDF. I just had to customize the "class" to add groups. The code attached is working with the snoop servlet but not with wps. Our portal depends a lot on groups and I have tried to add groups to the "inmemory repository" but without success.
have not changed the default "User repositort attribut mapping".
Any help would be very much appreciated
loginModule-error.txtloginModule.txt
Hi Daniel,
The stack trace in the error shows PUMA code trying to lookup the user in the repositories configured. If the user does not exist in the repositories, then you may want to configure transient users like what Travis described and provided a link to. This would tell Portal that this user doesn't actually exist in the repositories. I am not sure that you can do transient groups in Portal though. So if you depend on groups for access control settings, for example, then another solution could be to have a repository (like an LDAP) with all the users and groups already set up. This would allow you to configure the groups on access control settings.
Hello Daniel,
I just saw that my post four days ago got lost. Sorry. Let me try to summarize it once more and please accept my apologies if there is redundant information.
Looks like you are using the WAS SAML TAI to achieve what you've done so far. I assume that you've setup the user and group assertions similar to the steps here: https://blog.2innovate.at/posts/asserting_saml_users_and_groups_in_websphere_application_server/.
Did you set up portal's transient user registry (even if the documentation is for OIDC it's afaik required for SAML as well) and the JAAS login module for your configuration? A sample, as a starting point which might hopefully help, for the Login module can be found here: https://github.com/hhue13/WasLoginModule).
You are trying to work totally without a file registry and without local LDAP? Not sure if that works. One of the problems we found is for example that Portal UIs verifies users and groups if you assign users/groups to roles. If you are running the transient user registry only you simply don't have the users & groups. We've therefore created empty groups with the same name as in the group claims in the file registry (so these can be found by the Portal UIs) . At login we are adding the user to the groups which are in the SAML group claims via the JAAS login module.
Otherwise, I'm afraid you have to implement a VMM adapter or custom user registry (CUR) for this and can't achieve that by using the SAML TAI only.
However, if you manage to get that running without VMM adapter, CUR, file registry, and local LDAP I hope to read a BLOG post about that :)
Hope this gives some hints in the proper directions and helps a bit - Hermann
P.S: I've uploaded a lab I've created for one of the Portal conferences some years ago here.
Hello Hermann,
at the end, we were able to do it without an LDAP. As you wrote it, transient registry was necessary, JASS Login module as well ( Customized to add the groups included in the Claims of the Sam response ) and then we found that there was another solution to create groups inside the transient ( Inmemory ) registry. I needed to add a custom property to the transientidp whose name is "buildgroupsfor". I add there the name ( separated by a space) of the groups that will be added to this registry That is not far from your solution.
But at the end, we will need LDAP as having an administrator ( to run scripts, for example ) in the WIMRegistry is not a solution for our company. So LDAP .. but only for Admin purpose. Unless you got a solution for this one ...
Thanks a lot for the follow up.
Cheers
@Daniel JANS Can you please elaborate how and where you pass the group information. "I add there the name ( separated by a space) of the groups". I am also working on the same, struggle to get a solution.
@Hermann Huebler
In your document the below step is mentioned.
Copy the file “SamlLoginModule.properties” from the “/labfiles/dbp30”
directory to the <profile_home>/properties directory by running:
Any idea from where can I get the fie name SamlLoginModule.properties "/labfiles/dbp30".
Thank you
Good morning Kousik,
this property file is used as a mapping table to build a group mapping for the users. It seems to be used here in the login module https://github.com/hhue13/WasLoginModule/blob/master/LoginModules/src/main/java/at/toinnovate/portal/transparent/SamlLoginModule.java#L154 to build a hash table for the transient users.
By chance I've still indeed found a sample file as it looks like:
######################################################################
### Properties file for login module
######################################################################
## all users starting with "mta" will be member of the group "cn=mtausers,o=defaultWIMFileBasedRealm"
transparent.user.prefix.1=mta
transparent.group.name.1=cn=mtausers,o=defaultWIMFileBasedRealm
## All users starting with test will be member of the group "cn=testusers,o=defaultWIMFileBasedRealm"
transparent.user.prefix.2=test
transparent.group.name.2=cn=testusers,o=defaultWIMFileBasedRealm
transient.base.realmName=defaultWIMFileBasedRealm
transientEMailDomain=mta.labs
But again - that is just a sample setup to allow the login module to build groups. So it depends on your implementation how you assign your users to groups.
Hope this helps, Hermann
@Hermann Huebler Thanks for your reply. Any idea on how we can only relay on the transient user groups are coming through the SAML token which have no entry in LDAP (plan to remove LDAP completely). or light on what @Daniel JANS talking about in his post "I needed to add a custom property to the transientidp whose name is "buildgroupsfor". I add there the name ( separated by a space) of the groups that will be added to this registry". how to add this info as we have to add more then 100 groups.
Thank you.
Hello @Kousik Patra ,
the issue with the groups is as far as I can remember that you need the groups for the UI to assign groups etc. So if you don't have any groups in the federated repo you can't use the groups in the UI (not sure but would assume that you can use xmlaccess to set proper permissions).
What we've done some years ago for a customer as a mitigation we've created the groups in the fileRegistry (i.e. groups of the same name as we get via SAML) and assign the transient user on the Login module to the respective group.
Looking at https://help.hcltechsw.com/digital-experience/9.5/security/openid_trans_users.html (step 2.f) using buildgroupsfor attribute for the providers should possibly build the groups based on what you get from SAML. Not sure to be honest but thing it is worth to test.
Hi,
The github URL is not reachable anymore, do you have updated URL or the JAR file that we can use?
Mohammad,
Are you referring to this url:
https://github.com/hhue13/WasLoginModule
@Hermann Huebler do you have a new url for this resource?
Hello @George Fairbairn and @Mohammad Ashfaq Memon , I have converted the repo to a public repo now and it should be available at https://github.com/hhue13/WasLoginModule_public.git. Hope that works for you as well.
Thanks. Hermann