Contents

• Overview
• Before You Register Your Application URL
• Register Your Application URL
• Web Login process
  • Conventions & Definitions
  • CAS URIs
  • Login Securely
  • Ticket Validation (CAS protocol 1.0, AuthN, simple text response)
  • Ticket Validation (CAS protocol 2.0, AuthN, XML response)
  • Ticket Validation (CAS protocol 3.0, AuthN with attributes, SAML response)
  • Logging Out
• Access Control
• Sample Clients
  • Java CAS client
  • UH CAS Demo in Java
  • phpCAS
  • cURL (no attributes requested)
  • CAS Authentication with Spring Security
• Frequently Asked Questions
• Troubleshooting
• Technical Support

Anchor
overview overview

Overview

...

UH Login also provides Single-Sign On (SSO) capabilities. 

...

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

...

Append the following as needed:

• Login securely
  • cas/login
    • provides service ticket
• Ticket validation
  • cas/validate
    • Use HTTP GET
    • CAS protocol v1.0
    • response is text delimited by <LF>
  • cas/serviceValidate
    • Use HTTP GET
    • CAS protocol v2.0
    • response is XML
  • cas/samlValidate
    • Use HTTP POST
    • provides attributes
    • response is SAML 1.1
• Logout, destroy service tickets.
  • cas/logout

If your service is only interested in authenticating users and will not require a user object of released attributes, you should use either cas/validate or cas/serviceValidate. Their responses

...

...

• Redirect the client to the URL specified by the "service" parameter with a service ticket in a manner that will not cause the user's credentials to be forwarded to the your web application. The client uses the ticket provided as a parameter to one of CAS's validation methods.
  • cas/validate
    • Use HTTP GET
    • CAS protocol v1.0
    • response is text delimited by <LF>
  • cas/serviceValidate
    • Use HTTP GET
    • CAS protocol v2.0
    • response is XML
  • cas/samlValidate
    • Use HTTP POST
    • provides attributes
    • response is SAML 1.1

...

• url (DISABLED)

  Note

  Although Jasig's CAS protocol documentation describes the use the the url parameter, the Jasig 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.

...

Anyone that is in the UH Core LDAP Directory Service. In other words, current people in the UH System (ten campuses, system offices, some RCUH employees) and visitors (temporary guest accounts) managed by VIA. See the overview 13402875 above.

Why is the UH CAS Server sending requests to my webapp?

...

Application Not Authorized to Use UH Login

Problem:

Your application cannot successfully authentication against CAS.

Example error message:

Solutions:

...

If the time on the CAS client and server systems are not sufficiently synchronized, it can result in the tickets or responses being received outside of their window of validity from that system's perspective.

Example error messages using the Java client:

...

• The Java client has a tolerance init parameter to specify the a timing tolerance in ms:

  Code Block
  xml xml
  <init-param> <param-name>tolerance</param-name> <param-value>60000</param-value> </init-param>

  • Reference Configuring the Jasig CAS Client for Java in the web.xml

• The DotNetCasClient 3rd party plugin for .NET projects has an attribute to specify ticket timing tolerance in ms:

  Code Block
  ticketTimeTolerance="30000"

• Alternately, our CAS servers have their time synchronized via the NTP protocol. Client systems that also use NTP are presumably unlikely to encounter this problem.

...