2005.01.24 Yale CAS discussion

Yale CAS Discussion

Present: Howard Gilbert, Drew Mazurek, Andrew Petro

Synopsis:

Shibboleth/CAS integration. SAML. CAS 3 protocol.

The main topic of this meeting was how to integrate Shibboleth into CAS. After some discussion, Howard convinced us that CAS will, in effect, become a WAYF (Where Are You From?). An application that chooses to accept credentials from Yale and other Shibboleth entities would convey this information to CAS upon the login redirect. CAS would then allow the user to somehow specify they are a remote user, and where they are from. This could be done either with a pulldown or with some namespace distinction such as "@harvard.edu" appended to the username. If the user is remote, they will be redirected to their own sign-on system to present credentials which will be forwarded through Shibboleth to the "Local Shib Authority." Remote users will not provide their password to Yale CAS directly. They provide their username only for the purpose of helping determine what Handle Server they ultimately end up at.

CAS and Shibboleth game

Yale application

Some application that accepts authentication of both Yale users and users that are not Yale users but are remote users – users who can authenticate to some other Shibboleth-hosting institution within the Federation. To give our story flavor let's say it's a web application for registering your computer to receive a routable IP address.

(redirects to, specifying on redirect URL that remote users are acceptable)

Yale CAS

Provides local user login UI and provides some WAYF mechanism whereby non-Yale users can specify at which institution they can authenticate.

(Yale CAS redirects to Handle Server of institution user selects. Let's say the user is a Rutgers student. Yale CAS places on the request attributes declaring the URL of Yale's Shire (see below) and as the target its own URL, since Yale CAS is serving as the target of Rutgers Handle Server authentication).

Rutgers Handle Server

Itself provides or is fronted by local authentication UI. In Rutgers' case, this is likely CAS. User authenticates to Handle Server (e.g., by authenticating to a local CAS instance and passing through the CAS Java Servlet Filter in accessing the Handle Server).

User authenticates to Rutgers Handle Server. Rutgers Shibboleth directs the user's web browser to post the handle to Yale's Shire (Authentication Assertion Consumer Service).

Yale Shire

Yale's Shire receives the handle and calls up Rutgers Attribute Authority to get the attributes for the user.

Rutgers Attribute Authority

Rutgers Attribute Authority executes an Attribute Release Policy to release attributes for the authenticated user to the target "entity". Here the target "entity" includes Yale's shire.

After Yale Shire receives the user attributes, it redirects the user's web browser to Yale CAS, including on the redirect the equivalent of a ticket.

Yale CAS

Yale CAS reads the ticket off of the request, calls up Yale Shire to get a SAML response representing assertions about the authenticated user and his attributes. Yale CAS stores internally this information and generates a Service Ticket.

Yale CAS redirects to the original application.

Yale application

The application receives a browser request bearing a CAS ticket. It validates the ticket. It elects the CAS 3 validation protocol, which will represent the validation response as SAML. Note that Yale application's role here is almost certainly played by a Java CAS Client filtering the request for Yale application.

Yale CAS

Yale CAS serves as a local Shib authority. It applies an Attribute Acceptance Policy (we drop Rutgers' assertions that the user is a Yale Professor – only Yale can assert that.) It applies an attribute translation policy (Rutgers called the attribute "phone_number" but round here we call it "phone". Perhaps it applies an Attribute Release Policy specific to the application validating the ticket (since the SAML request for validation was signed by the Yale Application we know its identity). Rutgers may have released the user's cell phone number, trusting Yale Shire to locally apply appropriate attribute release policies. Yale CAS was the target of Yale Shire, and Yale Shire trusted CAS to in turn apply appropriate release policies, so the "appropriate release policy" it applied was to delegate responsibility for this to Yale CAS.

Yale application

The Java CAS Client (or other CAS client) translates the SAML authentication response sent by CAS into something the application can consume (set the REMOTE_USER header, place some information in the session, certainly expose the raw SAML response somewhere). The application receives these artifacts and consumes them – which might be as simple as taking the authenticated username as a local username and using it, and might be as complicated as then applying a complex local access control policy considering various assertions in the SAML authentication response.

The "Local Shib Authority" will do three things: translate attributes from eduPerson to local (e.g. "phone" to "phoneNumber"); filter the attributes, passing through only those that we are willing to accept; and manage the federation – what other schools do we trust?

The discussion then turned to the specific attributes that will be passed on login and validation. Below is a transcription of the whiteboard:

Login:
    what authn is okay?
    gateway? renew? remote user? auth types (cert, kerb, etc.)?
    "service"

Validate: "opt into SAML"
    /samlValidate
        POST
    SAML Request:
        ticket
        what attributes are desired?
        [access control] rule
    SAML Response:
        netid, renew, "service",
        how, attribs, perms (boolean) [access control rule satisfied?],
        PGT

attributes on the requests in the CAS protocol

Login

Login includes advisory attributes that help CAS to present its end user experience. These attributes must not have security implications because they are succeptible to end user manipulation (are passed through a redirect on the user's web browser).

service — specifies the identity of the service for which a Service Ticket is desired. Also the URL to which CAS redirects the web browser after a succesful authentication.
gateway — specifies whether CAS must immediately redirect back to the service. When true, CAS must not render any login pages but must instead immediately redirect back to the service desiring CAS authentication, either having succeeded in authenticating the request without rendering a login screen (single sign on) and including a corresponding service ticket or failing to authenticate the user and including no ticket.
renew — specifies whether Single Sign On authentication is acceptable or whether CAS must re-render the login screen providing the user an opportunity to present primary credentials anew. Without this feature, CAS would provide users the bad user experience of failing to render the login screen, redirecting the user back to the application, and yet having authentication fail because the ticket ultimately will not be accepted by the application.
authnTypes — something new which allows applications to specify which types of authentication will be acceptable to them when they read the SAML authentication response they will ultimately receive from CAS. This allows CAS to not render the username/password login page when an application will only accept authentication by client certificate. This parameter – or another – would also be the mechanism whereby an application would let CAS login know whether remote users (users authenticated by means of other institutions in the Shibboleth Federation) are acceptable. This would allow CAS to render the UI for WAYF selection only in the case where doing so has a chance of being helpful to the user in authenticating to the application he is trying to access.

Validate

CAS 3 ticket validation involves the client application composing a (potentially signed) SAML authentication request, posting that request to CAS, and then receiving from CAS a signed SAML response. Encoded in the request are:

ticket — the Service Ticket being validated.
service — the service to which the ticket is expected to authenticate. (Note: we could drop this, instead including the service in the SAML response and requiring the client application to check that the service to which the ticket authenticates is a service the client application is prepared to provide).
renew — in CAS 2.0 the requirement that the ticket was vended in response to an immediate presentation of primary credentials was communicated by a request parameter on ticket validation and enforced within CAS Server. In CAS 3, we can drop this from the request and instead include this information in the SAML authentication response, making it always available to client applications and allowing client applications to make the decision about whether it wants to then redirect back to CAS to require presentation of primary credentials.
attributes — the authentication request might communicate which attributes the client desires CAS to include in the response. In the case where no attributes are desired, CAS can avoid doing a needless attribute lookup.

The discussion then turned to a local "strong" PKI database. For a PKI to be secure and useful, certificates must be issued by a trusted source that actually verifies recipients and does not hand out certificates carelessly.