Registration
To apply to CASify your application, fill out the SSO Registration Form in ServiceNow (login is required). You can also choose to modify or delete an existing service by following that link.
In this form, Service URL refers to the exact URL to allow. This is the relevant setting for allowing access. For example, the URL https://calnet.berkeley.edu would authorize everything inside the CalNet site for CAS. More specific URL patterns are permitted if necessary to distinguish between applications.
If you are using your workstation for testing, you may use either localhost or 127.0.0.1 as part of the URL, with or without a port number. URL patterns for these two names have already been registered, so there is no need to request access for them.
CAS Authorization
If you opt for CAS authorization, we will work with you to implement this for your application. The application form selects all of the items in the Base Affiliations by default, but any of these items may be deselected before the form is submitted.
Base Affiliations
Affiliation Type |
Comment |
Students |
Any student with a STUDENT-TYPE-REGISTERED or STUDENT-TYPE-NOT-REGISTERED Includes Summer Sessions and Concurrent Enrollment students |
Employees |
Any person with EMPLOYEE-TYPE-ACADEMIC or EMPLOYEE-TYPE-STAFF |
UCPath Affiliates |
|
SPAs |
Special Purpose Accounts |
rSPA Test Accounts for Developers |
Additional Affiliations
If your application requires access to populations other than the Base Affiliations you may choose from the items below
Affiliation Type |
Comment |
Guests |
GUEST-TYPE-* in the Guests OU |
Pre SIRs |
Located in the PreSIR People OU; requires the Slate/MAP theme |
Alumni |
People located in the ADVCON OU |
Student Delegates | CalNet account (such as for a parent) sponsored by a student |
Former Students | |
Former Employees |
|
Former UCPath Affiliates |
Allow, Admin and Deny Groups in CalGroups
You will be set up with your CAS Access Folder in CalGroups, which will include an Allow Group for you to programmatically or manually add additional populations as your service requires. Add any account or group you want to access your service to your Allow Group. Anyone you add to the Allow Group will have access to your service until you delete them from the group.
Your folder will also contain an Admin Group. Anyone you add to the Admin Group will be able to administer your Allow Group in CalGroups.
Use the Deny Group to exclude any users from logging in to your service. Adding a user to the Deny Group will prevent them from logging in despite their affiliations and overrides other access logic.
The maximum resultant membership in either group must be less than or equal to 1000 members.
Example of CAS Access Folder with Allow and Admin Groups
Basic CAS Client Configuration
See also: CAS Service URLs
- CAS Server production cluster name: auth.berkeley.edu
Protocol function
|
Service path
|
Comments
|
---|---|---|
login | /cas/login | |
validate | /cas/serviceValidate | most CAS clients support this CAS 2.0 protocol endpoint; does NOT support attributes |
validate | /cas/p3/serviceValidate | for CAS clients supporting the CAS 3.0 protocol; supports attributes |
SAML validate | /cas/samlValidate | for CAS clients that support the CAS SAML 1.1 protocol; supports attributes |
Using the redirection on logout feature
Following logout, to redirect the browser to a landing page of your choice (and which page is not protected by CAS), use something like this example for the logout call in your CAS client application:
https://auth.berkeley.edu/cas/logout?service=https://myservice.berkeley.edu/welcome.html
The welcome.html landing page in this example should not be protected by CAS to avoid having the browser immediately prompt for a new application login session. To improve security, the CAS server only redirects the browser to the URL for the landing page if the URL matches a pattern that is already registered with the server. This URL typically would be one which is included within your CAS client application's registered URL pattern, but one which is not actually protected by CAS.
LDAP-Derived Attributes from CAS Protocol
The CAS protocol may return certain LDAP-derived attributes listed below for your service in addition to the default username-to-uid mapping available at this CAS server path:
/cas/samlValidate or /cas/p3/serviceValidate
In the CAS Registration form, you can indicate which of these attributes to return to your service via the CAS protocol. Some attributes require permission from the data proprietor.
Attribute Name | Public or Non Public | Description |
displayName |
public | the preferred full name |
givenName | public | the first name |
surname | public | the last name |
berkeleyEduOfficialEmail | non-public | |
uid | public | uid is the immutable identifier value assigned to all CalNetID holders and returned by CAS by default as the username. Optionally, the uid value can be returned as part of a CAS3 or samlValidate set of attribute values as well. In that case, some other directory attributes may be returned as the CAS username value, such as the CalNetID (berkeleyEduKerberosPrincipalString) value itself. |
departmentNumber | public | from the Org Node tree |
berkeleyEduAffiliations | public | for basic authorization information. This attribute is multi-valued and will show the current active affiliation(s). Any former affiliations will be listed as well. |
berkeleyEduKerberosPrincipalString | public | the CalNetID, an alternative for the uid in the CAS username |
employeeNumber | non-public | |
berkeleyEduStuID | non-public | |
berkeleyEduCSID | non-public | |
berkeleyEduIsMemberOf | non-public |
Please note a few things:
- Depending on the target user population for your application, we would need to contact the campus HR folks and/or the campus student Registrar to request the release of non-public attributes to you. Please follow this template in requesting access to non-public attributes: Applying for Directory Access
- Any of the listed attributes also can be mapped as the CAS username instead of the default uid attribute. This is true even if your CAS client otherwise has no current support for using the CAS 3.0 or SAML 1.1 protocol.