But I just got this pattern to work '^([^.]+).*$' but you’re likely going to want to beef that up a bit instead of looking for anything (.*) for a little robustness
.
Hi. I’m just starting to look at OOD now (so I don’t have much experience with it), and am having authentication issues similar to what’s described here (but I’m using PAM authentication). I’m running 2.0.9 and when I set specifically the user_map_match: '.’ in the ood_portal.yml file and recreate the config, the /opt/rh/httpd24/root/etc/httpd/conf.d/ood-portal.conf file lists this environment: SetEnv OOD_USER_MAP_MATCH "^([^@]+)@.$"
…and I get a login error (failed to match user)
If I modify the ood-portal.conf file directly and change the OOD_USER_MAP_MATCH to “.*” and restart the server, I can log in.
Seems like the /opt/ood/ood-portal-generator/sbin/update_ood_portal process is ignoring that setting.
Most likely you need to modify oidc_remote_user_claim otherwise it will default to email and the regex used is to extract the part before @ symbol. The value to set depends on what exactly you want to use to log people into OnDemand. If you look at the Dex logs you should be able to see which claims are being returned so know which claim to assign based on the data you want to use to log into OnDemand.
Ok. Let me check that out. We really just want the entered username to be the same as the system username (so no email format, just ‘userA’ mapped to ‘userA’ on the system)
I see what the issue was. I had installed ondemand-dex (but wasn’t really using it for anything). The fact that it was installed was making the portal generator assume ‘email’. After removing the package and re-running the generator, it stuck the correct info in the ood-portal.conf file.
The comment “# Dex support will auto-enable if ondemand-dex package is installed” was the tip-off there.