Single-Sign-On (or SSO) is a method for accessing multiple related yet independent software systems. With a single set of credentials, a user can access any of the software systems that have been related to each other.
Associations often want to allow their users to log into both their association website and the Cobalt portal with one set of credentials. Additionally, some association websites may include buttons and links to separate independent software systems like an LMS that also requires login. Having SSO would allow users to access the restricted content that is behind login on the association website, Cobalt portal, and the LMS after signing in a single time. This allows associations to create a more seamless experience for their members.
Because of this, Cobalt uses a Single-Sign-On (SSO) protocol called Security Assertion Markup Language (SAML) to allow easier login.
Should I Use SSO?
Before you decide to use SSO, you should determine if it's necessary for your goals. SSO allows users to log in to two or more websites at once with one set of credentials. This is useful if you have content on each site that is restricted and behind a login that you want users to access. If you only have login-protected content on one of the sites that users access, then SSO is extraneous and you can skip it.
Examples of when SSO would be useful:
- If you have website content that is login-protected and you use the standalone Cobalt portal, setting up SSO is helpful so that users will only need one set of credentials to be logged into both websites.
- If you have website content that is login-protected and are embedding login-protected Cobalt Web Elements (like the User Dashboard, My Meetings, or My Orders that require login) then setting up SSO is helpful so that users will only need one set of credentials to be logged into both websites.
Examples of when SSO is not needed:
- If you have embedded Cobalt Web Elements and want users to log into the embedded portal to access Cobalt content but have no website content that is restricted, then SSO is unnecessary since the users will only need one set of credentials to login to the portal.
- If you have website content that is login-protected but are only embedding unprotected Cobalt Web Elements (like the Member Directory or the Calendar of Events that do not require login) then SSO is unnecessary since users will only need one set of credentials to login to the association website.
Why Should I Use SSO?
1. One benefit of SSO is it will allow your users to remember just one password.
2. Another benefit is that it enhances the user experience by making the process quick and simple. Instead of having to enter credentials and login each time they try to access restricted content of the different websites (CMS, Cobalt portal, LMS, etc.), users will login once and then gain access to all the restricted content that has been configured for SSO.
How Does SSO Work?
In Cobalt products, we currently support SSO through Security Assertion Markup Language or SAML. This is an XML-based method and, while we won't go into detail on the technical components here, the basic process is illustrated well in the image below.
In a SAML configuration, there is
- An Identity Provider (or IDP), which is a login-protected website that offers its own services (like a CRM or a dashboard service) and holds all users credentials. The IDP performs authentication. The IDP will check the username and password to verify the identity of the user.
- A Service Provider (or SP), which is a login-protected website that offers its own services (like a WordPress site, CMS, LMS, or a CRM). The SP is the application or independent software system that the user is trying to access.
- The User, who wants access to the IDP and SP's services.
The User requests access to the SP's services, the SP redirects them to the IDP which authenticates the user (usually after the user logs in) and sends an Authentication Token to the SP to confirm that the user is a legitimate user and is allowed access to the SP services. The user is now logged into the IDP and the SP and has access to both software services.
Most Common SSO Configuration for Cobalt
In Cobalt's world, the IDP is most often the Cobalt CRM (though not always) and the SP is the client's Content Management System (CMS), Learning Management System (LMS), or other software. For example, many associations use WordPress for their CMS. We will configure SSO where Cobalt is the IDP and WordPress is the SP.
In some instances, like with Clareity Integrations, Cobalt's CRM is the SP and Clareity is the IDP. There are even instances where CRM is one of the SPs, alongside the clients CMS or LMS and Clareity is the IDP.