The Virginia Tech Login Service is a Web single sign-on (SSO) service that supports the following protocols:
As with all Middleware services, 3 tiers are provided for development, testing, and production:
- Development - https://login-dev.middleware.vt.edu/
- Pre-production - https://login-pprd.middleware.vt.edu/
- Production - https://login.vt.edu/
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.
- Dev password reset - https://portal-dvlp.es.vt.edu/accounts/recover
- Preprod password reset - https://portal-pprd.es.vt.edu/accounts/recover
Middleware provides the following services around SSO:
- Initial application/service integration consultation and support.
- Consultation around identity management best practices (e.g. crypto, authorization) as it relates to SSO.
- Highly-available production tier with target 99.995% uptime.
- Highly-available non-production tiers with target 99.99% uptime.
- Change management and release schedule communicated via the email@example.com 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:
- 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.
- Identify and maintain a technical contact for your application/service.
- Engage with Middleware as needed in response to planned service changes. The minimum level of acceptable engagement is to subscribe to firstname.lastname@example.org and follow SSO-related discussions.
- Obtain data steward approval for custom attribute release policies.
- Stand up a non-production application/service environment to facilitate SSO testing.
The following sections describe technical and policy requirements that consumers must fulfill in order to use the Login Service.
There are a couple notable classes of service that can simply use the Login Service without any sort of service request or policy approval that are described in the following sections. Any services outside the simple cases must explicitly register. Please contact the Middleware Group at email@example.com to discuss registering a new application.
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:
- The user selected the “Don’t remember me” checkbox on the login form.
- 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:
- Applications must support SLO.
- Applications must be explicitly configured for SLO.
- The SLO endpoint must be reachable by the user and/or the Login service.
- 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:
- Jasig Java CAS Client
- Spring Security
- .NET CAS Client
- Shibboleth SP 2.x
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.