Follow

What Is SSO?

Associations often want to allow user to log into both their association website and the cobalt portal with one set of credentials, especially if they're using Cobalt's Widgetized Web Elements. This allows them 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.

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.  

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 is you have content on each site that is behind a login and that you want users to access. If you only have login-protected content on one of the sites that you want users to access, then SSO is extraneous and you can skip it. For example, if you have embedded Cobalt Web Elements and want users to log into the widgetized portal to access Cobalt content but have no website content that is login protected, then SSO is unnecessary since the Cobalt portal has its own login. Alternatively, 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) then SSO is unnecessary since your website will have it's own login.

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
  • A Service Provider (or SP), which is a login-protected website that offers it's own services (like a WordPress site or a CRM)
  • 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.

In Cobalt's world, the IDP is most often the Cobalt CRM (though not always) and the SP is the clients Content Management System (CMS), Learning Management System (LMS), or other software.

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.

To learn more about SSO in general, read this article

To learn more about SAML SSO specifically, read this article

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk