On Wed, Sep 24, 2008 at 10:52 AM, Matthew Jones < [EMAIL PROTECTED]> wrote:
> <snip /> >> > > In my ignorance I have been hoping that I could change the Webflow: > > <action-state id="startAuthenticate"> > <action bean="x509Check" /> > <transition on="success" to="sendTicketGrantingTicket" /> > <transition on="error" to="viewLoginForm" /> > </action-state> > > to > > <transition on="success" to="viewLoginForm" /> > > and have some sort of error screen displayed for on="error" (saying invalid > certificate perhaps). Is there an error failed screen or is the normal flow > just to re-present the login screen? (In the case of a bad certificate, of > course, this is never going to work) You can transition to an error screen on error, you'll just need to write one :-) Re-thinking it, here's what I actually would probably recommend: 1. Extend UsernamePasswordCredentials to include a Certificate (i.e. create CertificateAndUsernamePasswordCredentials) 2. Create a CredentialsBinder class that can obtain the certificate from the Request and call certificateAndUsernamePasswordCredentials.setCertificate(certificate) 3. Create a delegating AuthenticationHandler (or a custom AuthenticationManager) that will essentially call both the Ldap handler and something you write to validate the certificate. 4. Configure everything in the Spring XML configuration. 5. Everything else should work like magic :-) -Scott > > However, do I then just keep the same LDAP / AD configuration for the > username & password? Plus, of course, I need access to the presented > certificate or principal name / e-mail address therein within my > authenticator. At this point I assume that I would have to modify some code > as I can't see a way to configure this although I would only be comparing > with some LDAP field. My authentication is bind to LDAP as user given in > logon screen and if logon succeeds compare certificate stored in LDAP/AD for > this user with that presented to the browser (or just the E-mail address > therein as that's in the LDAP entry too). > > I also presume that I wouldn't need the Credentials to Principal Resolver > as the principal would be that from the logon screen. However, that section > does include the use of LDAP to get the principal from LDAP where the uid is > used for the principal. So I'm trying to put 2 & 2 together and get 5 by > thinking can I use this LDAP lookup as well as the username / password bind > LDAP lookup and somehow check they both end up at the same entry? > > So you'd have to retrieve the certificate, store it in session/flow, and >>> >>>> then ask for username/password. You'll send the combination of >>>> username/password/certificate as one Credential and then have a custom >>>> authentication handler which can check both of them. >>>> >>>> Then its up to you to figure out what to do if the username's don't >>>> match >>>> :-) >>>> >>>> That easy, it's just a logon failure. Currently, I only have to do a >>> yes or >>> no and not the report of bad attempts or security alerts. The non-trivial >>> above may put off the people here so I'm trying to find the simplest >>> approach I can that just does what it has to. >>> >>> What I'm thinking above is would it be possible to require a client >>> certificate to be presented in the SSL handshake and then still re-direct >>> to >>> the logon form for username & password? Then, as part of some custom >>> LDAP/AD >>> handler, do the directory bind for authentication and then compare the >>> client certificate's E-mail address / principal name? The directory >>> currently contains the user's public certificate so the certificate could >>> be >>> compared it total if that were easier. >>> >> > -- > Matthew Jones > Interactive Data Managed Solutions Ltd > ----------------------------------------------------------------------- > Registered in England Company Number 3691868 > Registered Office: Fitzroy House, 13-17 Epworth Street, London, EC2A 4DL > Tel: +44 (0)1242 694133 | Fax: +44 (0)1242 694109 > [EMAIL PROTECTED] > http://www.interactivedata-ms.com/694133 > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
