@Larry.Jackson can you help with this?

Try using the info here. This may be an issue related to scopes in the client registration. The directive should be - OIDCRemoteUserClaim user_name - not a preferred name. The client has to have username scope so the uid can be accessed. Let me know if this helps.

I tried that, but it didn't work. I'm not sure why. I could get the value of USERINFO_user_name in PHP, so I know that the user_name claim was being set correctly. I could also get Remote_User to set to aud, auth_time and other claims that were shown in the OIDC_id_token_payload, but not user_name. My solution was to first assign preferredUsername to sAMAccountName attribute from AD in the Cache Refresh configuration. I then had to deliberately misconfigure Cache Refresh to trick it into clearing out all of the AD accounts from the local LDAP. I then fixed it so that it pulled all of the accounts in again. If I did not do this, the preferredUsername attribute never showed up in the local LDAP. Once this was done, I went to Configuration --> JSON Configuration --> oxAuth Configuration and set openidSubAttribute to preferredUsername. Then in the apache config I set OIDCRemoteUserClaim to sub. After closing the browser, waiting a few minutes, and reopening (incognito mode) the Remote_User attribute shows the username. It is working now, and I have SSO on Nagios as a result. It just took a lot of fiddling around with it to get a workable solution. I also used the solution to trigger Joomla to log in prior to displaying it's own login page or the home page. No more clicking the login button to get in. Overall I think this will open some doors for my organization to work toward a seamless SSO environment. Now if I could only get my webdav server to use Kerberos I would be good to go. Thanks for looking into this, and you are welcome to pass on my solution to others. Jeremy J. Hicks | Systems Engineer CAE Services Corporation Office (630) 761-9898tel:(630)%20761-9898> Direct (630) 761-2055 ext. 56tel:(630)%20761-2055> Cell (630) 344-9650tel:(630)%20344-9650> WEBSITEhttps://caeservices.com> | LINKEDINhttps://www.linkedin.com/company/cae-services-corporation> | YOUTUBEhttps://www.youtube.com/watch?v=R_n7w9NBSZ0> [https://caeservices.com/wp-content/uploads/2019/11/correct-2018-steel-logo.png] Ask the Moldflow Experts Free Webinarhttps://attendee.gotowebinar.com/register/1722399668101250831?source=email+signatures> Next Topic: What's New in Moldflow?https://attendee.gotowebinar.com/register/1722399668101250831?source=email+signatures>

Jeremy, We appreciate you sharing your knowledge and solution. Let us know if there is anything we can do to help in the future. Thank you - Larry

I also wonder if you used "Legacy Claims" in the id_token, if you might have been able to map it. By default, Gluu doesn't add user claims to the id_token. Enabling the legacy feature will do this (like adding attributes to a SAML assertion). But if you can avoid legacy claims, that's a good thing too.