What is Single Sign On?

Document created by Ike Bennion Employee on May 26, 2016Last modified by Annie Battad on Jan 2, 2020
Version 14Show Document
  • View in full screen mode


Bridge allows a client to configure a number of ways to authenticate into Bridge. This document provides a high level overview of what Single Sign On is and what it means for a Bridge client. Those who feel like seniors registered in a freshman course should go ahead and check out articles on SAML or CAS



What is authentication?


Bridge keeps your system information secure by requiring credentials for log in, but also allows you to control access to users you want. This is done through a process generally called "authentication".


Currently, Bridge allows for three means of authentication:

  • Bridge Basic (comes default with every account)
  • Security Assertion Markup Language (SAML, pronounced "SAM-el", rhyming with "camel")
  • Central Authentication Service (CAS, pronounced, "CAZ" rhyming with chaz? spaz? I dunno, there aren't great words that rhyme.)


Clients would opt for SAML or CAS over Bridge Basic for a couple of reasons:

  • Single Sign On (SSO)
  • User provisioning



Single Sign On (SSO)

A company with a number of web services will often think about configuring a Single Sign On solution to authenticate to these web assets since SSO will allow users to sign in to an entire environment by having a user submit a name and password once.


The easiest to understand and most widespread example of this is Google. When a user signs into Gmail, for instance, they are also signed into Google Calendar, Google Drive, Google Finance and other Google tools with a single user name and password input.


Like Google, the use of SSO allows users to pass through multiple web services quickly and easily. For instance, a user could log into a CRM, then navigate to an HRIS and then to a web-based email, all configured with SAML. SSO also allows a company to enhance security by leveraging features common to SSO solutions like mandating passwords to be changed every 60 days.


User Provisioning

Bridge also allows users to be created through a process called provisioning, commonly referred to "just in time provisioning" and "auto provisioning". An authentication solution (SAML, LDAP or CAS), can create a user based on what a company chooses to pass as an alias to Bridge. Meaning, when a user logs in via an authentication protocol, the protocol will tell Bridge which user is logging in by passing a unique identifier or alias. If user provisioning is on and a user has not yet been created in the system for the unique identifier that is passed, Bridge will create a new user account and log the user in immediately. It is important to note, however, that only the alias will appear in the user's profile. All other user data such as first and last name will have to be uploaded later through manual CSV or Auto CSV.



So what do I need?


Bridge is secure and will work great without any authentication services configured with it. If a company would like to configure an authentication solution with Bridge, they first need to acquire an authentication solution. There are many that are geared to be more "out-of-box" and provide standard features with easy set up while some provide a lot of levers that a company can use to control experience and security.


Bridge doesn't have recommendations for any authentication service over another, a simple search of SAML or CAS providers will provide you a number of companies that are eager to help you set up. The more adventurous may have technical knowledge in-house on standing up their own SAML or CAS servers. For additional information however, check out the Additional Reading for articles with more depth on SAML and CAS.



Additional Reading


CAS Documentation

Configure Google SAML with Bridge

Configuring ADFS 2.0 with Bridge Using SAML

Configuring Okta SSO with Bridge

SAML Overview



7 people found this helpful