Something I forgot in my last comment. If you don’t compare certs, ensure that your trusted CAs are limited to just the one(s) that you accept. The default Java trust store contains a ton of CAs…

My bad. I missed the “LDAP” distinction in your original question. What I described above is for the default identity asserter set to handle X.509 certs. There is no comparison of the provided cert to one in LDAP like the LDAP X.509 identity asserter does.

Whether you want to compare certs is up to you. The default identity asserter wouldn’t cause two hits to LDAP, though.

(In case you’re wondering, I asked originally because I’m trying to speed up certificate-based login.)

Identity asserters and authenticators work together to identify the user. Identity asserters check for the presence of tokens in the request such as an X.509 cert. When it finds one, it tries to map that token to a user known to the realm. In the case of a cert, the asserter might use the whole DN or just the CN as the user name. It does this via a username mapper class associated with the asserter.

Once the token has been mapped to a username, that username is passed to the authenticator(s) to see if the user exists. If an authenticator can find that username, the user has authenticated successfully (depending upon the control flags in the case of multiple authenticators). The authenticator can then do its other job of pulling the user’s groups.

As for the order, asserters always have to come first so that they can extract a username to pass along to the authenticators. An authenticator wouldn’t know what to do with the token.

However, as you know, the order of authentication providers is significant.

HTH,

Mike

No, there doesn’t have to be a WL user stored somewhere. This article is talking about the common case where there is a user account stored somewhere and the cert has to be mapped to it.

To not have a “backing user” so to speak, you’ll probably need a custom authenticator with a custom login module. This login module will do nothing more than add a WLSUser object to the Subject. This value can be anything you want but I’d imagine you’d take some piece of the DN and stick it there. This value represents the user from WLS’ perspective, so if you do an HttpServletRequest.getRemoteUser() you’ll get that value back (as a simple String, of course).

Check the sample security providers for an example of a custom authenticator.

Hope this helps,

Mike

Anyway, thanks for demystifying WL’s security framework. I can’t tell you how much your blog has already helped my understanding.

-kevin