4

I am rather stumped by trying to identify where CAC/Active Directory(AD) authentication comes into play for Java based web applications. Take for example multiple J2E JSF applications hosted on multiple Weblogic containers. Each of those applications limits access of the user by checking what AD role they are in. At what stage does one perform CAC/AD authentication, if all of these applications require it?

It was my understanding that ideally, you want a gateway seperate from your applications that does the authentication. A simple example is F5 hardware/sotware bundle. Once the user authenticates with their CAC/pin combo, they are forwarded to the deployed application on Weblogic, with some additional information in their headers(like the AD roles previously mentioned). I am not saying that I should purchase that as there is no programmable solution, rather as an example that authentication and resources of use are two seperate entities, and should not necesarily be combined for this problem.

In practice, however, I have read that many projects are combining Microsoft and Apache services to allow authentication. Here is a good blog post that outlines some benefits. Once a user authenticates against IIS, they are forwarded to the application on apache. Regardless, mixing IIS and Weblogic just seems like a bad idea off the bat, especially when trying to configure the communication betweem the two nodes.

There are also numerous posts on stack and the web, dating back to pre 2012 days, which reccomend different solutions. One post recommends the following:

you can specify set of acceptable certificate policies when the server validates the client certificate

While the answer makes sense in general terms, the author never goes into architectual details for this communication to take place. Some other posts reccomend JOSSO, to perform SSO functionality like the gateway mechanisam previously mentioned. This post also talks about using PKCS11 for reading smart cards directly by using the manufacturer provided drivers. There are also questions that have no answer, such as Authenticating AD server user using DOD issued CAC in java .

Considering it has been, on average, 5 years between some of these posts, I am unsure what todays best practice is for this problem. Is the gateway approach an ideal way to do authentication? Are my ideas not applicable at all and a better solution exists?

Community
  • 1
  • 1
angryip
  • 2,140
  • 5
  • 33
  • 67

1 Answers1

5

It took me some time to extract the questions, so - what are you trying to achieve? But - lets try:

As you've mentioned CAC/AD - I will assume there each client needs its own keypair and signed certificate. And you want to achieve SSO (single-sign-on) using the smartcard (which can host the keypair and the certificate).

Where is smart card authentication done for Java Web apps?

The smartcard often serves as a keystore (accessible as PKCS11 keystore). It may contain several keypairs and certificates. How it is used - the web browser (most of them) can use the smartcard certificate to establish the mutual (2-way) SSL with a server.

The common practice is to terminate the SSL on a web server / proxy and the certificate information (DN) is passed to the backend service as an HTTP header (e.g. x-client-cert). F5 BIGIP is a very good tool, we use Apache or Nginx very commonly for this purpose as a simpler and cheaper option.

Note:

  • You can set-up the Weblogic to directly support the client certificate authentication, but I'd advice to use a proxy (F5, Apache, IIS, ...) so you manage the trusted CAs at a single point.

A completely different question is how do you convert the HTTP header into the user principal (identity) and its permissions / roles. You can write a servlet filter for this purpose, but for larger deployments you could use an identity server (F5 APM, WSO2 IS, OpenAM) effectively converting the client certificate information into the user identity provided by other protocols (SAML, OAuth, ..)

At what stage does one perform CAC/AD authentication, if all of these applications require it?

Technically - when establishing the SSL connection. So whether you provide the client certificate information to the proxy or an identity server - it is not important, the important part here is that this information is provided to all other applications (as an HTTP header behind a proxy or a claim usign SAML, OAuth, ... other authentication).

Is the gateway approach an ideal way to do authentication? Are my ideas not applicable at all and a better solution exists?

The gateway approach is very common and reliable. Do not forget to sanitize the HTTP headers before passing any information.

Another option is using an identity server, which gives you advantages integrating with external (cloud) services. However - it is a separate server with all hassles around (deployment, maintenance, knowledge, ...)

Another option - you may require a smartcard to log on into the AD client workstation and then use ordinary SPNEGO (Kerberos) SSO :)

I hope it helps, carpe diem

gusto2
  • 11,210
  • 2
  • 17
  • 36
  • Thanks for the feedback. You are certainly answering the questions I am asking in the question. The question I had about your post regards to this statement "The common practice is to terminate the SSL on a web server / proxy and the certificate information (DN) is passed to the backend service as an HTTP header" Does this mean that the SSL is not used between tomcat and F5 for an example, so that those headers can be read? I have talked to the F5 guys before, and supposedly its possible to pass and decode ssl information where tomcat and f5 can communicate. But, I do not know much about this – angryip Apr 07 '16 at 14:10
  • The client certificate is part of the SSL only to the first SSL termination endpoint (F5). The F5 can extract the certificate and set it as an HTTP header using an iRule. In many cases the traffic behind F5 is considered secure and not necessary to encrypt. However - you can establish an ordinary SSL channel between F5 and your app server (Tomcat). Just the client (user) certificate is further passed as an HTTP header and your application needs to trust the header value. – gusto2 Apr 07 '16 at 14:15
  • Just to make sure I understood you correctly, if you establish the ssl channel between F5 and tomcat, than the headers you are receiving from F5 on tomcat are encrypted and decrypted using the certificates between those two entities. This is definitely desirable, because I honestly don't think that the client certs should be propagating to the application, unless they are needed. I'd rather my app trust F5 certs that we agree on, as opposed to manage relationships between clients. – angryip Apr 07 '16 at 15:01
  • Basically you are right. There shouldn't be direct "tunnel" between the user client and the application itself. F5 can do a lot of security, load balancing, offloading, .. You need to propagate the client certificate information to the app server (in form of a header), but not the SSL connection (please don't mix these). – gusto2 Apr 07 '16 at 15:04
  • Exactly. I now understand you completely. Thanks for taking the time to provide a writeup. – angryip Apr 07 '16 at 15:10