Table of Contents

Overview

UH Login (CAS) is available for University of Hawaiʻi (UH) Web site developers to authenticate users with their UH username and password. It alleviates the problem of having to develop a user authentication system as part of the Web-enabled application (web application) development. It also provides increased security for users by not allowing Web applications to handle their passwords (often using insecure means such as sending it in the clear or unnecessarily storing it).

UH Login (CAS) enhances security by requiring Web application developers to register their applications. This prevents rogue Web applications, phishing Web sites, etc., from misusing this service and misleading UH community members.

In addition to authentication services (AuthN), UH Login (CAS) may also provide other information (attributes) about the authenticated subject. These attributes are released using the the SAML 1.1 protocol. A registered Web application may obtain attributes about the user to implement access control (authorization) decisions, beyond the simple determination that the user has successfully authenticated with their password. For example, if an application is designed to be accessible only to faculty, that app can compare the eduPersonAffiliation attribute to determine if the user is faculty. If you do not perform any access control then anyone in the UH Core LDAP Directory Service will be able to use your Web application. This includes all current people in the UH System as well as visitors allowed by the Visitor Internet Access (VIA).

• More information about attributes available via CAS may be found in our CAS Attribute Release Policy.

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

Before You Register Your Application URL …

Before you register your application URL there are a few details to first consider:

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 (808) 956-7487.

Register Your Application URL

For security purposes, application URLs must be registered in order to prevent unauthorized use.

• Registration Form

Web Login process

Web applications registered for UH Login use a link or redirect from their main page to the secure HTML CAS form.

To Authenticate Users

• A user enters their UH username and password on the UH Login page.

• After submission, the Web Login Service redirects the user back to your web application along with a service ticket provided by the Web Login Service.

• Your web application then requests that UH Login validate this ticket.

  • If the user supplied the correct authentication credentials (username/password), UH Login will return a success response to your web application.

  • Otherwise, a failure response is returned.

The specific format and content of these responses are determined by the CAS URI used by your application's request to validate the service ticket.

The service ticket is a one-time use token so any attempt to reuse it will result in a failure response.

This multi-step process should occur within your application; the user will only see that they've authenticated successfully, or a rejection message.

UH Login does not provide session tracking information so it is your Web application's responsibility to handle session tracking. Session tracking will reduce the number of round trips to UH Login to validate the user each time a resource (URL/URI) is requested from your Web application.

If the login step fails repeatedly for the user, they will remain at UH Login's login page. They may need to visit the Account Management page to reset their password or contact the Help Desk for assistance.

Conventions & Definitions

• "Client" refers to the end user and/or the web browser.

• "Server" refers to UH Login (CAS).

• "Service" refers to the application the client is trying to access (i.e., your application).

  • "TARGET" for samlValidate

• <LF> is a bare line feed (ASCII value 0x0a).

CAS URIs

URIs for CAS use the hostname followed by /cas and ended with the desired service. In the examples that follow, substitute the following for $WEBLOGIN-HOST for the appropriate environment.

• Production

  • https://authn.hawaii.edu/

• Test

  • https://cas-test.its.hawaii.edu/ (testing does not require registration of your URL)

• Future Test

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

• Deprecated Production

  • cas-deprecated.its.hawaii.edu

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/p3/serviceValidate

    • Use HTTP GET

    • CAS protocol v3.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

• indicate whether the user authenticated successfully

• provide the user's UH Username if the they authenticated successfully

If your service requires additional attributes for the user beyond their UH Username (eg UH Number, First/Last Name, etc), you should use cas/samlValidate.

Log in Securely

/login

To have a user login securely put a link on your main page to the "login securely" URL with a request parameter named service and having a value that is the Service URL (i.e., the URL of the main page or a page that will be able to handle an HTTP request with a parameter). This link should be labeled with something like "Login Securely" to establish in your user's mind that the password will not be seen by your application and is handled securely. See the next section on ticket validation for information about how your application finds out the username.

Parameters

The /login URI uses the following parameters:

• service

  • used for AuthN responses

  • validate service ticket with

    • cas/validate

    • cas/serviceValidate

    • cas/p3/serviceValidate

    • cas/samlValidate

• renew (OPTIONAL)

  • if this parameter is set, single sign-on will be bypassed. In this case, CAS will require the client to present credentials regardless of the existence of a single sign-on session with CAS.

• other parameters are described on the CAS Protocol wiki page

The service parameter should be set to the URL that the Web Login service will redirect the client to after successful authentication, as well as where the Web Login service will direct success/failure responses.

Successful login:

• 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/p3/serviceValidate

    • Use HTTP GET

    • CAS protocol v3.0

    • response is XML

  • cas/samlValidate

    • Use HTTP POST

    • provides attributes

    • response is SAML 1.1

Failed login:

• Return to /login as a credential requester. The CAS server should display an error message to the user describing why login failed (e.g. bad username/password).

Examples

• Service/target URL, this is your site's menu page or the page after a user logs in.

  https://myserver/myapp

• "Log in Securely" link:

  Simple AuthN, allow SSO

  <A HREF= "https://$WEBLOGIN-HOST.hawaii.edu/cas/login?service=https://myserver/myapp"> Log in securely </A>

  Simple AuthN, disallow SSO

  <A HREF= "https://$WEBLOGIN-HOST.hawaii.edu/cas/login?service=https://myserver/myapp&renew=true"> Log in securely </A>

Ticket Validation (CAS protocol 1.0, AuthN, simple text response)

/validate

This section describes how your Web application finds out the username of a user that has successfully logged in.

cas/validate checks the validity of a service ticket. cas/validate is part of the CAS 1.0 protocol. When UH Login has authenticated the user, it will redirect the user back to your Web site to the Service URL with an HTTP request parameter named, ticket, added on the end of the Service URL. That Service URL may not be a static page since it must be able to extract the service ticket for validation.

Parameters

• service (REQUIRED)

  • the identifier of the service for which the ticket was issued

• ticket (REQUIRED)

  • the service ticket issued by /login

• renew (OPTIONAL)

  • if this parameter is set, ticket validation will only succeed if the service ticket was issued from the presentation of the user's primary credentials. It will fail if the ticket was issued from a single sign-on session.

Examples

• Here's an example of the URL used by UH Login to redirect the request back to the Web site (with a sample ticket):

  https://myserver/myapp?ticket=ST-3-8tkkJbPThesE1cZjVVtc

• The server-side processing of your Service URL must validate the extracted authentication token by sending an HTTP GET request with the following parameters:

  service=<Service URL> ticket=<service ticket>

• Using your URL with ticket, send your request to UH Login:

  https://$WEBLOGIN-HOST/cas/validate?service=https://myserver/myapp&ticket=ST-95-a1kjb6g4Tcdeh17vfy6g

• After validating the service ticket, UH Login will return a text document indicating success or failure.

  On ticket validation success:

  yes<LF> username<LF>

  On ticket validation failure:

  no<LF> <LF>

Ticket Validation (CAS protocol 2.0, AuthN, XML response)

/serviceValidate

This section describes how your Web application finds out the username of a user that has successfully logged in.

cas/serviceValidate checks the validity of a service ticket and returns an XML-fragment response. cas/serviceValidate is part of the CAS 2.0 protocol. When UH Login has authenticated the user, it will redirect the user back to your Web site to the Service URL with an HTTP request parameter named, ticket, added on the end of the Service URL. That Service URL may not be a static page since it must be able to extract the service ticket for validation.

Parameters

• service (REQUIRED)

  • the identifier of the service for which the ticket was issued

• ticket (REQUIRED)

  • the service ticket issued by /login

• renew (OPTIONAL)

  • if this parameter is set, ticket validation will only succeed if the service ticket was issued from the presentation of the user's primary credentials. It will fail if the ticket was issued from a single sign-on session.

Examples

• Here's an example of the URL used by UH Login to redirect the request back to the Web site (with a sample ticket):

  https://myserver.example.edu/myapp?ticket=ST-7655-K6dyN9ystYwdOZynSnak-cas

• The server-side processing of your Service URL must validate the extracted authentication token by sending an HTTP GET request with the following parameters:

  service=<Service URL> ticket=<service ticket>

• Using your URL with ticket, send your request to UH Login:

  https://$WEBLOGIN-HOST/cas/serviceValidate?service=https://myserver.example.edu/myapp&ticket=ST-7655-K6dyN9ystYwdOZynSnak-cas

• After validating the service ticket, UH Login will return an XML-fragment indicating success or failure.

  On ticket validation success:

  <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationSuccess> <cas:user>joebogus</cas:user> </cas:authenticationSuccess> </cas:serviceResponse> 

  On ticket validation failure:

  <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationFailure code="INVALID_TICKET"> Ticket ST-7655-K6dyN9ysFOOdOZynSnak-cas not recognized </cas:authenticationFailure> </cas:serviceResponse>

Ticket Validation (CAS protocol 3.0, AuthN with attributes, XML response)

/p3/serviceValidate

This section describes how your Web application finds out the username of a user that has successfully logged in.

cas/serviceValidate checks the validity of a service ticket and returns an XML-fragment response. cas/p3/serviceValidate is part of the CAS 3.0 protocol. When UH Login has authenticated the user, it will redirect the user back to your Web site to the Service URL with an HTTP request parameter named, ticket, added on the end of the Service URL. That Service URL may not be a static page since it must be able to extract the service ticket for validation.

If cas/p3/serviceValidate is used and your application is authorized to receive attributes, an XML object is returned with a list of defined attributes for your application.

• We return the following set of user attributes by default for cas/p3/samlValidate:

Parameters

• service (REQUIRED)

  • the identifier of the service for which the ticket was issued

• ticket (REQUIRED)

  • the service ticket issued by /login

• renew (OPTIONAL)

  • if this parameter is set, ticket validation will only succeed if the service ticket was issued from the presentation of the user's primary credentials. It will fail if the ticket was issued from a single sign-on session.

Examples

• Here's an example of the URL used by UH Login to redirect the request back to the Web site (with a sample ticket):

  https://myserver.example.edu/myapp?ticket=ST-7655-K6dyN9ystYwdOZynSnak-cas

• The server-side processing of your Service URL must validate the extracted authentication token by sending an HTTP GET request with the following parameters:

  service=<Service URL> ticket=<service ticket>

• Using your URL with ticket, send your request to UH Login:

  https://$WEBLOGIN-HOST/cas/p3/serviceValidate?service=https://myserver.example.edu/myapp&ticket=ST-7655-K6dyN9ystYwdOZynSnak-cas

• After validating the service ticket, UH Login will return an XML-fragment indicating success or failure.

  On ticket validation success:

  <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationSuccess> <cas:user>joebogus</cas:user> <cas:attributes> <cas:mail>joebogus@hawaii.edu</cas:mail> <cas:eduPersonAffiliation>staff</cas:eduPersonAffiliation> <cas:authnContextClass>mfa-duo</cas:authnContextClass> <cas:eduPersonOrgDN>uhm</cas:eduPersonOrgDN> <cas:uid>joebogus</cas:uid> <cas:serverIpAddress>10.0.0.10</cas:serverIpAddress> <cas:eduPersonPrincipalName>joebogus@hawaii.edu</cas:eduPersonPrincipalName> <cas:longTermAuthenticationRequestTokenUsed>false</cas:longTermAuthenticationRequestTokenUsed> <cas:sn>Bogus</cas:sn> <cas:clientIpAddress>192.100.100.100</cas:clientIpAddress> <cas:isFromNewLogin>true</cas:isFromNewLogin> <cas:authenticationDate>2025-07-09T17:22:38.497155089Z</cas:authenticationDate> <cas:bypassMultifactorAuthentication>false</cas:bypassMultifactorAuthentication> <cas:uhUuid>12345678</cas:uhUuid> <cas:givenName>Joe</cas:givenName> <cas:successfulAuthenticationHandlers>mfa-duo</cas:successfulAuthenticationHandlers> <cas:cn>Joe Queso Bogus</cas:cn> <cas:credentialType>DuoSecurityUniversalPromptCredential</cas:credentialType> <cas:samlAuthenticationStatementAuthMethod>urn:oasis:names:tc:SAML:1.0:am:unspecified</cas:samlAuthenticationStatementAuthMethod> <cas:authenticationMethod>mfa-duo</cas:authenticationMethod> <cas:geoLocation>unknown</cas:geoLocation> <cas:uhEmail>joebogus@hawaii.edu</cas:uhEmail> <cas:uhOrgAffiliation>eduPersonOrgDN=uhm,eduPersonAffiliation=staff</cas:uhOrgAffiliation> </cas:attributes> </cas:authenticationSuccess> </cas:serviceResponse>

  On ticket validation failure:

  <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationFailure code="INVALID_TICKET"> Ticket ST-7655-K6dyN9ysFOOdOZynSnak-cas not recognized </cas:authenticationFailure> </cas:serviceResponse>

Ticket Validation (CAS protocol 3.0, AuthN with attributes, SAML response):

/samlValidate

This section describes how your Web application determines the username and possibly additional attributes for a user that has successfully logged in.

cas/samlValidate checks the validity of a service ticket and returns an SAML1.1-fragment response. When UH Login has authenticated the user, it will redirect the user back to your Web site to the TARGET URL with an HTTP request parameter named ticket (or SAMLart) added on the end of the TARGET URL. That TARGET URL can not be a static page since it won't be able to extract the service ticket for validation.

A SAML 1.1 ticket validation response is obtained by validating a ticket via POST at the cas/samlValidate URI.

If cas/samlValidate is used and your application is authorized to receive attributes, a SAML object is returned with a list of defined attributes for your application.

• We return the following set of user attributes by default for cas/samlValidate:

Parameters

• TARGET (REQUIRED)

  • the identifier of the TARGET for which the ticket was issued

• ticket (or SAMLart)

  • the service ticket issued by /login. Note that in this case, the service ticket is not provided in the request URL as with the other validation methods, but in the SOAP request

• renew (OPTIONAL)

  • if this parameter is set, ticket validation will only succeed if the service ticket was issued from the presentation of the user's primary credentials. It will fail if the ticket was issued from a single sign-on session.

Examples

• Here's an example of the URL used by UH Login to redirect the request back to the Web site (with a sample ticket):

  https://myserver/myapp?ticket=ST-7655-K6dyN9ystYwdOZynSnak-cas

  Note that if the login URL used "TARGET=" instead of "service=", the request from the CAS server will use "SAMLart=" instead of "ticket=".  Also, the value will be a base64 string.

• Your webapp will then validate the ticket by sending a HTTP POST request with the ticket enclosed in a XML SOAP message:

  https://$WEBLOGIN-HOST/cas/samlValidate?TARGET=https://myserver.example.edu/myapp
  POST /cas/samlValidate?TARGET=https://myserver.example.edu/myapp Host: cas.example.com Content-Length: 491 Content-Type: text/xml <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header/> <SOAP-ENV:Body> <samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion="1" MinorVersion="1" RequestID="17337.2018-05-03T09:50:56Z" IssueInstant="2018-05-03T09:50:56Z"> <samlp:AssertionArtifact> ST-7655-K6dyN9ystYwdOZynSnak-cas </samlp:AssertionArtifact> </samlp:Request> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 

• After validating the service ticket, UH Login will return a SAML1.1 fragment indicating success or failure.

  On ticket validation success:

  <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <saml1p:Response xmlns:saml1p="urn:oasis:names:tc:SAML:1.0:protocol" InResponseTo="myserver.example.edu" IssueInstant="2018-05-03T19:50:56.390Z" MajorVersion="1" MinorVersion="1" ResponseID="_0044d5b611aac99d82cb9926281bbd30"> <saml1p:Status> <saml1p:StatusCode Value="saml1p:Success"/> </saml1p:Status> <saml1:Assertion xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_0b1889b7ce444ecbe8cfd131501c4f59" IssueInstant="2018-05-03T19:50:56.390Z" Issuer="localhost" MajorVersion="1" MinorVersion="1"> <saml1:Conditions NotBefore="2018-05-03T19:50:56.390Z" NotOnOrAfter="2018-05-03T19:51:26.390Z"> <saml1:AudienceRestrictionCondition> <saml1:Audience>https://myserver.example.edu/myapp</saml1:Audience> </saml1:AudienceRestrictionCondition> </saml1:Conditions> <saml1:AuthenticationStatement AuthenticationInstant="2018-05-03T19:50:56.320Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"> <saml1:Subject> <saml1:NameIdentifier>iam_0108</saml1:NameIdentifier> <saml1:SubjectConfirmation> <saml1:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:artifact</saml1:ConfirmationMethod> </saml1:SubjectConfirmation> </saml1:Subject> </saml1:AuthenticationStatement> <saml1:AttributeStatement> <saml1:Subject> <saml1:NameIdentifier>joebogus</saml1:NameIdentifier> <saml1:SubjectConfirmation> <saml1:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:artifact</saml1:ConfirmationMethod> </saml1:SubjectConfirmation> </saml1:Subject> <saml1:Attribute AttributeName="mail" AttributeNamespace="http://www.ja-sig.org/products/cas/"> <saml1:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">joebogus@example.edu</saml1:AttributeValue> </saml1:Attribute> <saml1:Attribute AttributeName="eduPersonAffiliation" AttributeNamespace="http://www.ja-sig.org/products/cas/"> <saml1:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">staff</saml1:AttributeValue> </saml1:Attribute> <saml1:Attribute AttributeName="uhUuid" AttributeNamespace="http://www.ja-sig.org/products/cas/"> <saml1:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">12345678</saml1:AttributeValue> </saml1:Attribute> <saml1:Attribute AttributeName="givenName" AttributeNamespace="http://www.ja-sig.org/products/cas/"> <saml1:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">Bogus</saml1:AttributeValue> </saml1:Attribute> <saml1:Attribute AttributeName="eduPersonOrgDN" AttributeNamespace="http://www.ja-sig.org/products/cas/"> <saml1:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">uhsystem</saml1:AttributeValue> </saml1:Attribute> <saml1:Attribute AttributeName="cn" AttributeNamespace="http://www.ja-sig.org/products/cas/"> <saml1:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">Joe Queso Bogus</saml1:AttributeValue> </saml1:Attribute> <saml1:Attribute AttributeName="uid" AttributeNamespace="http://www.ja-sig.org/products/cas/"> <saml1:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">joebogus</saml1:AttributeValue> </saml1:Attribute> <saml1:Attribute AttributeName="uhEmail" AttributeNamespace="http://www.ja-sig.org/products/cas/"> <saml1:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">joebogus@example.edu</saml1:AttributeValue> </saml1:Attribute> <saml1:Attribute AttributeName="eduPersonPrincipalName" AttributeNamespace="http://www.ja-sig.org/products/cas/"> <saml1:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">joebogus@example.edu</saml1:AttributeValue> </saml1:Attribute> <saml1:Attribute AttributeName="sn" AttributeNamespace="http://www.ja-sig.org/products/cas/"> <saml1:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">Bogus</saml1:AttributeValue> </saml1:Attribute> <saml1:Attribute AttributeName="uhOrgAffiliation" AttributeNamespace="http://www.ja-sig.org/products/cas/"> <saml1:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">eduPersonOrgDN=uhsystem,eduPersonAffiliation=staff</saml1:AttributeValue> </saml1:Attribute> </saml1:AttributeStatement> </saml1:Assertion> </saml1p:Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 

  On ticket validation failure:

  <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header/> <SOAP-ENV:Body> <Response xmlns="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" IssueInstant="2018-05-03T19:50:56.390Z" MajorVersion="1" MinorVersion="1" Recipient="https://myserver.example.com/myapp" ResponseID="_f2a2d3c1d7b451a71a688eb63a3251b9"> <Status> <StatusCode Value="samlp:Responder"></StatusCode> <StatusMessage>ticket\'ST-7655-kPThesE1cZjVVtcMANGLED\' not recognized</StatusMessage> </Status> </Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Logging Out (SLO)

/logout

Web applications that login a user must handle their own session state and should offer the user the ability to log out of their session. Without the logout service provided by CAS, a user returning to the web application's Service URL, will be automatically logged back in because of the ticket-granting cookie also provided by CAS stored by the client. This is a single sign-on feature across web applications that use UH Login. There are two basic ways to "log out"; logout from application and UH Login single sign-on or logout from application and force re-authentication to UH Login.

cas/logout destroys a client's single sign-on CAS session. The ticket-granting cookie is destroyed, and subsequent requests to /logout will not obtain service tickets until the user again presents primary credentials (and thereby establishes a new single sign-on session).

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)

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.

  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.

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

Access Control

It is every developer's responsibility to perform any necessary access control (authorization, AuthZ) after a user has logged on to their Web site. This is may be done by using information as attributes for the user. The affiliation, campus, or campus affiliation data should be enough to filter out unauthorized users. Alternatively, you choose explicitly may allow or disallow by username. Ultimately, it is up to each developer to determine how to implement access controls based on available information.

Sample Clients

• Apereo documentation on CAS clients

• Jasig CAS Client for Java - Spring Boot Support

Java client

Aperero provides an example of SAML 1.1 Ticket Validation Filter.