...
Synopsis:
| Excerpt |
|---|
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.
...
| Panel |
|---|
| title | attributes on the requests in the CAS protocol |
|---|
|
| Notetip |
|---|
| 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.
|
| Note |
|---|
| 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.
|
|
...