BGSU Single SignOn (SSO) Application Integration Requirements

Single SignOn (SSO) provides a mechanism by which users may be authenticated to web applications by a trusted source within BGSU. This may include web applications maintained by BGSU as well as web applications outside the bgsu.edu network with which BGSU has an agreement to provide authentication of BGSU users for a specific application. The benefit of SSO is that it provides a single common interface for the user to identify themselves to many applications without having to manage a password within each of them and which uses secure communications mechanisms.  The standard SSO protocols used by BGSU are CAS (Central Authentication Service) and SAML (Security Assertion Markup Language).  

BGSU provides this service using SSO systems that accept the user’s credentials through secure communications channels and send secure tokens to application servers that provide trusted identification of the user associated with the identifier (uid, email, etc.).  Application managers should be aware that this facility provides only authentication (verified user identification) and it is up to the application to determine what resources the user is authorized to access.  The BGSU SSO systems may also send additional user attributes (other identifiers, affiliations, etc.) to aid the application with authorization decisions. 

In order to utilize the BGSU SSO systems to authenticate users for an application, the administrator of the application should address each of these SSO integration items:

Protocol / Method – For SSO integration, BGSU supports either CAS (www.jasig.org/cas), which is preferred, or SAML (the BGSU IPD uses Shibboleth - https://shibboleth.net/).

Principal identifier - Application managers should indicate what identifier is needed for the application (depends on method above).   The BGSU uid is suggested, while email address provides an identifier that should be unique outside bgsu.edu.   Be aware that either uid or email address could change for a given user (marriage, etc.).

User attributes - What attributes are needed by the application (commonly used are uid, email, first name, last name, etc.)

Implementation Process - SSO integration will be tested first using the test BGSU SSO systems and all portions (including logout below) verified before implementing in production.  If no test application environment will be available the production application should be verified against test SSO before moving to production SSO.

Application vendor should exchange necessary URLs, configuration details, metadata, etc. as needed for integration according to the method to be used.

The BGSU SSO systems have been designed to provide user access to necessary applications and services while attempting to protect the user’s data from unintended access that could occur as a result of having multiple different authenticated sessions active.  BGSU will enable SSO integration only after it has been tested and approved to comply with industry best practices for safely handling user authentication and Single SignOn session.  BGSU utilizes the following resources as guidelines and refers to them when completing SSO integrations:

• https://apereo.github.io/cas/4.2.x/planning/Security-Guide.html
• https://wiki.shibboleth.net/confluence/display/CONCEPT
• https://www.incommon.org/policies.html

The following items should be considered when completing SSO integrations:

• Logout must be complete according to BSGU requirements – see below
• The user name should be displayed on each page in an active application session
• A logout button should be readily available and clearly indicated (preferably at top right)
• There should be no password prompts or option items to change or otherwise manage password within an SSO integrated application (passwords should be managed by the SSO authentication provider, so references to passwords may be confusing to users).

Logout is given particular attention in the SSO integration process in order to protect against others gaining access, inadvertently or intentionally, to active application sessions that the user had opened.  While SSO provides authentication which is used to open any number of user specific sessions in various applications, it does not maintain any sense of which application sessions may be active at any point in time.  This could result in exposure of active sessions if SSO logout for each application is not managed properly and consistently.  When a user logs out from an SSO authenticated session, if any other active application sessions are not logged out, then they could remain after the user leaves a terminal (potentially in an open area such as a lab, etc.) allowing access to those authenticated sessions.  Complicating this situation is the fact that logout links within an application do not indicate which applications / SSO components will be logged out which could lead to a user leaving authenticated sessions when the leave a system.

The BGSU means to address the logout issues above is to make every attempt to close all SSO authenticated applications when the user clicks a logout link from a page in any of the SSO authenticated applications.  There is an established understanding within the BGSU community that logout from an SSO application will end all SSO application sessions.

For this to be completed appropriately it is required that any SSO authenticated application will utilize these logout mechanisms before SSO integration will be completed with the BGSU production SSO systems.

Application logout redirect to BGSU global logout page - BGSU will maintain a global logout page - https://sso.bgsu.edu/sso/logout (ssotest.bgsu.edu for test) - that includes calls to log out all active SSO authenticated sessions that the user may have open.  When a user clicks a logout link within a page of an SSO authenticated application, after the users application session is properly closed it must redirect the user's browser to this BGSU global logout page.  See below on preventing looping for more details.

SLO or URL for logout of application session - The application should provide a means by which the BGSU SSO systems can trigger closing the user’s active application session, so that when the SSO session is ended the application session can be ended also.  The preferred method for this is SLO (Single LogOut) which may or may not work depending on variables in the SSO protocol used (CAS appears to work more consistently).  If this method does not work then the application manager should provide a logout URL that will end all portions of the user session related to that application (both local application session and any related SSO components - eg. Shibboleth SP session, etc.).  This URL will be added to the BGSU SSO logout page to trigger logout of all application sessions when the SSO session is ended.  This logout URL should not redirect to the BGSU SSO logout page after closing the application session in order to avoid looping.  Thus, this URL should be separate from the one used to trigger logout within the application, or it should only redirect to the BGSU SSO logout page if there was an active session closed.

Testing - the correct functioning of the above elements will be tested before moving to SSO production to verify that the redirects to the BGSU SSO logout page are occurring and looping is not.  This testing will be completed with logout from the application being integrated as well as from another SSO logout source (ie. BGSU portal logout).