After making edits to this JS file, be sure to flush your browser cache/cookies for the changes to take effect on reload to avoid chasing phantom problems.
If you intend to import AD groups via the UI, you should plan to have the ID returned from the CAS server match what AD or LDAP imports into the login field of ohdsi.sec_user during the group import. Otherwise you will see two distinct identities in sec_user and sec_role for the same person, so the imported user login won’t match the currently authenticated user. AD iimport seems fixed on only importing sAMAccountName, which in our environment is not available from CAS due to uniqueness issues. Your mileage may vary. Using remote debugging, it appears the following setting does not impact the import field: ‘security_ad_userMapping_usernameAttr=userPrincipalName’, so I’m not sure what it does since it doesn’t seem to change the login name used for authentication either.
However, I see that the most recent update (post-2.11.1) to source I’m speculating will allow you to specify the AD login attribute on import with a new field in the code, security.ad.userImport.loginAttr. This is great for us since we can’t get either AD or CAS authentication to return a matching sAMAccountName. Meanwhile, if you are building WebAPI, I believe you could change the following returned value:
public String getLoginAttributeName() {
return "sAMAccountName";
}
to the attribute that will match the returned CAS user field, but if using Docker then you’ll need to wait for the next release of Broadsea to contain this update, or install an updated WebAPI.war and atlas.zip into the container as part of the container startup since the Docker images aren’t updated very often.