Single Sign-On (SSO) is the concept of allowing logged in users to access a secure External Application (EA) or site without having to physically log into that external site. For example, a user clicks on a link in the portal and goes directly to the user’s personal page on the external site without having to log in. The user exists in both applications, but there is no user Id that is common to both systems. How does the external application know which user is trying to log in, or if that user can be trusted without forcing him to log into the EA? This is where SSO comes in.
The SSO API creates a trust in the form of personal information that is common to both systems such as first name, last name, SSN, email, etc. The SSO API allows for the creation of user information tokens that trusted external applications can use to obtain that private information to automatically log in members to their systems. The token (guid) is supplied to the EA, usually in the form of a query string which is then sent back to get the user information. Once the EA has the personal user information, the applications can map to and authenticate an existing member on their systems. The SSO API therefore facilitates the creation of the token (by internal applications) and the obtaining of user information (by external applications).
The SSO configuration allows for different student (or staff) information groups to be used in the authentication process. Thus, EA #1 might want to complete the auto-login process with FirstName, LastName, SSN, and Email, while EA #2 would want StudentCode, LastName, and PhoneNumber. By setting up the different configurations, all external applications can be satisfied. The SSO API handles the retrieval and update of these configurations. The list of all possible information properties (FirstName, StaffCode, Email, etc.) for Student and Staff are also provided for ease of use. Thus, the SSO API facilitates the creation and retrieval of the configurations for use by an internal configuration application.
Once set up properly, the user clicks on a link and seamlessly accesses the user’s personal page on the external site without having to log in. The following process flow shows the sequence of events in an automatic login to an external application:
Note: For security concerns, the API’s GetSSO method will probably not be directly exposed to external clients. Instead, a DMZ page will pass the request through to the API, and pass the user info back to the external client.
Topics in this section:
