Versions Compared

Old Version 14

changes.mady.by.user Andrew Petro

Saved on

compared with

New Version 15

changes.mady.by.user Andrew Petro

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Panel
titleattributes on the requests in the CAS protocol
Notetip
iconfalse
titleLogin

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
iconfalse
titleValidate

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.

...