Apereo CAS provide centralized authentication for supported web applications. It is one of the two standard mechanisms for authentication at NDSU and is used where possible. It is the preferred mechanism for providing authentication for internal NDSU resources, and secondary for external resources after InCommon.
CAS usage by application is by approval, which is easy to receive. To use CAS in your application or your vendor's application please contact the NDSU Help Desk.
CAS as implemented at NDSU supports these protocols
- CAS 2.0
- Not recommended, does not have extended attributes.
- CAS 3.0
- SAML 1.1
- Allows for attribute return.
Single sign on is supported by default. Single sign out is not supported.
The following assumptions are valid.
- User ids are unique: Returned user ids by CAS are the unique IID / eID that is typically of the form firstname.lastname.
- User ids are lower case: User ids are always returned in lower case.
- Usernames are not email addresses: While CAS does allow firstname.lastname@example.org, the username attribute never contain domains.
- services attribute is authoritative: The services attribute is maintained by ECI.
- nid never changes: The NID is a numeric attribute for users that never change and are appropriate for use as Unix numeric ids.
- uids rarely change: The uid attribute is an alpha-numeric id with a maximum of 20 characters in length, most are 8 characters or less. It almost never changes, but as it is based off of a name, on rare occasions it is changed.
The following are not valid assumptions
- Authentication implies authorization: Authentication does not imply anything about the relationship of the user with NDSU. Guests, affiliates, and other accounts can authenticate against NDSU CAS.
- User ids are un-changing: User ids (iid / eID) are frequently changed by end users. However, each ID will only reference one person.
- User ids have meaning: User ids have no meaning, and none should be taken from the id.
- Additional attributes have been verified: Many other attributes can be returned by CAS. However, not all of these have been verified or are authoritative. The only authoritative attributes are username (iid/eID), uid, nid, and services.
The following settings are for production CAS
The following are possible attributes that can be returned in SAML 1.1 / CAS 2.0 responses. How to retrieve these attributes.
- displayName: givenName + sn
- eduPersonPrincipalName: Same ePPN as provided via InCommon, scoped to @ndsu.edu, will change over time
- eduPersonUniqueId: Same ePUID as provided via InCommon, scoped to @ndsu.edu. Will not change for a given account. Is not share across multiple accounts for a single user. This is the best choice for an immutable value to identify as user.
- givenName: Given name, normally preferred name from PeopleSoft
- mail: Email address for the user
- memberOf: List of Active Directory group memberhips
- nid: Unix numeric id. This is immutable.
- scopedAffiliation: Same ePSA as provided via InCommon.
- services: List of services for an individual for service not maintained in an AD group.
- sn: Surname normally preferred last name from PeopleSoft
- uid: An alpha-numeric id that is 20 characters or less, with most at 8 characters or less. This id rarely changes.
- username: The user's user name. This is the IID / eID normally used by the user. It has been cleaned up to remove any domain and trimmed.
eduPersonScopedAffiliation is provided by Shibboleth and CAS (under scopedAffiliation). This can be, and most likely is, a multivalued field. Currently these are the values and meanings associated with those values.
- email@example.com: Indicates that the account belongs to someone who is member of the NDSU community and should receive services and access accordingly. Generally this is set by having one of the affiliations below.
- firstname.lastname@example.org: Indicates that the person is currently enrolled as a student for at least one credit at NDSU. This is cleaned up during fall and spring purges. Additionally, after the last day to add online for fall and spring semesters this is also cleaned up. This means that students from the spring will remain marked as students over the summer, even if they are not enrolled for credits during summer. This implies email@example.com.
- firstname.lastname@example.org: Indicates that the person is employed with the institution in some way. This includes faculty, staff, and student employees. This implies email@example.com.
- firstname.lastname@example.org: Indicates that the person is employed as a staff member with the institution. This implies email@example.com.
- firstname.lastname@example.org: Indicates that the person is employed as a faculty member with the institution. This implies email@example.com.