Single Sign-on (SSO) allows a user to use a single set of login credentials – such as a username and password, or even multi-factor authentication – to access multiple applications. This is a Federated Identity Management architecture, sometimes called identity federation. In order for SSO to work, most applications rely on open standard protocols to define how service providers (SPs) and identity providers (IdPs) can exchange identity and authentication information with one another.
For more information on how SSO works and the benefits of one of the most common protocols, SAML, visit our SAML for Single Sign-on page.
To seamlessly integrate all applications PortalGuard’s Single Sign-on Solution supports many types of SSO protocols, including:
Central Authentication Service (CAS)
Developed by Shawn Bayern at Yale University, CAS differs from typical SAML SSO by enacting Server-to-Server communication. The Client Machine is used to initiate the token request, but the final verification is handled by a back-end communication between the CAS server and the Service Provider. CAS is a typical SSO protocol used in education organizations because of reliance on that extra, more direct verification. Like SAML, no passwords are exchanged through the SSO token.
CAS is a common SSO protocol for higher education. Check out the SSO for Education page for more details.
Shibboleth SSO
Shibboleth is another SSO protocol typically seen in educational organizations – specifically where a high number of institutions are federated to share applications and/or services. Shibboleth is built with SAML as a foundation but uses Discovery Service to improve upon SAML’s organization of data from a large number of sources. Additionally, Shibboleth helps to automate the parsing of metadata to handle security certificate updates and other configurations that may be set by individual institutions within a federation
Cookie-Based SSO
Works by using Web based HTTP Cookies to transport user credentials from browser to server without input from the user. Existing credentials on the client machine are gathered and encrypted before being stored in the cookie and sent to the destination server. The server receives the cookie, extracts and decrypts the credentials, and validates them against the internal server directory of users.
Claims-Based SSO
Claims (aka “assertions”) are created by a claims issuer that is trusted by multiple parties. Claims are typically packaged into a digitally signed token that can be sent over the network using Security Assertion Markup Language (SAML).
NTLM-Based SSO
It is possible for a user to prove they know their password without actually providing the password itself. NTLM achieves this using a challenge and response protocol thatfirstdetermines what type of NTLM and encryption mechanisms the client and server mutually support, then cryptographically hashes the user’s password and sends it to the server requiring authentication.
Kerberos-based SSO
Kerberos enables users to log into their Windows domain accounts and then receive SSO to internal applications. Kerberos requires the user to have connectivity to a central Key Distribution Center (KDC). In Windows, each Active Directory domain controller acts as a KDC. Users authenticate themselves to services (e.g.web servers) by first authenticating to the KDC, then requesting encrypted service tickets from the KDC for the specific service they wish to use. This happens automatically in all major browsers using SPNEGO (see below).
SPNEGO-based SSO
There are instances when the client application and remote server do not know what types ofauthenticationthe other one supports. This is when SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) can be used to find out what authentication mechanisms are mutually available. Some of these mechanisms can include Kerberos and NTLM authentication.
Reduced SSO
Reduced Single Sign-On is widely used for limiting the number of times a user will be required to enter in their credentials to access different applications. With critical applications, reduced SSO also offers a technique to make sure that a user is not signed on without a second factor of authentication, having been provided by the user.
Enrollment-Based SSO
A user logging into a website may choose to have their credentials permanently remembered for that site. This is accomplished by creating an encrypted cookie on the user’s machine for that web browser that contains the user’s credentials. This cookie persists across different browser sessions and restarts of the machine but will be set to expire after a set period. The next time the user accesses the website, the server recognizes the cookie, decrypts it to obtain the user’s credentials, and completely bypasses the login screen after validating them successfully.
Form-Filling SSO
Form-filling allows for the secure storage of information that is normally filled into a form. For users that repeatedly fill out forms (especially for security access), this technology will remember/store all relevant information and secure it with a single password. To access the information, the user only has to remember one password and the Form-filling technology can take care offillingin the forms.
Banner XE/Banner 9
Banner XE/Banner 9 supports CAS SSO. While not the newest SSO protocol, CAS SSO improves Banner’s usability. Additionally, CAS SSO simultaneously increases the integration points for Banner in various institutions. Higher education institutions that are looking for additional, more feasible options, may land on using Banner XE/Banner 9 to fill the gap. CAS SSO opens Banner XE/Banner 9 up to more unique configurations and deployments.
See PortalGuard’s Single Sign-On in Action
Enjoy this brief demo ofPortalGuard’s Single Sign-Oncapabilities thensign up for our free trialto try it out for yourself.
