Repository group memberships not recognized after migration to JAS (Jazz Authorisation Server)
CLM V.6.0.3, JAS V.6.0.3
After migrating JTS to use JAS with help of repotool, I'm able to login to JTS, but I'm only recognized as guest and I'm not member of any repository group when login through JAS with an LDAP account. Any idea what could be wrong? I'm using the same LDAP setup than before the migration. A local file based registry is working. Local users defined and added to the local groups are working. The LDAP setup in JAS is working. I can run the test on the /oidc/endpoint/jazzop/registration URL. Also members are recognized in LDAP groups for the oauth-roles to manage application registrations within /jts/setup. The Liberty AdminCenter for JAS is also able to work with the LDAP groups defined in the <administrator-role> section. The Issue is that all CLM applications are NOT recognizing the repository groups through JAS. The setting in appConfig.xml, <application> section, is just "ignored". As well as the settings in the application.xml of the CLM applications, which was working before with direct LDAP. How does JTS recognize the group membership through JAS? What can I do to troubleshoot? Any Idea or configuration example? I read many documents and help pages but I do not have an idea anymore. regards Guido |
One answer
Hi Guido
The group membership is recognized via the entries in JTS Advance Settings (+Group Mappings in JAS application.xml). If your JTS setup was previously pointing to LDAP, then you need to change it to DETECT to be able to use basic registry via JAS. You could change this in JTS teamserver.properties.
com.ibm.team.repository.user.registry.type=DETECT
If the LDAP settings in JAS earlier failed, you can check the LDAP parameters via the following article:
https://jazz.net/wiki/bin/view/Deployment/ConfigureLDAPforLibertyProfile
Once configured, you can check by accessing the JAS registration URL to confirm LDAP is configured right: https://<JAS_host_name> :< ssl_port> /oidc/endpoint/jazzop/registration
Regards
Shubjit
Comments Hello Shubjit,
I tried with UNSUPPORTED (the one which makes most sense), LDAP and also LIBERTY (makes not much sense). The /registration works well. I made some more investigations. And will update my question with the current status. regards Guido
Shubjit Naik
commented Jan 03 '17, 6:01 a.m.
HI Guido
My bad, "DETECT" was for Non JAS setup, it should be "UNSUPPORTED".
Guido Schneider
commented Jan 03 '17, 6:18 a.m.
Hello Shubjit,
Can you share the ldapUserRegistry.xml? If the authentication works while accesising the URL, it could be with group mapping.
https://<jas_host_name:< ssl_port> /oidc/endpoint/jazzop/registration
In addition to this, do you have deatils of the LDAP parameters in JTS (Before moving the JAS)?
Lonnie VanZandt
commented Mar 25 '21, 10:49 a.m.
Shubjit, Guido is correct. Having configured CLM, JAS, and LDAP according to available IBM documentation, all three systems appear to individually properly configured. Independent queries of the JAS OIDC endpoints and of the LDAP endpoints and structures all prove to show proper values. JAS authentication works well.
Nevertheless, the Jazz CLM applications never correctly recognize the Group memberships of the JAS-authenticated, LDAP-provided users.
There is no documentation or logging to indicate where CLM is looking for User/Group cached state or to see why CLM fails to properly map users and groups.
I suspect that in UNSUPPORTED mode, CLM actually is caching Users and Groups into its internal Derby database and something is messed up or not yet configured internally there.
Shubjit Naik
commented Mar 25 '21, 10:57 a.m.
HI Lonnie,
The User to group role mapping is handled by JTS. If you are using LDAP the User Registry type should be LDAP in JTS. It can be set to UNSUPPORTED if JAS is configured with BasicUserRegistry.
Lonnie VanZandt
commented Mar 25 '21, 2:21 p.m.
I'll give the setup a run-go with "LDAP" as the User Registry Type.
It might be able to share the ldapUserRegistry.xml file from the JAS server - the same LDAP server is being consulted.
showing 5 of 7
show 2 more comments
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.