Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updated for CAS 6.3.5

Contents

...

Info
titleThe UH Web Login Service is provided via Apereo's Central Authentication Service (CAS).

Currently UH Login is running CAS version 56.03.105.

Please refer to Apereo documentation for authoritative references for CAS client integration and the CAS protocol. The CAS Community mailing list and archives are also valuable sources of information and support.

Additional  info

This information was derived from Apereo's :

, Apereo's , and .

Anchor
select
select
Before You Register Your Application URL …

...

  1. Will authentication include the release of attributes to your application?
    1. If yes, UH Data Governance guidelines apply.  For each unique application you must submit a separate request.  What that means is that you cannot register a single URL and host multiple applications under it.  
  2. Is your application hosted on a non-UH server?
    1. If yes, your request may be subject to the UH Data Sharing Request process. Please send an inquiry to datagov@hawaii.edu or call 956-7487.

Anchor
register
register
Register Your Application URL

...

Info
titleCAS clients

Note that CAS clients are available that handle many of the login and ticket validation details for you. If your development can make use of one of the available CAS clients (eg, Java, PHP) you will probably want to take advantage of them rather than trying to reinvent the wheel.

Anchor
login
login
Log in Securely: /login

...

Note
titleCAS /logout will affect applications other than your own!

Note that use of /logout may affect any other application that is also using the CAS Single Sign-On (SSO) session. Other applications may share the same CAS SSO session that is terminated by the use of /logout, and their SSO session will likewise be terminated as well when the ticket granting cookie is destroyed.

Please refer to the CAS reference documentation for a more extensive discussion of this issue.

Parameters
  • service (OPTIONAL)
    • the identifier of the service to redirect to after logging out
    • the service parameter must be also be a registered service URL
  • url (DISABLED)

    Note

    Although Aperero's CAS protocol documentation describes the use the the url parameter, the Aperero developers have disabled it in recent versions of CAS to prevent potential abuse. Their explanation of the situation may be found in this thread from the cas-users mailing list. The url parameter defined in the former CAS 2.0 specification is not a valid parameter in CAS 3.0 anymore. CAS Servers MUST ignore given url parameters.


Examples
  • To logout a user and prevent her from automatically logging back into a Web application, the Web application can forward the user to the Logout URL of UH Login. That URL will destroy the ticket-granting cookie that enables the single sign-on feature and gives the user a page that informs them that they have logged out of UH Login.

    No Format
    https://$WEBLOGIN-HOST/cas/logout
    


  • To logout a user and prevent her from automatically logging back into a Web application, the Web application can forward the user to the Logout URL of UH Login. That URL will destroy the ticket-granting cookie that enables the single sign-on feature and redirect the user to the URL identified by the service parameter.

    No Format
    https://$WEBLOGIN-HOST/cas/logout?service=https://myserver/myapp
    


    Info

    The URL provided by the service parameter must be registered to use UH Login.


Note
titleSLO to be disabledis not unabled
Because SLO may affect other applications using SSO[*], it
will be disabled in future deployments of CAS.

It is currently disabled in the following CAS environment:

  • https://cas-future-test.its.hawaii.edu

This will be consistent with the SLO policy already in effect for our Shibboleth IdP SSO service.

has been disabled as of the implementation of CAS 6.3.5.

[*] From the CAS documentation for Single Logout (SLO):

When a CAS session ends, it notifies each of the services that the SSO session is no longer valid, and that relying parties need to invalidate their own session. Remember that the callback submitted to each CAS-protected application is a notification; nothing more. It is theresponsibility of the applicationto intercept that notification and properly destroy the user authentication session, either manually, via a specific endpoint or more commonly via a CAS client library that supports SLO.

Also note that since SLO is a global event, all applications that have an authentication record with CAS will by default be contacted, and this may disrupt user experience negatively if those applications are individually distinct from each other. As an example, if user has logged into a portal application and an email application, logging out of one through SLO will also destroy the user session in the other which could mean data loss if the application is not carefully managing its session and user activity.

...

Anchor
clients
clients
Sample Clients

...

...

Anchor
JavaCASclient
JavaCASclient
CAS client for Java

Aperero provides a an example of SAML 1.1 Ticket Validation Filter.

...

Application Not Authorized to Use UH Login

Problem:

Your application cannot successfully authentication against CAS.

Example error message:

Panel

The application you attempted to authenticate to is not authorized to use UH Login.


Solutions:

Expand


Panel
  • If you have requested attributes, make sure you are using https.
  • Check that the URL matches the URL specified in your original CAS URL registration request.
    • Common errors
      • Adding or leaving out "www" not in registered registered URL
      • Using "http" as the protocol rather than "https"


...