On Nov 19, 2013, at 6:10 PM, Baron Fujimoto <[email protected]> wrote: > Anyone? Is there a perhaps a more useful way to frame my query? > > Specifically, I'm trying to ensure that REMOTE_USER is set to the > actual username credential that was used to authenticate to CAS. > More generally, it would be useful to have a better understanding > of what gets mapped to REMOTE_USER and how to configure such.
Couple of thoughts off the top of my head: 1. Refactor data in the LDAP directory. E.g. we allow multiple 'uid' values for authN, but return (e.g. in Shibboleth) a unique, persistent principal (e.g. ePPN). 2. Perform direct-bind authentication, as there's no 'uid' attribute to pull from LDAP to mix up. This can have some unintended side effects: many LDAP operations are case-insensitive: someone enters 'FrED', LDAP matches/authenticates 'fred', but FrED is returned in the validation call. We worked around this with a 'normalization' shim extending AbstractPersonDirectoryCredentialsToPrincipalResolver to match our username policy, then wiring into deployerConfigContext.xml. 3. Switch attribute retrieval/delivery to Shibboleth? Depending how it's done, can isolate authN from authZ. E.g. instead of the (IMO rather complex) Shib-CAS integration, we employ mod_auth_cas on the Shib servers for authN, with Shibboleth taking care of the rest. Tom. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
