ITS Operations : Single Sign On - SSO

Overview

RIT uses a web single sign-on service to provide a common authentication and authorization interface for web-based applications. Historically each web application either needed a data feed or had to be integrated with LDAP and each site prompted a user to provide credentials to login. Single sign-on resolves many of the issues around security and integration while providing users with a more friendly experience.

What is single sign-on (SSO)?

Single sign-on allows users to provide their username and password at a familiar login page one time to access the various web sites that are affiliated with RIT. Some of these sites are hosted by ITS, some are hosted by other IT groups around campus, and some are hosted in the cloud by third-party vendors. This login session is valid for four hours and can be used to login to any other sites using SSO without the user being prompted for a password again.

Because this login session can be used to access to hundreds of sites, including SIS, eServices, Parking, and Google Apps, it's critical that the browser be closed to destroy the session when the user is done using SSO-protected sites. If the browser cannot be closed, such as on a shared computer or a mobile device, then it's recommended that Private Browsing or Incognito mode be used.

What isn't single sign-on (SSO)?

Single sign-on isn't various sites each prompting for the same username and password.

What is Shibboleth?

Shibboleth is the software that powers RIT's single sign-on infrastructure. There are two parts to Shibboleth: the Identity Provider (IdP) and Service Provider (SP). The Identity Provider is the central hub that verifies (authenticates) users. During the first visit to the IdP a user provides his RIT Computer Account username and password. Once that has been authenticated a single sign on session is established. That session is reused for each new service that requires authentication. Along with that session is a profile containing information including the type of user, contact information, enrollment data, campus employment information including department and organization, and any groups.

What role does LDAP play in authentication?

LDAP is still used as a directory but is being phased out as an authentication method. Shibboleth is now the preferred method for web authentication.

Among its advantages are:

Single sign-on with both RIT applications and third-party applications.
Ease of integration with existing applications
Increased security due to a consistent, trusted login page for all applications
Applications are only able to access information about a user when a user logs in
Ability to provide services as part of a federation

Who can authenticate?

Anyone with an RIT Computer Account. This includes:

RIT Employees
Non-RIT Employees
Prospective Students
Students
Alumni
Third Party Users (Parents/Vendors/Etc.)
Retirees
Affiliates
Guests

While this provides flexibility it also means that those who deploy single sign-on, the service providers, need to evaluate that the appropriate population is allowed access while restricting users who should not have access.

What attributes can I access?

Examples of attributes you can request includes:

uid - the user's RIT username
givenName - the user's given (first) name
sn -the user's surname (last/family name)
mail - the user's email address
ritEduMemberOfUid - groups the account is a member of (Ex: forklift-operators, vendingmach-admins, historyintegrator, etc.)
ritEduAffiliation - multi-valued attribute showing relationship to RIT (Ex: Student, Employee, StudentWorker, Retiree, etc.)

A full list of attributes along with how they are organized and maintained can be found at Directory Schema.

How do I integrate with RIT's SSO service?

If you plan on running your own service please review the Deploying SSO information.

If you plan on using www.rit.edu, apps.rit.edu, or people.rit.edu use the Web Developer documentation as a reference.

If you plan on integrating with an outside vendor or are internally hosting an application that is SAML/Shibboleth capable, please submit a request with the RIT Service Center for assistance.

Note: There are many applications that natively support SAML/Shibboleth authentication. For those that do not, it may be possible to easily retrofit the application to work with SAML/Shibboleth due to the Shibboleth software's flexibility.

Responsibilities

See https://en.wikipedia.org/wiki/RACI_matrix#Role_distinction for definitions.

Activity	SSO Service managers	Server administration team or vendor/hosting provider
Configuration of RIT's back-end Shibboleth Identity Provider (IdP) infrastructure.	Responsible, Accountable
Installation and configuration of Shibboleth Service Provider (SP) on a server to connect to RIT's Shibboleth back-end Identity Provider (IDP).	Informed	Responsible, Accountable
Providing information required for the back-end IdP to be configured to connect to the SP configuration on a server: Location of the service provider's metadata (The Shibboleth Service Provider software makes this available at https://yourhostname/Shibboleth.sso/Metadata) Contact information of the application or server administrator. The purpose of the application. A list of desired attributes. Example: first name, last name, title, etc. Also include: How the attributes will be used (authorization of users, profile information, etc.) A full list of attributes along with how they are organized and maintained can be found at Directory Schema. If the attributes will be stored If the server complies with the ISO server security standard	Informed	Responsible, Accountable
Providing documentation and roles/responsibility information to assist administrators responsible for shibboleth configurations on their servers.	Responsible, Accountable	Informed

Note: There are a large number of SAML products that could potentially be used on your server to connect to RIT's IdP. More information can be found here: https://en.wikipedia.org/wiki/SAML-based_products_and_services. Please understand that ITS cannot be familiar with each of these potential applications that you might install and configure on your server, and the server administrator is always ultimately responsible for your servers configuration, including the SSO aspects of that configuration. Although ITS can provide a number of basic and example configuration files for the Shibboleth SP software, ITS cannot configure your server for you, or learn and understand all possible SAML applications that you might choose to install and use.

Glossary

Authentication - Verifying that the identity of a person based on a private piece of information. Typically this is a password/passphrase, a unique token, or a combination of the two.
Authorization - Determining if a person is permitted access to protected content based on a set or characteristics about that person. For instance, a student may have access to different services than would an employee.
Identity Provider (IdP) - Service that provides authentication and profile (identity) information to a Service Provider. It also handles the single sing on functionality. Also known as the SSO server or Shibboleth server.
Metadata - Information detailing how the SP and IdP can communicate. Typically this includes a public key and URLs detailing how and where information is passed.
Service Provider (SP) - It is the client to the Identity Provider and is the service that provides the protected content to a user. Access is granted based on authorization rules that are applied to the profile information received from the Identity Provider.
Security Assertion Markup Language (SAML) - An XML-based open standard for authentication and authorization. It provides a method for an IdP and SP to communicate to determine if a user should be granted or denied access to a protected resource.