Michael Thanks for your response.
Some points just to answer your questions:
1. The LDAP is ours - we control what records are in there. It
contains only employee records. When an employee leaves the
company their record is removed from the LDAP (which should mean
they no longer can authenticate using CAS)
2. The certificates are issued by us, via certificate authorites we
control. We include a check for our certificate issuer in the CAS
X509 authentication handler config
3. In our current working cas system we use
CredentialsToLDAPAttributePrincipalResolve to resolve from the
email address in the certificate to a uid in LDAP via an LDAP
lookup. This also has the advantage of denying access to anyone
with a certificate of an ex-employee, as the email address will
not be successfully resolved to an LDAP uid.
4. We use a webflow that first executes the X509Check - and then if
successful, passes the user to the login form. Invalid cert uses
do not see the login form.
5. In the login form authentication handler the certificate is made
available (yet), but the username (and password) from the login
form is. This latter username (and password) must correspond to a
uid and a matching password in LDAP.
6. What we're asking for is conceptually simple. We just need to
check that the uid in (3) matches the uid in (5) [i.e.
uid1.compareTo(uid2) == 0]
We currently have a very poor solution which implements (6) via some
additional lines in the AuthenticationManagerImpl class. It does this
via caching the uid from (3) in a private variable in that class. Of
course, this will break whenever two people try to login to CAS at the
same time, as CAS is not maintaining distinct instances per browser. By
"break" I simply mean that valid logins will fail due to the clash.
It seems to me that Marvin is right in his suggestion - we "simply" need the X509 certificate to be presented to the AuthenticationManagerImpl during handling the web login form submission - as well as the other credentials. That way we do not need to rely on comparing uids between two subsequent browser requests - rather we will have all credentials at the point when the user submits the login form. This would of course be more secure too.
Cheers Andy Michael Ströder wrote:
Andy Cowling wrote:Just to be clear, pulling the email address from the cert and resolving to a username in LDAP is required for authentication, not authorization(!) We don't want to authenticate any user who provides a cert that does not correspond to the login name they use in the web form.I think one has to distinguish several (optional) steps: 0. Map the user ID entered in a web form to a credential name (e.g. search the user's LDAP bind-DN with (uid=%u) in CAS) 1. Use the credential name together with the credential for authc => result is a principal name based on the authc mech used 2. Map the authc-specific principal name to a (normalized) authz-ID as CAS principal name. This is not authz, it's just name mapping 3. Outside CAS: Authz of the user within an application based on the (normalized) CAS principal name So for your situation... - step 0. is only needed if cert-based authc mech does not work. - the result of step 1. is the cert's subject-DN if cert-based authc was used. Being in your situation I would more think about what the different IDs are and who controls the name spaces with which naming rules. I'd then try to provision the LDAP entries in such a way that you can do the mapping in step 2. above like described here: http://www.ja-sig.org/wiki/display/CASUM/Attributes Further considerations: What is your authz-ID? The e-mail address? Is the e-mail address name spaces limited for your user community? Do you control the e-mail address name space? Note that in general normalization of the e-mail address can be tricky since the local part of a RFC2822 e-mail address is *case-sensitive*. The standard LDAP equality matching rule for attribute 'mail' is caseIgnoreIA5Match though. Who issues the client certs? If you control the client certs your issuing CA should be the only one trusted CA for the login. Also you can provision parts of the client cert data to the user's LDAP entry. ...etc... Ciao, Michael.
-- *Andy Cowling | UK Platform Management* *Interactive Data Managed Solutions Ltd* ----------------------------------------------------------------------------------- Suite 1101, Eagle Tower | Montpellier Drive | Celtenham GL50 1TA | GL50 1LE Tel: +44 (0)1242 6941 15 | Fax: +44 (0)1242 6941 01 [email protected] http://www.interactivedata-ms.com/This message (including any files transmitted with it) may contain confidential and/or proprietary information, is the property of Interactive Data Corporation and/or its subsidiaries, and is directed only to the addressee(s). If you are not the designated recipient or have reason to believe you received this message in
error, please delete this message from your system and notify the sender immediately. An unintended recipient's disclosure, copying, distribution, or use of this message or any attachments is prohibited and may be unlawful.Interactive Data (Europe) Ltd Registered No. 949387 England Registered Office:
Fitzroy House 13-17 Epworth Street. London. EC2A 4DL
smime.p7s
Description: S/MIME Cryptographic Signature
