Page Comparison

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).

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

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.

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.

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 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.

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.