CAC Authentication to LDAP User Repository

Dave Evans (148●1●24●46) | asked Apr 10 '14, 2:04 p.m.

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

Comments

Robert Carter commented Apr 10 '14, 2:13 p.m.

David,

I have worked on this before, but I would need some additional information to help. Specifically are you using the web client, or RTC thick client or both.

We need to find a common field that exists in both. If you are using a CAC proxy. IE you login to a portal first with your CAC credentials. Then you login to tool using the same browser session. I have found that the CAC proxy can build a matching variable to pass along.

Like I said these implementations are very specific and always have to be done on a one on one basis.

Dave Evans commented 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 commented Apr 10 '14, 2:50 p.m.

Can you explain your setup a little more?

RTC or RTC/RRC/RQM (CLM)?

Window or Unix Based?

Database vendor

Application server, Apache/Tomcat or WebSphere Application Server

LDAP Server Windows Active Directory or some other vendor/type?

Dave Evans commented 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

3 answers

Most liked answers ↑|Newest answers|Oldest answers

0	permanent link Abraham Sweiss (2.4k●13●31) \| answered Apr 10 '14, 2:52 p.m. Hi Dave, May be a good idea to open a service request with WebSphere security team for an assist.

permanent link

Richard Schulz (1) | answered Apr 10 '14, 7:37 p.m.

Robert,
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

Robert Carter commented Apr 11 '14, 4:01 p.m.

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.

The SSO portal was what I was describing as a "CAC Proxy".

Richard Schulz commented Apr 14 '14, 11:06 a.m.

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?

permanent link

Robert Carter (429●2●83●89) | answered Apr 16 '14, 10:38 a.m.

Sorry for the delay. But I have done some research and testing.

You can use LDAP Wild Card searching in LDAP. I have tested it with a Apache Directory Studio against a Windows Active directory. Here is the link to the LDAP Browser Tool, How to verify LDAP for RTC

For Example, I did.

(uid=aaa*)

This would return all users objects in LDAP that start with three a's.

So in your example you would configure your LDAP filter to use something like this:

(uid=${SubjectCN}*)

This should map EVANS.DAVID.M.1234567890 (On Cert) to EVANS.DAVID.M.1234567890.C (On LDAP)

Here are some reference articles:

RTC with Smart Card Workaround

Config Certificate with WAS and RTC

WAS LDAP Search Filters

Active Directory Search Filters

Comments

Dave Evans commented Apr 16 '14, 11:02 a.m. | edited Apr 16 '14, 11:03 a.m.

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

Robert Carter commented Apr 16 '14, 11:10 a.m.

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?

Also, is this number on the end of SubjectCN unique, the 1234567890 number?

Dave Evans commented Apr 16 '14, 11:36 a.m.

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 :).

Robert Carter commented Apr 16 '14, 12:10 p.m.

Here is my understanding of how CAC works in general.

1. Plug you CAC into the reader.

2. Enter your PIN.

3. PIN is checked again PIN on card.

4. Certificate is checked against CRL(Certificate Revocation List) to ensure validity

5. User is checked against LDAP (Active Directory)

So... There has to be some common data on the cert and in LDAP? Is the ".C" value in another attribute? What about the concatenation of multiple attributes to create a unique search LDAP search filter?

Dave Evans commented Apr 16 '14, 12:15 p.m.

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).

It's all about the answers!

Related questions

CAC Authentication to LDAP User Repository

3 answers

Your answer