Its certainly possible, but non-trivial. We have code to handle theretrieval of the certificate and create a Credentials object for it that you can later interrogate for information. We generally assume however, that, you're only asking for the certificate.If that provides access to the contained E-mail address and/or principal name then that should do. If I change the connector such that clientAuth="true" so that a client certificate is required how do I get the interactive logon to appear too? The documented Webflow implies that if the client does supply a valid certificate then it is not re-directed to the interactive form.The documentation merely details the flow process. If you want it to go somewhere (i.e. an action that captures the certificate and dumps it in the session, or to the form, just change where the flow sends you to after it success/fails on the X.509 stuff). In theory, that should work ;-)
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)
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, andthen 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
