Child pages
  • Shawn CAS and SAML
Skip to end of metadata
Go to start of metadata

SAML-compatible CAS

This document was produced by Shawn Bayern and shared on the cas@tp discussion list.

Qui melius probat, melius habet.
("He who proves the most holds the most.")


The Security Assertion Markup Language (SAML) describes a document and protocol framework by which security assertions (such as assertions about a prior act of authentication) can be exchanged. The model underlying Yale's Central Authentication Service (CAS) is compatible with SAML; this document explains how to conduct CAS authentications (including n-tier proxy authentications) using SAML queries and assertions.

One-tier authentication and single sign-on

At its simplest, CAS concerns authentication at a single application tier: a web application may use CAS to authenticate its interactive user in order, typically, to initialize a session using its own session semantics. The one-tier CAS protocol is well understood; here, I describe how to conduct this authentication by way of SAML. It is important to note that SAML is general enough to allow a variety of specific forms of interaction; this document describes one concrete mechanism. While I believe the proposed model is straightforward and reasonably parsimonious, it's by no means the only way to incorporate SAML into CAS.

The initial steps in a SAML-based CAS authentication match the traditional CAS protocol. Initially, a user contacts a web application, and because this application has no existing session with the user, it redirects the user to CAS in order to request strong authentication. Following this redirection, the user's browser contacts CAS and conducts a primary authentication with CAS, at which point CAS redirects the user back to the service that requested authentication, supplying information in the query string sufficient for the application to verify the authentication.

You might wonder why I don't make an effort to incorporate SAML into this initial step of the protocol. SAML is designed to convey assertions about security; in the realm of authentication, such assertions involve prior acts of authentication. For instance, section 3.3.3 of the SAML specification, which describes a SAML query embodied in an <AuthenticationQuery> element, gives the following warning to SAML implementations:

The <AuthenticationQuery> MAY NOT be used as a request for a new authentication using credentials provided in the request. The <AuthenticationQuery> is a request for statements about authentication acts which have occurred in a previous interaction between the indicated principal and the Authentication Authority.

Furthermore, the nature of CAS yields little advantage in doing attempting to accommodate SAML in this initial step; for this step, the user's browser must be involved, and browsers (so far) have no knowledge of SAML. Thus, as in CAS 1.0 and CAS 2.0, we inform CAS that an authentication is needed by way of a simple HTTP redirect, and CAS informs applications that an authentication assertion is available by way of a correspondent redirect.

In SAML, there are two ways of requesting information about a prior act of authentication. A party can submit an open-ended query or can ask for an assertion based on an ID or an artifact, the latter of which has a format under the application's control. While SAML lets implementations define their own query types and would thus allow for the possibility of a custom CAS query, there seems to be no advantage to doing so. A CAS authentication is already uniquely identified by an artifact, so it is both secure and appropriate to use this artifact.

This precise methodology is straightforward. A web application, having received an opaque ticket from the incoming HTTP request (via its ticket parameter), marshals a SAML request to be sent using SOAP, over HTTPS, to the CAS server. The application contacts CAS over a well-known URL and authenticates CAS using CAS's SSL certificate (applying rules at least as restrictive as a common browser's, to prevent spoofing of CAS). Thus, no XML Signatures are necessary; the underlying channel is trusted. Over this secure channel, the application sends a SAML request of the following form:

Listing 1

When CAS recognizes the opaque ticket string sent within this request, it produces a response containing an appropriate assertion, along with supplemental information that the application will need to ensure that the ticket was intended for it and not for another application:

Listing 2

Unlike the non-SAML CAS protocol, confirmation of the assocation between a ticket and a service is the responsibility of the web application, not of CAS.
Proxiable credentials under CAS 2.0

SAML can also accommodate proxiable credentials, as supported by the CAS 2.0 model. There are three major related to proxying:

  1. Secure acquisition of a proxy-granting ticket (PGT)
  2. Secure acquisition of individual-use proxy tickets
  3. The protocol underlying the use of proxy tickets

Step 3 represents the most appropriate use of SAML, though SAML must accommodate step 1 given that secure PGT acquisition relies on the same secure channel by which authentication assertions are exchanged. This document does not address step 2, for SAML is not specifically intended for ticket acquisition; it is designed to relay assertions, and while a proxy ticket embodies an assertion (used in step 3), its acquisition (step 2) represents a service-level action (with side-effects).

To acquire a PGT using CAS 2.0's basic model, an application must authenticate itself to CAS. Under the basic CAS 2.0 model, this authentication is conducted by virtue of a callback URL; however, this complicates the model, so I will describe an alternative approach more appropriate for SAML.

This approach is straightforward. To authenticate itself to CAS when sending the request from listing 1, the application supplies an XML Signature using the <Assertion> element's <Signature<; subelement. If it is satisfied with the application's authenticity, CAS includes an <AttributeStatement> in the assertion contained in its response. This statement has the following format:

Listing 3

Once a proxy has used the PGT acquired in this statement to generate a PT (again, using an out-of-band mechanism that does not necessarily use SAML), it supplies a SAML document to its target back-end service. (It could also simply provide the ticket as a query parameter, just as in the current model; however, using SAML arguably makes it easier for a back-end service to use multiple authentication schemes.) This SAML document contains the following assertion:

Listing 4

Note that this is a potentially baseless, bold assertion; it is not trusted. The authentication of the subject is contingent upon validation of the proxy ticket supplied in the <SubjectConfirmation> element.

  • No labels

1 Comment

  1. Browser/Artifact Profile of SAML

    SAML also defines some thing called the "Browser/Artifact Profile of SAML", which describes a standard way of performing authentication with browser redirects and SAML artifacts. The method is very similar to the current CAS sequence of events, and so I think CAS could easily be modified to conform to the SAML spec.

    In theory, this would allow the CAS server to work with other SAML-compliant clients, which is a big plus if a 3rd-party vendor creates a product that supports SAML.

    The "profiles" document for SAML 1.1 can be found here:

    Here are some of the things that I've identified from the document that would need to be changed in CAS:

    Current Operation:
    Destination site redirects to CAS server and includes a parameter "service" which specifies the URL of the destination site.

    Change required:
    Change parameter name to "TARGET"
    Target must be encoded to remove "?" and "&" characters

    Current Operation:
    CAS server uses JavaScript to redirect the user back to the destination site

    SAML requires:
    Redirect from CAS server to destination site must use HTTP code 302.

    My suggestion:
    A 302 redirect has problems (which is why CAS intentionally uses JavaScript). Interaction with other SAML systems will PROBABLY still work even if this SAML rule is broken. Hopefully in the future the SAML spec will be changed in light of the problems caused by some non-compliant browsers when a 302 redirect is used.

    Current Operation:
    CAS server redirects back to destination site with URL search parameter "token=<opaque_token>" attached to the end of the search part of the URL.

    Changes required:
    Add parameter "TARGET" containing the original "TARGET" parameter, still encoded
    Change name of parameter "token" to "SAMLart"
    Note: Agents must allow TARGET and SAMLart parameters to be included anywhere in the query string.
    Note: Agents must allow multiple SAMLart parameters, though they can ignore any "extras."
    Note: Agents should probably reset the entire search part of the URL to the search part decoded from the TARGET parameter.

    Current Operation:
    The current "token" format is simply an opaque string.

    Changes required:
    The format for SAMLart is a base64-encoded concatenation of a three things:
    1) a two-byte "TypeCode" of "0x0001"
    2) a 20-byte "SourceID" identifying the CAS server (they recommend using a SHA-1 hash of server's URL)
    3) a 20-byte assertion handle (we could use an expanded version of the current service ticket)