What is Single Sign-On?
Single sign-on (SSO) is a feature associated with logical access to multiple related, but independent information systems. Using this feature a user logs in once and gains access to all systems without being prompted to log in again at each of them. The University is using a product called Shibboleth to provide this SSO functionality.
Shibboleth is a common SSO solution for higher education institutions and facilitates federation with the InCommon communities. When you authenticate with the new MyCWU portal, you are in fact establishing a Shibboleth session and this is an integral part of how users authenticate across many different systems.
This Shibboleth session is the result of verifying your credentials against CWU directory services and then passing your session on to the Service Providers (e.g. Faculty180 and PeopleSoft) available through the MyCWU portal.
Understanding Shibboleth Single Sign-On Sessions:
In order to understand how a Shibboleth session works, we first have to define some terms.
Service Provider (SP): The service the user is attempting to access (e.g. Faculty180 or PeopleSoft).
Identity Provider (IdP): Provides for user authentication (i.e. your credentials).
For example, our Microsoft Active eDirectory service provides authentication via Shibboleth (this is the IdP) so you can gain access to Faculty180 (this is the SP). Information systems such as Canvas, PeopleSoft, and Blackboard are all identified as SPs and Shibboleth is the IdP.
There are usually up to three sessions associated with Shibboleth IdP and SP integration: the IdP session, the SP session, and the optional web application session for the service the SP is providing. The following is the most common authentication flow for the creation of these sessions at a high level.
Whenever a user attempts to access an SP-protected application for the first time, they will not have an SP session or an application session and are redirected to the IdP to see if they have a valid IdP session. When they make it to the IdP, they also do not have an IdP session at this time and are prompted to provide your credentials to authenticate.
Upon successful authentication, an IdP session is created and an associated IdP session cookie is placed in the user’s browser. The user is redirected back to the SP where the IdP session is verified and an SP session is created and an SP session cookie is placed in the user’s browser. Finally, the user is passed to the application itself where a web application session may also be created.
Upon returning to the application, the optional web application session is checked and then the SP session is checked. If either of these sessions are still valid, the user will not be redirected back to the IdP to re-authenticate. If neither of these sessions are valid, the user will be sent back to the IdP where the IdP session is checked using the IdP session cookie that was created upon initial authentication.
If the user makes it back to the IdP with the IdP session cookie and the IdP session is still valid, the user will not get prompted to provide credentials. The IdP session will be refreshed and the user will be returned back to the SP and web application where new SP and web application sessions will be created.
If the user makes it back to the IdP without the IdP session cookie, or with an IdP session cookie but an invalid IdP session, the user will be asked to authenticate.
Single Logout (SLO) & User Expectations
When you click on a logout button in an application (e.g. PeopleSoft), you have a set of expectations. These expectations combined with technical roadblocks currently keep Single Log Out (SLO) from being implemented.
When the logout button is clicked, your application session is ended, but you are not logged out of the IdP session. Therefore, if you were to revisit the application, you would be automatically re-authenticated to log in because you still have a valid IdP session cookie.
In theory, a solution would be to have the SP tell the IdP to end its session as well. Unfortunately, the IdP does not know which applications the user has sessions with, cannot inform those applications to end the user’s sessions, and cannot force those applications to end the user’s session on both the application and IdP application side. This gives you a false sense of security because you may believe that you have been logged out of all systems. It also means that you could go from application to application and have different experiences after logging out of one application.
The best way to end an IdP session after logging out of an application accessed through the web application is for you to close your browser so that the IdP session cookie is cleared. CWU Security Services recommend that, upon logging out, Service Providers (SPs) direct their users to an unprotected page instructing them to close their browser, accordingly.
Frequent Questions:
Why does CWU have Single Sign-On?
Employees and Students at CWU use multiple systems to fill their needs. For example, the Canvas system may be required for a student’s classwork, the Campus Solutions is needed to register for next quarter’s classes, and FMS is needed to submit for club approved student travel reimbursement. Providing for a Single Sign-On solution enhances the usability of the system while also provide for additional security by providing a single identity management solution.
How does Single Sign-On help me?
You won’t have to log into different applications used throughout the day. The Shibboleth session that begins with your MyCWU portal log in, will give you access to the wide variety of information services throughout your work day, until you close your browser.
What are the negatives of using Single Sign-On?
Mostly positive with a few areas needing special attention (i.e. SLO), such as training to remind you to not only log out, but completely close your browser to clear the Shibboleth session cookie. We also have to ensure that we implement the appropriate security controls around account provisioning.
How can I better protect my data and CWU data when using Single Sign-On?
You need to be aware that you are logging into a single sign on tool that will keep authenticating your credentials in the different systems until you completely close your browser. If you log out of one application and walk away from your computer, the next user of that computer will be automatically allowed into applications under your ID. When using a public computer, you always want to close completely out of all of the programs. Clearing the cache and cookie history on public machines is just one more step to control any unauthorized access to your accounts. This is a personal responsibility and all part of being security conscious and aware of potential risks.
How can we properly implement an SLO solution with Shibboleth?
The best solution is well-designed session management on the application's side combined with effective training. The Shibboleth session only last as long as your browser is open. If users are trained to close their browser as the last step of using any system than there is no need for a logout button, thus preventing any of the problems of premature logging out or confusion about what systems are closed or still logged into.
For a much more technical discussion on how Shibboleth sessions are terminated, please see this online resource: https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues
Sources: http://www.utexas.edu/its/help/shibboleth/2299
http://en.wikipedia.org/wiki/Single_sign-on
http://en.wikipedia.org/wiki/Shibboleth_(Internet2)