What is SSO?
SSO, short for “Single Sign On”, provides a way to authenticate into multiple systems by only providing one set of login credentials(often username and password) only once within a relatively short time interval. There are several different methods and technologies to provide Single Sign On services, and one of the primary systems used by campus is web based SSO via software called Shibboleth.
What is Shibboleth?
The Shibboleth Identity Provider software is a secure open source software used by many higher education institutions and many companies throughout the world. It provides the means to authenticate, using our own campus credentials, to services and systems we’ve partnered with it. At the time of this writing, our campus has partnered with over 100 systems and services to enable SSO for those services.
How does SSO work?
When you visit a service that has been previously partnered with our campus SSO system, that service will redirect you to our campus SSO login page to sign in using your campus credentials. This often happens fairly transparently, but some services require you to put in some information first, such as email address, so that the service can know which login page to take you to(some services are partnered with many SSO systems at many institutions). Once you’ve successfully put in your campus credentials, and perhaps MFA(Multi Factor Authentication) if it’s required, you’re taken back to the service you originally wanted to get into.
Since I’m putting in my campus credentials on our own SSO system, how does the service I’m trying to get into know it’s really me?
Our SSO system must be partnered with services ahead of time. This establishes a trust relationship with that service. When you enter your campus credentials on our SSO system, a special message is crafted by our SSO system and given to your computer’s web browser that tells the service that we’ve verified the credentials, and also gives the service a little bit of information about you to identify you to that service. These special messages are signed and encrypted wherever possible(a few services don’t offer support for this), and communication channels between our campus SSO system, your web browser, and the services we access are handled over secure, encrypted connections.
What is the information being passed to these services?
Information that’s allowed to be passed to any service is only directory level information, and only the information that’s actually required by any particular service to function is actually passed to each service. No service can get any more information than it actually needs to get a user into the service to use it. The most common pieces of information sent to identify a user for the use of a service is person number and/or email address since those are unique to each person. Some services also request things like first name, last name, and affiliation(student, staff, faculty). This is usually to provide a better experience within the service to make it feel tailored to each person.
Does our SSO system talk directly with the service I’m trying to get to?
No. All the messages generated by our SSO system and the service you’re attempting to access are given to your web browser and used by your browser for the SSO system and the services you’re attempting to access. The messages are generated very specifically and are signed and encrypted wherever possible(a few services don’t offer support for this) to protect you and your account. In addition, the communication channels between our campus SSO system, your web browser, and the services we access are handled over secure, encrypted connections.
Sometimes I get an error in my web browser that says “Web Login Service - Stale Request”. What does this mean?
The SSO system is workflow based. It proceeds very systematically, by design, to get someone logged in to a particular service being requested. The SSO system must know what service you intend to access, so it can generate messages appropriately. Also, once you’re logged in, there’s really no use of logging in again. If you attempt to go back to the workflow that’s already completed, the SSO system doesn’t know what to do with that request since the workflow was completed and the SSO system has already forgotten about it.
So the two most common reasons for an error page that says “Web Login Service - Stale Request” are:
- An attempt was made to get to the SSO login page by itself, such as a bookmark or a link that may have been emailed out, so the SSO system didn’t know what service you were trying to log into, or
- the browser’s “back” button was used and you were taken back to a workflow that was already completed and no longer valid.
There may be other reasons that this page occurs, but is usually dependent on the browser doing something it shouldn't be doing and is unique to specific cases. Therefore isn't easy to troubleshoot. Clearing the browser's cache/cookies completely may solve this issue if it keeps occurring.
I’ve noticed that I don’t always get our SSO login page when I try to go to some services. Why is this?
One of the other benefits to an SSO system, other than not having to remember more than one password, is to provide a brief period of time where the SSO system “remembers” that you’ve already put in your campus credentials. The first time you attempt to login to a service that requires campus credentials on our SSO login page, a four hour timer starts. If you try to access another service that requires SSO login within that four hours, you are not required to enter your campus credentials again. Further, that four hour timer is extended for another four hours. This happens up to eight hours after the first login that required campus credentials.
To use an example, if you attempt to get into a service that requires you to put your campus credential into our SSO login page at 8AM, then you need to access another service protected by our SSO system at 11:50AM, you will not be required to enter campus credentials again at 11:50AM and the timer that requires you to enter campus credentials if you attempt to access a third service is extended to 3:50PM. Since 8AM was the first login, the timer cannot be extended past 4PM. After 4PM, you would be required to enter your campus credentials again, should you need to access another service protected by our SSO system.
I’ve noticed that particular services I log into still log me out or interrupt my session in less than four to eight hours. Why is this?
Our SSO system keeps its own timer of when you should have to put your campus credentials into the SSO login page again. However, this is different and separate from the timer each service has to keep you logged into any given service. The length of time that each service keeps your session available within any particular service is almost always something beyond our control. However, if the timer for our SSO system is still active, you should be able to get back into the service again without retyping your campus credentials. If you were in the middle of some work and the service’s timer expired, it’s also up to the behavior of the application to recover that work in a friendly way, not the SSO system since the SSO system can only authenticate you to the service again.
Why does it seem inconsistent as to the times that I need to put in my campus credentials?
This is mostly a combination between what services you need to access throughout the day and when you access them. Keeping in mind that you get four hours from the first time you enter your campus credentials before you have to re-enter them again, then potentially an extension of four hours if you access another service protected by our campus SSO system sometime within those first four hours, and the fact that all the services partnered with our SSO system have different session timeouts of their own, it can definitely feel inconsistent. However, the background rules are always the same, and the only thing that ever changes is what services we access and when. It may also depend on if you use multiple web browsers.
I use multiple web browsers. I seem to see the SSO login page very frequently in all the browsers I use. Why?
Since our web based SSO system is strictly web based, the SSO timer and service sessions don’t get shared between web browsers.
When I click the Logout button in a particular service, I’ve noticed that if I go back to the service, I just get right back in. Is this normal?
Most likely, so long as the timer our SSO system uses is still valid. You are likely getting taken to our SSO login page, but since you’ve already entered your campus credentials earlier, you just get taken back to the service and logged in there again.
What is SLO?
SLO, short for “Single Log Out”, provides a way to log out of every logged in service at once. Our campus currently supports SLO. However, at the time of this writing, out of the 100+ services that we are currently partnered with, only about 15 of them fully support SLO. This means that SLO only works for those particular services. Since support for it is relatively low and beyond our control, SLO is considered a “best effort” attempt. For our campus, when using SLO, we forcibly expire the SSO timer so that entering campus credentials again when accessing the next service protected by the SSO system is required. Then, a specially crafted SLO message is sent by your web browser to any service that supports SLO and tells those services to log out any existing sessions. Any other service sessions that don't fully support SLO are still considered "logged in".
How confident should I be in the “Logout” buttons I see in various services?
Not very, but it is still highly recommended to log out of any service you’re currently in and close your browser completely at the end of your browsing session. If the SSO timer is still active, you’re likely to be able to get back into the services you’ve just logged out of. If SLO was involved, then the SSO timer is taken care of, but any service that doesn’t support SLO may still have an active session for as long as those services have their own session timeouts set. The best approach to having the convenience of a Single Sign On system is to practice good security all around. Lock or log out of your devices when you’re not using them and/or when you’ve stepped away from them. Closing your browser completely when you’ve finished is also effective. However, it should be noted that clearing out sessions when a browser is closed is still a behavior that is determined by the service, and almost always out of our control. Also, many modern browsers allow you to “sign in” to the browser itself to keep your experience across multiple devices the same. This sometimes includes the sessions of services you’ve logged into, and is again, a behavior that is determined by the service and sometimes, even your web browser.