Single Sign On using SAML 2.0

Overview

In this article, we'll consider some of the challenges faced by users and IT manager regarding authentication, and adherence to enterprise security policies,and consider the benefits of using Single Sign On to help alleviate some of these concerns.

Drawbacks of standard authentication

In a typical enterprise setting, a user can easily leverage dozens of different tools and platforms, each of which could require user account and login credentials. The cognitive load for remembering all these complex, and unique passwords is increasing for users at all levels of technical proficiency. More often than not, security best practices are not followed; passwords are often reused, or are forgotten frequently and must be continually reset. Corporate IT security policies compound the issue by requiring users to cycle their passwords frequently, making them even more difficult to remember. Another issue that arises is the IT operational load for de-provisioning all the associated accounts when an employee leaves the organization or their department and no longer require access. Not only must the user’s enterprise access be deactivated or updated, but also all associated 3rd party accounts for that user.

Using SAML for Single Sign-On (SSO)

To alleviate some of issues described above, ConceptShare features support for SAML 2.0

Using SAML, you can configure and leverage your organization's authentication services to grant your users access to ConceptShare, using their existing domain credentials. There are several benefits to this approach, but let's first look at the high-level user workflow of logging in with SAML:

1. An unauthenticated user arrives at ConceptShare and attempts to log in using the Single Sign On login button (see: SAML User Interface further below).
2. They click the Login button and are redirected to your organization's authentication service's login page.
3. If the user can successfully authenticate using your authentication service's login page, the service will redirect them back to ConceptShare, along with a security "assertion"; essentially vouching that this user is who they claim they are.
4. Once ConceptShare gets sees this assertion, the user is identified and given access to their ConceptShare account.

Benefits of using SAML SSO

1. Lower cognitive load for end-users
   One less password and username for the end-user to track.
2. Lower IT overhead
   If you opt to use SAML as the only method of authentication, your IT team can toggle access directly at the source, using the company directory, rather than having to log into ConceptShare. There's no longer a need for your IT to duplicate their password policies in ConceptShare in order to maintain security compliance, since the user is leveraging the organization's own authentication services. IT only needs to manage security policies in one centralized location.
3. Better Security
   If you opt to use SAML as the only method of authentication, the problem of users creating weak passwords, or reusing passwords across multiple services is addressed. At no point is ConceptShare privy to the user credentials or authentication details. The authentication is compartmentalized and entirely handled by your organization's service. By leveraging SAML, your enterprise services authenticate your users in complete isolation, without giving ConceptShare any unnecessary exposure or visibility to users' credential details. This mitigates against the possibility of ConceptShare being used by a nefarious 3rd party, as a potential escalation point for a coordinated security attack.
4. Flexibility
   As you'll discover below, SAML is configurable in ConceptShare and allows you to target specific groups of users to authenticate via SAML, while allowing external users the flexibility to use ConceptShare's standard authentication.

Available Configurations

Depending on the needs of your organization, there are a few different ways to leverage SSO for your account.

1. FORCED for everyone
   You can force SAML authentication for all users on an account, meaning no one can use ConceptShare unless they are able to use your company's authentication service.
2. TARGETED only for users with specific email domains
   You can force SAML only for users with emails from specific domains or sub-domains, while allowing other users to login the old fashion way. This can be useful if you have, for example, both internal users (ex. employees that should only use SAML), as well as external users (ex. contractors or clients) that would also want access to your ConceptShare account but wouldn't be in your company's directory. In this case, you can force SAML for those with specific email domains. For example, you can setup ConceptShare so anyone with emails ending in @yourcompany.com and @department.yourcompany.com are all forced to use SSO, while still allowing your external users to access ConceptShare using the standard authentication.
3. OPTIONAL for all users
   You can enable SAML for convenience. Anyone who has domain credentials can use SSO to log in, but would maintain a ConceptShare password as well, just in case they need to login from outside the corporate domain, or as a fail safe in case the company authentication services are down for some reason.

Single-Sign-On User Interface

When you enable SAML in ConceptShare, your account login page will display some new and customizable elements. If using Forced SAML, the UI won't display the right side of the login screen as that mode of authentication will not be allowed under any circumstance. Optional and Targeted SAML will display the mixed-mode authentication UI, as shown below.

If you force SAML by domain, item 5 (pictured above) shows the error message an end-user from that domain would see if they tried to use the standard authentication method instead of using SAML login button on the left hand side.

Enabling SAML for your Account

Refer to Configuring Single-Sing-On In ConceptShare for a step-by-step breakdown of how to configure ConceptShare's SSO features to work with your enterprise identity provider.