SSL Background

SSL client authentication provides a way to authenticate clients with SSL certificates. It is most often used to authenticate application-to-application connections; however, most web browsers support authenticating the user with with a certificate. This browser authentication can be used to authenticate who have certificates stored on security tokens. This is not very common and there are a few issues to understand.

The Connection Process

The SSL Authentication process begins with a connection between two peers. A peer wishing to identify itself presents its certificate to the other. The peer receiving the certificate must determine if the certificate presented belongs to an authorized user by some combination of the following:

  • Check one or more attributes in the certificate (usually DN or CN).
  • Determine the authenticity of the certificate by checking the issuing CA's signature.
  • Check that the issuing CA is authorized for the application (a Trusted CA).

In addition to determining if the peer is authorized, it must also be authenticated. Once the certificate is determined to be valid, the peer being authenticated presents data signed with its private key which the other peer decrypts with the public key from the certificate. This authentication process proves that the peer being authenticated has a copy of the private key. (With hardware tokens, these keys cannot be copied from the token. The token is presented with the data to encrypt and returns the encrypted data.)

Every time a user connects to a SSL web service, the user's browser authenticates the remote server. If any of the authentication steps fail, the user is presented with a dialog showing the problem and giving the option to continue or abort the connection. SSL client authentication repeats the above process with the roles reversed. The web server authenticates the client.

The steps above involve a good deal of computation (public-key operations). In addition to the authentication/authorization steps the peers must also calculate the session key (symmetric) and negotiate several other parameters.

SSL Session/Context

Many client/server applications involve a large number of short-duration connections, e.g. the typical browser to SSL web application interaction. The computational overhead of establishing an SSL connection makes maintaining some persistant state that allows much of the connection establishment overhead to be avoided on subsequent connections highly desirable. This persistent data is usually represented as an SSL session or context. If a peer presents a valid session identifier, the connection can be established without renegotiation of all parameters.

SSL Libraries and Modules

Most of the important SSL functionality is implemented by libraries that make the SSL process fairly transparent to the application. The application configures various SSL parameters and usually doesn't get involved with the details of connections and sessions. In many applications, a module or plugin is used to configure the SSL parameters and the application may be totally unaware that SSL is being used at all. In the case of Apache, mod_ssl performs this function. When used for client authentication, an application on an Apache server is presented with what appears to be a user authenticated with any other authentication method. Read access to many of the SSL parameters are available to the application via environment variables.

It is important to note that all of the SSL connection and session management takes place before the application has access to the connection. For example, session cookies set by the application can only be examined after the connection is established. The cannot be used as part of the SSL connection process.

Security Implications

A web application generally uses one of two ways to perform authentication. First, it may rely on the web server/container to perform the authentication and present it with the authenticated user name. The advantage of this is that the application does not need to be concerned with the details of authentication (i.e. using a password file, LDAP, etc.). The actual authentication method can be changed or reconfigured without modifications to the application. Second, the application may perform the authentication and session management itself. In this case, the application may present the client with a form to be filled out with user name and password, validate those credentials itself, and track the session with a browser cookie.

The first method provides the most convenient way for using SSL client authentication.

  • What happens if the application returns auth required?
  • Application does auth basic?

CAS Specifics

First Authentication (CAS Login, Service Login)

  • An un-authenticated user accessing a CAS-authenticated service is redirected to the CAS login URL.
  • The CAS server authenticates the user and sets a TGT cookie in his browser.
  • The CAS server redirects the user's browser back to the original application with the addition of a CAS service ticket (ST) parameter to the URL.
  • The application validates the ST, sets an ST cookie in the user's browser, and allows access.
  • Access is allowed to the application without re-authentication so long as the ST is valid.

Subsequent Login (Logged into CAS, Service Login)

  • A user is considered to be logged into CAS (service) if he has a valid TGT (ticket granting ticket).
  • An un-authenticated user accessing a CAS-authenticated service is redirected to the CAS login URL.

Notes

  • Certificate/key
  • TLS/SSL
  • encrypt/sign
  • No labels