That sounds good. I'm trying to make things as general as possible, but in areas it'll help for now, I'll keep the focus to one LDAP server.
Thanks! - Drew On Mon, Jul 23, 2012 at 3:44 AM, Misagh Moayyed <mmoay...@unicon.net> wrote: > Drew,**** > > In addition to the refactoring approach, would it perhaps be reasonable > for the PM module to assume that there will be a single LDAP instance, for > v1? That might simplify the problem quite a bit, such that you will no > longer have to loop through to find the correct instance. It would just be > one additional bind. I recall that the module was designed to work with a > multiple ldap setup but if it’s easier to switch back and not a whole lot > of work to ease the multi-ldap setup back to the code in the future once > the codebase has support for exposing the proper context, it might be safe > to make that assumption for now.**** > > ** ** > > Hope that helps :)**** > > ** ** > > *-*Misagh* > > * > > ** ** > > *From:* Scott Battaglia > [mailto:scott.battag...@gmail.com<scott.battag...@gmail.com>] > > *Sent:* Sunday, July 22, 2012 7:05 PM > *To:* cas-dev@lists.jasig.org > *Subject:* Re: [cas-dev] BindLdapAuthenticationHandler and Password > Manager**** > > ** ** > > 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: > mmoay...@unicon.net > > 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: mazu...@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
