CAC Authentication to LDAP User Repository
Has anyone been successful at getting CAC (client certificate) authentication working with an LDAP user repository?
I have a problem because our client certificate's websphere-supported properties do not have any exact match to any LDAP property. Are there any suggestions on what I should research on how to accomplish authentication?
We have an attribute which is very close, but not quite:
EVANS.DAVID.M.1234567890 (CAC's SubjectCN)
EVANS.DAVID.M.1234567890.C (LDAP name)
If we could just wildcard the .C off the end that would be fabulous since the CAC's SubjectCN is unique to a person, and we don't need to distinguish between types of people (contractor, civilian, reservist, etc.). I do not know why on earth the Air Force set LDAP up this way, but it seems that in any case it is little value added for a lot of pain. Are wildcards acceptable in a certificate filter? Any other ideas? THANKS!
-Dave
3 answers
Can you define what you mean by "CAC Proxy"?
The problem we are facing is that the RFC822_Name from the Subject Alternate Name(SAN) is the only value that is common in both the CAC and LDAP. IBM doesn't support parsing any value from the SAN, so we are hoping that this "CAC Proxy" will allow us to build a matching variable.
Can you describe how "CAC Proxy" would work?
Thanks for your insight.
Comments
We had a DoD customer using a portal to login. So basically it was a SSO portal where the users authenticated against their CAC and then the portal build an authenticated session cookie. We used that cookie for authentication down the line.
Perfect, we can provide that same option, SSO portal front-ending the WAS applications. What is required in the cookie and how is WAS setup to interpret the authenticated session cookie?
Comments
Robert, sorry if we didn't mention our fun fact, but if we were to wildcard EVANS.DAVID.M.1234567890, that would cause authentication to fail due to the search returning multiple users. Quite a few users's have multiple LDAP user accounts. For example, if I was a civilian and a contractor, we would have two entries in LDAP for me: EVANS.DAVID.M.1234567890.C, and EVANS.DAVID.M.1234567890.E
On your CAC is this value unique, SubjectCN? So, if you where a civilian, then left and came back as a contractor. Would your SubjectCN be the same on your CAC? I think it would be different, because you are issued a different CAC card the second time your came back?
Yes, it is the SubjectCN property. The number at the end is called the EDIPI, and while it is unique per person, it is not unique per position or per CAC. You can actually have two different CACs at the same time which are active (you could even be Contractor, Civilian, and Reservist at the same time: three CACs, one EDIPI number). There are other parts of the certificate which are different and unique, but those attributes on the certificate are unsupported by IBM. Hence us reaching out for support :).
Here is my understanding of how CAC works in general.
Yes, we can use the "RFC822Name" attribute, which contains the user's email address. If we truncate this attribute (mine would be something like dave.evans.34), then we can match the LDAP emailNickname attribute. The RFC822Name is in the SAN field of the certificate (unsupported by IBM).
Comments
Robert Carter
Apr 10 '14, 2:13 p.m.David,
Dave Evans
Apr 10 '14, 2:32 p.m.Robert,
We will be using both web and thick clients to login to RTC. We have a load balancer set up already but would need help with getting a CAC Proxy functioning.
The common fields is indeed our problem which appears to be forcing us to not use WebSphere's authentication mechanism. I am not familiar with CAC proxy setup, so I will have our expert join this post and continue to follow with it. Thank you SO much for being willing to help!
-Dave
Robert Carter
Apr 10 '14, 2:50 p.m.Can you explain your setup a little more?
Dave Evans
Apr 10 '14, 3:23 p.m.Setup is RTC + RRC + JTS
WAS 8.5.5 on Windows
LDAP service is Active Directory
DB is SQL Server 2008