Login Service CAS Protocol Integration


Integration process in brief:

  1. Register your service
  2. Configure a suitable CAS client
  3. Test and troubleshoot

Service Registration

Services hosted at a vt.edu domain do not require registration. If your service is not hosted at a vt.edu domain, follow the instructions below to start the registration process.

Registration Process

Please send a note to middleware@vt.edu containing the following information:

  1. Service URL (e.g. https://wookie.subdomain.vt.edu/foo/)
  2. Service name (e.g. Wookie Management)
  3. Service administrator name and PID

The service URL should be the base URL for all authenticated application entry points.

CAS Client Configuration

Middleware provides competent support for the following CAS client software libraries:

  1. Apache mod_auth_cas client
  2. Jasig Java CAS client
  3. Spring Security
  4. Apereo .NET CAS client
  5. phpCAS client

There are many more CAS clients for various platforms (Python, Perl, Ruby, etc) that are also likely to work with the Virginia Tech Login Service, but Middleware cannot provide configuration instructions or advice outside the list above.

In most cases it should suffice to plug in the Login Service URL(s) into the configuration framework provided by the CAS client library. There five CAS protocol URLs, though only the first three are commonly used.

  1. CAS login URL - https://login.vt.edu/profile/cas/login
  2. CAS v2 ticket validation URL - https://login.vt.edu/profile/cas/serviceValidate
  3. CAS logout URL - https://login.vt.edu/profile/cas/logout
  4. Proxy ticket request URL - https://login.vt.edu/profile/cas/proxy
  5. Proxy ticket validation URL - https://login.vt.edu/profile/cas/proxyValidate

NOTE that the /samlValidate is deprecated and should not be used for any new applications. While it is technically supported at the time of writing, it may be removed from future versions of the Shibboleth IdP software used by the Login Service. Historically this endpoint was used to provide user attributes, but that distiction is no longer relevant as the /serviceValidate endpoint provides attributes by default.

It’s worth nothing that the /profile/cas/logout URI is a synonym for the protocol-agnostic logout URI, /profile/Logout. Clients should use the latter if possible.

If using a non-production tier, substitute one of the following host names accordingly:

  1. Develop - dev.login.vt.edu
  2. Pre-production - pprd.login.vt.edu

Attribute Release

The Login Service releases attributes at /serviceValidate by default using a well-supported extension to the CASv2 protocol. The following attributes are released to Virginia Tech services by default.

Attribute ID Description
personType Person type, e.g. “Virginia Tech” or “Guest”
uid Immutable numeric identifier for person
authId Username with which user authenticated
uupid Enterprise directory uupid attribute; not defined for guests
accountState User account state, e.g. ACTIVE, EXPIRED
passwordState User account password state, e.g. ACTIVE, EXPIRED
passwordExpirationDate User account password expiration date
virginiaTechAffiliation Virginia Tech affiliations, e.g. VT_FACULTY, VT_STUDENT_ACTIVE
eduPersonAffiliation eduPerson affiliation, e.g. faculty, staff, student
eduPersonPrimaryAffiliation Meaningless at present
groupMembership DNs of Enterprise Directory groups to which user belongs
groupMembershipUugid Group name (uugid) of ED groups to which user belongs
loa Virginia Tech level of identity assurance
suppressDisplay Whether all person attributes should be suppressed
UDC_IDENTIFIER Banner UDC identifier (BEIS)

SLO Configuration Considerations

The following CAS clients are known to support SLO:

  1. Jasig Java CAS client
  2. Spring Security
  3. Jasig .NET CAS client
  4. phpCAS client

Most clients do not require any special configuration to support SLO. A notable exception is phpCAS, which requires the following configuration directive:

// Handle SAML logout requests
// Do not authenticate clients since requests come from user's browser
// and those network locations cannot be known apriori

For more information about the logout/SLO features in the underlying Shibboleth IdP software, please see the following reference:


CAS Proxy Requirements

A request for a CAS proxy-granting ticket represents a request to perform delegated authentication, which is a substantial increase in privileges beyond the standard service ticket. Where a service ticket represents access to one service, a proxy-granting ticket represents the ability to grant access to many services. The increase in privileges demands a commensurate increase in authorization to ensure adequate security controls. Proxying services must meet the following requirements:

  1. Proxying services must be explicitly authorized to proxy (i.e. service registration requires authorizedToProxy=true).
  2. The proxy callback URL must be secured with a VT Global Qualified Server CA certificate.