Apereo CAS provide centralized authentication for supported web applications. It is the standard mechanism for new efforts in ECI and is used where possible. It is the preferred mechanism for allowing outside parties to authenticate against NDSU's user accounts.
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 1.0
- Not recommended
- CAS 2.0
- With extended attributes
- SAML 1.1
Single sign on is supported. 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.
- User ids are not email addresses: While CAS does allow email@example.com, returned ids never contain domains.
- services attribute is authoritative: The services attribute is maintained by ECI. Anything in all upper case is active, anything in all lower case is inactive.
- 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 members of other NDUS institutions can all 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.
- givenName: Given name, normally from PeopleSoft
- mail: Email address for the user
- Name: Common Name attribute from LDAP. First Middle Last
- nid: Unix numeric id. This is immutable.
- scopedAffiliation: Values from LDAP's scopedEduPersonAffiliation. These values are accurate and up to date for NDSU. Other institutions are not represented. This should be used to determine affiliation with NDSU.
- services: List of services for an individual. All caps are active services, all lower case are inactive / locked services. Do not overload a service as usage and even existence may change at any time without notification.
- sn: Surname normally 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 present in LDAP and 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.
- firstname.lastname@example.org: 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.
- email@example.com: 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 firstname.lastname@example.org.
- email@example.com: Indicates that the person is employed with the institution in some way. This includes faculty, staff, and student employees. This implies firstname.lastname@example.org.
- email@example.com: Indicates that the person is employed as a staff member with the institution. This implies firstname.lastname@example.org.
- email@example.com: Indicates that the person is employed as a faculty member with the institution. This implies firstname.lastname@example.org.