Cosign Solution

Cosign is an open source project recently developed at the University of Michigan to provide a secure single sign-on web authentication system.

Source: http://www.umich.edu/~umweb/software/cosign/

Components and Roles Cosign Server

The Cosign server is made up with two service modules: the “CGI” module and the “Daemon” module.

The “CGI” module handles most of the user interface for user to login and logout of the central Cosign server. It is also responsible for registering each service a user logs into which will tie the user's central login cookie to their session on individual application servers.

state of all user sessions and keeping track of all of the service cookies that represent the web applications which the user has accessed.

Filter

In cosign parlance, “the authentication filter is the piece of software required on a web or application server to participate in the single sign-on & proxy environment.”

Cosign system uses a filter to determine the protected web resource. The filter is responsible for assuring the user is authenticated when he/she requests a restricted service. The filter is also used to collect the user’s authentication information which will be used by some authorization mechanisms for further access decisions.

Authentication Model

Figure 3.2.4-1 unauthenticated access to protected Web resource 1. An unauthenticated user attempts to access a protected web service.

2. The authentication filter on this service checks for the existence of a service cookie. As the user has not visited this protected service before, there is no service cookie presented. So, the authentication filter generates and sets a service cookie, then redirects the user to the Cosign server.

3. The Cosign server checks if this user has a valid login cookie set. As there is no login cookie exists, the service cookie register fails. The Cosign server generates and sets a login cookie, then presents a login form to the user.

along with the login cookie and the service information.

5. The Cosign server verifies the credentials. If authentication succeeds, the server associates the login cookie with the service cookie, and re-directs the user back to the original URL requested, along with the service cookie.

6. The application filter checks the service cookie with the Cosign server. The server verifies that the user is actively logged in and returns the userID.

7. The cosign filter checks response message, grants user permission to access the service he/she originally request, and caches this information as necessary, so it doesn’t need to access the Cosign server to validate every request to the web resource.

After successful login to the central Cosign server, Cosign's SSO feature allows the user to get authenticated with other protected web resource without re-entering password.

Figure 3.2.4-2 single sign-on after initial authentication 1. An authenticated user issues a request to access a protected web service.

2. The authentication filter on this service checks for the existence of a service cookie. As the user has not visited this protected service before, there is no service cookie presented. So, the authentication filter generates and sets a service cookie, then redirects the user to the Cosign server.

3. As this user already has a valid login cookie set, the Cosign server check the login cookie, associates the login cookie with the service cookie, and re-directs the user back to the original URL requested, along with the service cookie.

verifies that the user is actively logged in and returns the userID.

5. The cosign filter checks response message, grants user permission to access the service he/she originally request, and caches this information as necessary, so it doesn’t need to access the Cosign server to validate every request to the web resource.

Logout

Users can logout of all Cosign-protected services by visting a centralized logout URL.

Security Overview

Cosign is a single sign on system which is designed to allow access to restricted websites using a centralized sign on mechanism.

Cosign SSO solution has a very special architecture. It issues both the login cookie and the service cookie before the user is validated. Users only need to send the password to the central Cosign server via SSL. Once the authentication succeeds, these two cookies will be associated with internal state.

Unlike other cookie-based SSO solutions, Cosign does not use a domain or public cookie to allow cross-server authentication. Both the Cosign server and the departmental web servers have their own cookie. All the Cosign cookies are host cookies that only the originating host could get them back. This means, a compromise of a service will only affect that service but not the whole system. All the cookies which are used in the system only contain the session keys without users’ data. The service keys and authentication keys are 93-byte base64 encoding of randomly-generated strings, even if compromised, no sensitive information about the user or service will be revealed.

3.2.5 Solution Comparison

This comparison mainly focuses on the reliability and security based-on the solution designs. As all the systems are still in development, they may well change over time, so this table should only be treated as an indicator.

Reliability

Passport It will be vulnerable both to the network and server failures. (As the "granting cookie" is signed by login server’s private key, and encrypted by the symmetric key shared between the application server

and login server, the server failure will invalidate all the authentication cookies).

WebAuth It will be vulnerable to network failure.

Strong resilient server capability (As the cookies are still in the browser and not tied into the login server, even if the server is down, existing sessions do not need re-authentication).

CAS It will be vulnerable both to the network and server failures. (The CAS server holds a credential cache in the server memory. The server failure will cause all cookies in use become invalid and re-authentication of all user sessions will be required.)

Cosign Strong resilient server capability (As the cookies are still in the browser and not tied into the Cosign server, even if the server is down, existing sessions do not need re-authentication).

Security Passport Using the Triple DES encryption scheme.

Passwords are only sent to the central Passport server protected by SSL.

WebAuth Passwords are sent only to the central login server over SSL.

Communications between the browser, the application server and the login server use SSL.

Shared symmetric keys are used to encrypt tokens between the login server and application servers; servers’ private keys are used to encrypt tokens so only this server could decrypt it.

Both the application server and login server use randomly-generated 128-bit AES keys to encrypt their tokens.

CAS ♦ Passwords are sent only to the CAS server protected by SSL. ♦ All the communications with CAS server is over SSL.

♦ No domain cookie is used in this system. All CAS cookies are host cookies sent only to the originating server that set it. So, a compromised service host will only affect that service without representing a compromise of the whole system.

user or service will be betrayed. ♦ Sessions only has hard timeout

Cosign ♦ Passwords are sent only to the central Cosign server over SSL. ♦ Communications between the browser and the authentication

filter and Cosign server are protected by SSL.

♦ No domain cookie is used in this system. All Cosign cookies are host cookies sent only to the originating server that set it. So, a compromised service host will not represent a compromise of the Cosign system as a whole.

♦ All the Cosign cookies only contain the session keys which are randomly-generated strings, even if compromised, no sensitive information about the user or service will be revealed.

♦ Session have both idle timeout and hard timeout.

3.2.6 Summary

Both the Passport and the WebAuth use a very similar architecture. They make use of a central authentication server which shares the symmetric keys with each application server for encrypting and decrypting the tokens sent, so only the recipient can read the contents.

Figure 3.2.6-1 high-level architecture of Passport and WebAuth solutions Passport is one of the most widely used web SSO solution in the world. But its old

design has a series of security weaknesses such as Cookies problem, Key management, and etc. There are also a number of different ways to attack to the Passport, e.g. Fake merchant attack, Active attack, DNS attack and Cookie attack. David P. Kormann and Aviel D. Rubin give an itemized analysis in their paper” Risks of the Passport Single Sign-On Protocol”. [14]

WebAuth uses randomly-generated 128-bit AES keys instead of using the Triple-DES encryption scheme, which seems a little more secure than Passport solution. Moreover, WebAuth could use a real Kerberos authentication, which means: the cookie shared with the login server really isa Kerberos ticket-granting ticket and the cookie issued for access to an application server really is a Kerberos service ticket. This could solve many of the security problems associated with ticketing systems.

Both Passport and WebAuth use a widely scoped cookie to transfer the authentication assertion between the login server and the target application server. As all the information about the authenticated user is kept on the user’s browser in the form of cookies, the departmental application server does not need to communicate with the central authentication server to validate the cookies. This makes the authentication server is very distributable and thus the whole system is high scalable.

But unfortunately, this stateless design also brings some relative security limitations. The cookie which the application server consumes may contain some sensitive information about the user, and it can be read by any web server in the domain, so, any vulnerable server could compromise it. Browser hacks and cross-site scripting attacks, for instance. The ability to intercept a cookie and use it for an attack is a weakness in this architecture.

And let’s assume what will happen if any one of the shared secret keys between the authentication server and application server is compromised. In the worst case, it might give hacker access to the users’ authentication tickets, and then it would be catastrophic as the whole system is compromised.

Unlike the two web-SSO solutions mentioned above, Cosign and CAS do not use a domain cookie to allow cross-server authentication. Both of them have a real good design.

Figure 3.2.6-2 high-level architecture of CAS and Cosign solutions

CAS and CoSign also use the cookies, and just like other cookie-based solutions, they are technical vulnerable to some attacks too. But the cookies they use only contain a random key, even if it is compromised, no confidential information about the user or service will be revealed. So, this architecture seems more secure as it is impossible for an attacker to obtain any sensitive information relating to the users or sessions from the cookies.

The biggest drawback of these two solutions might be the lack of technical documentation, especially the Cosign solution. I can find nothing valuable on its website except an overview and the source codes, so it’s a little hard to get the technology details of this solution.

In CAS solution, all the CAS credentials are cached in the CAS server memory and can not be retrieved from the hard disk. The session cookies in the browser are random strings which are simply an index map onto the user in the credentials cache. So, if the CAS server fails down, all the browser cookies in use will become invalid, and re-authentication of all user sessions will be required. This causes a “single point of failure” problem. However, this design can also provide some benefit. If some users refuse to accept cookie, it will only reduce the SSO functionality of CAS, but will make all the other cookie based solutions unusable.

Moreover, the design of ST probably is the best feature in CAS solution. ST is a one-time-use-only opaque and will expire as soon as the web application verified it. The web application only handles its own ST.

Although someone might think that CAS heavily relies on the J2EE application server could be a big burden, as in my project, the existing application system is also JAVA-based and we do not need additional cost to set up the J2EE environment, so this shouldn’t be a big trouble.

As we see from the descriptions and the tables above, each of the solution has particular strengths and weaknesses. We should carefully consider the existing environment before choose a particular SSO solution.

3.3 Technology Requirement

Before we start our project, there are some important techniques we should understand: the HTTP communication between the client and server, the implementation of safe redirection, the use of secure sockets layer and secure cookie.

3.3.1 HTTP Client-Server Communication

The Hypertext Transfer Protocol, an application-layer protocol, is one of the most important parts to implement the World Wide Web. HTTP is primarily used to transfer hypertext documents and other files from Web servers to Web clients. [15]

“HTTP is a client/server-oriented, request/reply protocol.”

The simplest communication consists of an HTTP Request message sent by an HTTP client to an HTTP server, and an HTTP Response message returned from the HTTP server back to the HTTP client. When a TCP connection is set up, the HTTP communication takes two steps which are described as follows:

1. Client Request:

The client sends an HTTP request message which is formatted according with the HTTP standard. This message specifies the target resource that the client wants to interact, and optionally contains some information to be provided to the server. 2. Server Response:

The server receives the HTTP request and interprets it. Relative to the HTTP request, it takes some operations, creates an HTTP Response message and sends it back to the original client. This HTTP response message indicates whether the request succeeds or fails, and optionally contains some appropriate information that the client requested.

Figure 3.3.1 Basic HTTP Client/Server Communication

3.3.2 Safe Redirection

A redirection is a type of command sent from the server that directs a browser to another location. In most SSO solutions, it is used to send unauthenticated users from web application to the central authentication server, and send them back to the original application after authentication succeeded. Generally speaking, most redirections are transparent to the end-users.

There are two ways of user redirection using Java: using the HttpServletResponse object's sendRedirect method or sending HTML and JavaScript to the client, which initiates a POST. The second one obviously has strong advantages when compared to the first one. First, the HTML form action is a POST which means the query string information is not visible from web browser. This efficiently hides the full URL and prevents the reply attack by copying-and-pasting the URL string. Second, using HTML and JavaScript, there is no restriction on the amount of information which can be passed to the server. [16]

When a user is redirected from generic application server to central authentication server, he/she usually may send the following information:

1. Action: what the member server wants, for example, authentication. 2. Return URL: original URL to the requested resource.

3. Server identifier: the identity of the application server.

3.3.3 Secure Sockets Layer (SSL)