Several of our application development groups need the ability to impersonate specific users in the dev/test environment so that was a requirement when we implemented CAS here. My solution was to set up a separate CAS instance and LDAP server for the applications that need impersonate functionality. I built a web-app that authorized users can log into and impersonate a user. The app works by creating a new user entry on the separate LDAP server and copying the "impersonated" user's attributes (except userPassword) from the production LDAP instance. The hashed userPassword value is copied from the LDAP entry of the "imposter" so they can use their current password to access the impersonated account. Obviously, the power to impersonate a user is something that we don't take lightly. You must be granted approval by all of the areas with applications connected to the impersonate CAS environment before you're given access and the list of authorized users is regularly audited.
In the CAS config, we're already using LinkedAuthenticationHandlerAndCredentialsToPrincipalResolverAuthenticationManager, so I just added another AuthenticationHandler, CredentialToPrincipalResolver and a LdapPersonAttributeDao all configured to search against the 'impersonation' LDAP. These where basically copies of the configurations I already had for our production instance with new values for server, bindDn, etc. Since LinkedAuthenticationHandler... tries credentials against all configured handlers until it receives a success, the developers can either use their production credentials and login to the services as themselves or use the the 'impersonated' username with their own password and access services as that user. We've been using that process for about 4 years and it has worked really well. Unfortunately, I've had to look for a replacement due to two factors: we are moving to AD as our main authentication backend, so userPassword is no longer available and I don't want to run a whole separate LDAP environment just for this. I'm currently working on a new version of the impersonate webapp that I've called Ditto (https://github.com/epierce/ditto) that uses token-based authentication (https://github.com/epierce/cas-server-extension-token) instead of LDAP for authentication. The process for impersonating a user is basically the same, except instead of copying the attributes from the production LDAP server, ditto generates a JSON document with all the user's attributes, generates an authentication token, and redirects the user to the login URL on the CAS server. The removes the need for a separate LDAP environment and we don't need the user's password since the token is the authentication credential. I've also added some enhancements to the process such as the ability to impersonate in the pre-production and production CAS environments (with the right authorizations, of course) and alerts to an audit mailbox when a user is impersonated. Right now, Ditto is tied pretty closely to way we do things at USF, especially in attribute resolution, but if anyone wants to take a look at it please be my guest. Thanks, -Eric -- Eric Pierce Identity Management Architect Information Technology University of South Florida (813) 974-8868 -- [email protected] ________________________________________ From: Fabio Sogni <[email protected]> Sent: Thursday, January 16, 2014 5:51 AM To: [email protected] Subject: Re:[cas-user] Impersonation support Jérôme wrote: > In fact, the implementation will strongly depend on the version of the CAS > server and the way you authenticate your Admin user. It's probably easier > with the new CAS server 4.0 as everything can be done in an authentication > handler [1] without using a principal resolver. > > Let's say that your Admin user is authenticated by a login and a password > and has an IP in a specific range. > > I would change the login page to post a new field : impersonatedUsername. I am also interested in the impersonation. We have CAS 3.5.2 and happy with it, so I am reluctant to move to 4.0. What we do is the authentication mechanism taking place in a custom java class. It would be sufficient for us to retrieve the username of the user to impersonate from the URL: i don't feel comfortable to add a new field "Impersonate user" to the login page. Checking the IP address is a good idea. Any further suggestion (or link) is welcome! Ciao, --------------------------------------------------------------------- Fabio Sogni | E-Mail: [email protected] | ESO - EUROPEAN SOUTHERN OBSERVATORY | Phone : +49 89 320 06 566 | Karl Schwarzschild Strasse, 2 | Fax : +49 89 320 06 677 | Garching bei Muenchen - Germany | | --------------------------------------------------------------------- Visita Interiora Terrae, Rectificando Invenies Occultum Lapidem. --------------------------------------------------------------------- -- 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 -- 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
