Factoring out the code into a shared method so that we can guarantee the logic is executed the same is rather easy, and we're always happy to encourage code re-use.
Exposing more of the context details would be interesting. We'd have to update the APIs to support exposing this meta data in either a way that was method agnostic (i.e. it would work for the DB as well as the LDAP authentication handlers), or just provide a "context" object you know to cast appropriately. Either way, this seems like a good thing to pile into our discussion of updating the Authentication APIs. Cheers, Scott On Sun, Jul 22, 2012 at 5:54 PM, Drew Mazurek <dmazu...@unicon.net> wrote: > Hey folks... I'm working on getting the CAS password manager working with > 3.5, and I could use some advice as to how to get the LDAP authentication > metadata over to the password manager subflow. > > First, some background. The password manager's purpose is to provide a > flow within CAS that supports changing and resetting users' passwords as > well as setting up password verification security questions for them. > There are a few paths through the flow: > > 1. The user clicks "Forgot Password" on the login screen. They can then > answer their security questions and set a new password. > 2. The user logs in successfully but needs to set security questions. > They're prompted to set up the questions. > 3. The user logs in successfully and their password has expired or must > be changed (as determined by the LPPE extensions). They're prompted to set > a new password. > > Now on to my questions: > > In the initial password manager release under 3.4, I had a separate LDAP > server configuration that would mirror the main configuration that was used > for authentication. It would perform the same lookup/DN determination that > the authentication handler used. If there were multiple LDAP servers, it > would also need to find the correct server. This works, but it's a little > klunky. > > In 3.5, so far I've consolidated the configurations so that the server(s) > only need to be configured in one place. But to ensure that the password > manager finds the exact same LDAP user that the authentication handler did, > I had to copy verbatim the code from BindLdapAuthenticationHandler that > determines the user's DN. On top of that, once I'm in the password manager > subflow, I don't know which LDAP server the user authenticated against, so > I have to try them all again and essentially reauthenticate the user before > I can look up their security questions or change their password. > > Ideally, at least for #2 and #3 above, it would be great to have access to > the LDAP DN and context of the successful authentication. There doesn't > appear to be a way for the authentication handler to release this > information. Any ideas or suggestions as to how this can be done cleanly > and in a way that's easily maintainable with future releases of CAS? > > For #1, I need to perform the same lookup that authentication would. In > that case, perhaps factoring the DN lookup code (lines 82-101 in 3.5.0 of > BindLdapAuthenticationHandler) into a public method could help? That feels > like a hack, though, so I'm not sure what the best way to proceed here is > either. (It doesn't feel right to me that an authentication handler should > be doing general username->DN conversion.) > > So now I'm open to suggestions. :) > > Thanks, > Drew M > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
