Table of Contents
Table of Contents | ||||
---|---|---|---|---|
|
...
- Will authentication include the release of attributes to your application?
- 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.
- Is your application hosted on a non-UH server?
- 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
...
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
Info | ||
---|---|---|
| ||
The primary difference between the Test and Production environments is the source of credentials used for authentication and attributes. The production Web Login instance uses production LDAP, whereas the test Web Login instance uses our test LDAP instance. Data in the test LDAP instance generally represents a (somewhat stale) snapshot of the production LDAP. Developers should verify that the credentials they wish to test are available in test LDAP. The login page presented to the user in the test environment is also conspicuously identified as being "Not intended for normal use" and a "test-env". |
...
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. Theurl
parameter defined in the former CAS 2.0 specification is not a valid parameter in CAS 3.0 anymore. CAS Servers MUST ignore givenurl
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.
...
A future enhancement could make single sign-on an option for the user so the default will be no single sign-on. If the user chooses to enable single sign-on when authenticating to UH Login, only those apps that don't use the renew parameter will permit single sign-on if the user doesn't logout via the Logout URL from a previously visited app.
Why can't I login successfully to the CAS test environment?
There are several reasons for this and one or both may be applicable:
- Currently you need to use a UH VPN to access CAS test. (not a requirement for production CAS, nor will it ever be)
- CAS test points to a test LDAP instance that may not have your current password. Send an email to the IAM team to request a "password sync" if needed.
Can anyone use my Web site?
...
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 | ||
---|---|---|
|
...