Certificate to User Mapping in WebLogic
A reader of my Fifteen Minute Guide to Mutual Authentication post commented that perhaps the burden of doing mutual authentication (two-way SSL) isn’t worth the effort since you still have to map certificates to users. I’ll admit, that does seem like a bummer.
However, since most companies already have a list of users in LDAP or a database it’s probably not a big deal most of the time. WebLogic has several authentication providers that you can use to tap into your existing user store. Still, I think it’s a great question worth exploring so let’s consider what’s involved.
Having the user provide a certificate to the server is a form of strong authentication. No password traverses the network and the user must possess the certificate file. It’s extremely difficult to spoof a user due to the cryptography involved. The user is most definitely authenticated when the two-way SSL link is successfully created. In other words, they are who they say they are assuming you trust the Certificate Authority (CA) who signed their certificate.
Strong authentication alone is the primary benefit of using mutual authentication, of course. The user is who they say they are. We now need to turn our attention to authorization so that we can determine whether or not they can access the system.
If you don’t want to maintain cert-to-user mappings you can leverage WebLogic’s implicit groups. See the link for more info but you could use the “users” group to authorize users without maintaining a user list. The “users” group represents any authenticated user. When using mutual authentication, any user identified by their certificate will automatically be in this group. If you can get away with one role in your application then the “users” group may work for you. However, be sure to read about CAs below.
Certificate Authority Scope
The huge drawback to using the implicit “users” group in this way is that any certificate signed by the CAs you trust will be acceptable to your application. If you’re using the default JDK truststore “cacerts” you’ll wind up trusting the signed certificates of all the major and a ton of minor CAs from around the world.
The fix, of course, is if you control the CA. For example, if your company has a CA, you can configure your truststore to only have that CA’s certificate. Then, you only accept users from your company (and partners if they get certs signed by your company’s CA).
In this scenario you will still allow anyone signed by the company’s CA to have access to your app. Whether that’s acceptable or not is a business decision. If you go this route make doubly sure that you ONLY trust your company’s CA.
When you don’t have a list of users how do you deny them access when they quit?
Revoking the certificate is the obvious answer. Checking certificate revocation requires a custom security provider and is outside the scope of this article. However, the implication is that your public key infrastructure must be mature enough to have OCSP or CRLs for you to check revocation in the first place.
To summarize, it is possible to use mutual authentication without maintaining a list of users. However, you need to exercise extreme care when doing so. Also, authorization flexibility is reduced to just one possible role since there’s only one group to which to map.1
1. Technically, you can do the mapping to multiple roles if certain preconditions exist and you’re willing to do some extra work. As an example scenario, let’s say you use your own CA. Your CA uses OU fields in the DN which you might be able to leverage for role mapping. You’d have to write your own authentication provider to add groups to the subject based upon the OU information and then you can map the roles to the groups as usual in your application’s deployment descriptors.