Integration process in brief:

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

Service Registration

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. Jasig .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 four 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. SAML 1.1 ticket validation URL - https://login.vt.edu/profile/cas/samlValidate
  4. CAS logout URL - https://login.vt.edu/profile/cas/logout
  5. Proxy ticket request URL - https://login.vt.edu/profile/cas/proxy
  6. Proxy ticket validation URL - https://login.vt.edu/profile/cas/proxyValidate

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 - login-dev.middleware.vt.edu
  2. Pre-production - login-pprd.middleware.vt.edu

Attribute Release

Historically, the /samlValidate endpoint has been used exclusively at Virginia Tech to release attributes to services. The Login service also supports releasing attributes at /serviceValidate using a well-supported extension to the CASv2 protocol. This makes possible combining CASv2 proxy capabilities with attribute release. While this feature is not enabled by default, it’s possible to request it for your service by sending a note to middleware@vt.edu.

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
phpCAS::handleLogoutRequests(false);

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

https://wiki.shibboleth.net/confluence/display/IDP30/Logout+and+SLO

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.