North Dakota State University

Jasig 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
  • Preferred

Single sign on is supported. Single sign out is not supported.

Valid assumptions

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 first.last@ndsu.edu, 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.

Invalid assumptions

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

• Host: apps.ndsu.edu
• Port: 443
• Path: /cas/
• Login URL: https://apps.ndsu.edu/cas/login
• Logout URL: https://apps.ndsu.edu/cas/logout
• Service Validate URL: https://apps.ndsu.edu/cas/serviceValidate
• SAML Service Validate URL: https://apps.ndsu.edu/cas/samlValidate

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
• group: Primary institution relationship: ndscs, ndsu, vcsu, wsc, etc. People can be at multiple institutions, but this is a single value. It is not entirely accurate due to this fact.
• mail: Email address for the user
• Name: Common Name attribute from LDAP. First Middle Last
• nid: Unix numeric id
• relationship: General relationship with institution: faculty, staff/admin, student. People can have multiple relationships at an institution, but this is a single value. It is not entirely accurate (for example, it is very common for new employees to appear as "student").
• 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
• telephoneNumber: Office phone number for employees, local phone number for students. Not very accurate for students.
• 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.