Login Service Single Sign-On

Introduction

The Virginia Tech Login Service is a Web single sign-on (SSO) service that supports the following protocols:

  1. SAML1/SAML2
  2. CAS (v2)
  3. OIDC (Gateway)

As with all Middleware services, 3 tiers are provided for development, testing, and production:

  1. Development:
  2. Pre-production:
  3. Production:

The choice of tier to integrate with is at the discretion of service owners, though for production services there is no sensible choice other than the production tier. Note that each tier consumes the corresponding tier of the Enterprise Directory, so use of the preprod tier, for example, requires having valid credentials in the preprod LDAP directory. It may be necessary to reset your dev or preprod PID password to test with those tiers; self-service reset URLs are listed below.

  1. Dev password reset - https://dev.accounts.it.vt.edu/recover
  2. Preprod password reset - https://pprd.accounts.it.vt.edu/recover

Service Agreement

Middleware provides the following services around SSO:

  1. Initial application/service integration consultation and support.
  2. Consultation around identity management best practices (e.g. crypto, authorization) as it relates to SSO.
  3. Highly-available production tier with target 99.995% uptime.
  4. Highly-available non-production tiers with target 99.99% uptime.
  5. Change management and release schedule communicated via the middleware-g@vt.edu mailing list.

Middleware does not provide any response time guarantees for integration consulting and support; we do our best to balance consumers needs with other priorities as we see fit. We try to communicate planned changes at least a week in advance for minor changes (e.g. patches), and at least a month in advance for major changes. Minor changes SHOULD NOT impact consumers; major changes MAY impact consumers.

In order to provide the services above, our customers are responsible for the following:

  1. Identify business and technical requirements sufficient to complete an SSO integration. Middleware offers consulting services to fill gaps in technical knowledge and to facilitate requirements gathering.
  2. Identify and maintain a technical contact for your application/service.
  3. Engage with Middleware as needed in response to planned service changes. The minimum level of acceptable engagement is to subscribe to middleware-g@vt.edu and follow SSO-related discussions.
  4. Obtain data steward approval for custom attribute release policies.
  5. Stand up a non-production application/service environment to facilitate SSO testing.

Usage Requirements

The following sections describe technical and policy requirements that consumers must fulfill in order to use the Login Service.

Registration

While there are a couple common cases where customers can use the Login Service without explicit approval, usage typically requires explicit registration. Please request a new single sign-on integration by completing the following form:

Single Sign-On Requestable Item

A member of the SIS team will review your request and contact you for additional information required to start your integration. You should be prepared to provide vendor documentation and field technical integration questions in terms of the SSO protocol your application or service intends to use.

Registration is not required for the following common cases.

CAS Consumers Hosted at Virginia Tech

Any service hosted in the vt.edu DNS namespace may perform SSO via the Login Service using the CAS protocol. This also includes the loosely-supported SAML 1.1 protocol for ticket validation available at /profile/cas/samlValidate. Consumers MUST use the /samlValidate endpoint for ticket validation to receive attributes.

R&S Compliant InCommon Federation Services

Any service in InCommon Federation that advertises R&S compliance SHOULD be able to authenticate to the Login Service via the SAML2 protocol without any explicit setup. These services get the consent experience in order to comply with Virginia Tech policy that covers disclosure of student and employee data to third parties.

Secure Transport (TLSv1)

Services MUST consume SSO services over a secure channel, which means that the service must be accessible exclusively over HTTPS. Middleware will confirm that the requested service URI/URL to be registered conforms to this requirement. Any X.509 certificate issuer may be used to provide SSL/TLS server certificates to secure the service, though we recommend the Virginia Tech Global Qualified Server CA, which provides SSL certs at no cost to University principals. Use of self-signed certificates are allowed, but strongly discouraged for production services.

Sessions and Security

Login maintains a session to facilitate accessing services without having to reauthenticate. Understanding the circumstances under which a session is created, maintained, and destroyed is vitally important to securing applications that participate in SSO.

Single Sign-on Session

When a user log in to the Login Service, a single sign-on session is started. Users will not be prompted again for credentials (i.e. username/password/2FA) for 24 hours unless one of the following conditions is met:

  1. The user selected the “Don’t remember me” checkbox on the login form.
  2. A service explicitly requires users to re-authenticate (i.e. forced authentication, “renew=true”).

It is vitally important to understand that the single sign-on session is entirely independent of application sessions created as users access services via Login. Indeed, it’s entirely possible for an application session to be created and expire due to inactivity while an SSO session is still active. In many cases if the user attempted to access that application again, he or she would be permitted without having to reauthenticate. Upon reintering the application a new application session would be created and the only outward sign might be loss of application state. Most users would perceive this as a glitch, not realizing that they are creating new application sessions seamlessly due to SSO.

The converse of single sign-on is single logout (SLO).

Single Logout (SLO)

The Login Service provides a best-effort logout protocol to end the sessions of all applications used during a user’s single sign-on session. The choice to perform SLO is optional upon ending the SSO session. When a user navigates to https://login.vt.edu/profile/Logout, the SSO session is ended and the user is presented with the option to perform SLO along with a list of services whose application sessions will be affected. If the user proceeds with SLO, Login sends a protocol-specific message to every application accessed by the user during the SSO session.

In the best case, all applications that support and are configured for SLO will terminate the application session and the user will be truly signed out of everything. A number of complicating factors make the best case a rare case:

  1. Applications must support SLO.
  2. Applications must be explicitly configured for SLO.
  3. The SLO endpoint must be reachable by the user and/or the Login service.
  4. The SLO endpoint must successfully process the protocol-specific SLO message.

While none of the requirements above are problematic in isolation for a single service, the likelihood that all are met for all services accessed during an SSO session is uncommon at Virginia Tech. The largest obstacles are #1 and #2; many CAS clients, notably mod_auth_cas, do not support SLO, and those that do may not be correctly configured.

Some notable SSO integration libraries that DO support SLO are mentioned below:

  1. Jasig Java CAS Client
  2. Spring Security
  3. .NET CAS Client
  4. phpCAS
  5. Shibboleth SP 2.x
  6. SimpleSAMLphp

Recommendations for Handling Logout

Logging out of an application is simply the act of terminating the application session, but it is vitally important to note that with single sign-on the user can simply return to the application and obtain a new session without having to provide credentials. That may or may not be problematic depending on the application security requirements. There are two ways to prevent that behavior:

  1. Terminate the SSO session immediately following the termination of the application session.
  2. Enable forced authentication such that it credentials are always required to start a new application session.

The latter is preferable in terms of both security and usability. This is consistent with the following guiding principle around single sign-on: let the user choose. The princple leads to the following general recommendation for handling application logout; when the user logs out of an application, display the following message:

You have logged out of $APPLICATION but you are still logged in to Virginia Tech. Please click the button below to log out of everything.

The link button to log out of everything should point to https://login.vt.edu/profile/Logout.

Non-interactive Authentication

Login provides a means for service principals to access SSO-protected resources. A common case would be application monitoring software that needs to authenticate to Login in order to reach an SSO-protected application. An ED-ID service certificate (Middleware CA issuer) may be used as an authentication credential. An alternate port, 9443, is specified in the protocol endpoint URL in order to trigger client SSL on the HTTPS communication channel. We provide a reference Python script to document the message exchange needed in order to get a service ticket to access an application that uses the CAS protocol. Sample usage follows:

marvin@seiche$ python login-cert-auth.py https://cas-sp.middleware.vt.edu/phpcas/secure.php

Note that in order to execute the script, it will need to be modified for your environment.