Resources

How Brightspot can enable single sign-on authentication for your applications

Image of Brightspot CMS customer logo

Single sign-on (SSO) authentication allows users to sign in once, and then have access to multiple different sites or pages that would otherwise require additional logins. Here's how Brightspot makes this process work and keep our customer's data and systems secure.

In a world where cyber breaches are common, organizations need to ensure that their systems are as secure as possible; however, much of the duty of security falls on individual employees’ shoulders. Things like maintaining secure passwords are a microcosm of an organization’s greater security efforts.

Managing passwords can be painful, though; sites have different password requirements, and it can be difficult to remember each one. Some users slip up and write out a cheat sheet with passwords on a piece of paper or in a Word document, but these are easy targets for malicious eyes that know where to look.

The benefits of single sign-on authentication

Single sign-on (SSO) authentication allows users to sign in once, and then have access to multiple different sites or pages that would otherwise require additional logins.

SSO is then a great way to prevent users from making security mistakes while improving their experience, saving them the hassle of having to re-enter login credentials each time they navigate to a new login portal. It’s also an effective way to lower the strain on help-desk teams since they won’t have to spend much time answering “forgot password” calls and emails.

At Brightspot, security is paramount. The highly secure Brightspot CMS helps protect customer websites, especially those who want to not only maximize security but also improve the user experience.

screenshot of Brightspot CMS login screen

How Brightspot enables single sign-on authentication

Brightspot is experienced in bolstering sites with SSO capabilities. For one, Brightspot is natively multisite, making SSO easier since users are centralized in the CMS and can be managed across multiple websites or front ends.

Brightspot’s most common method of enabling SSO, though, is via SAML authentication.

SAML stands for Security Assertion Markup Language, and it’s a way that companies can authenticate logins across multiple applications.

SAML usually has three main factors:

  • The user
  • The organization that authenticates the user—called an Identity Provider (IDP)
  • The service provider(s) with which the user wants to authenticate

In this scenario, the IDP—managed by the user’s employer—is the source of truth for whether a user is logged into an application; it determines whether or not a user is truly signed in, and if so, it gives the go ahead to other applications that are configured under the same SAML umbrella.

Image of Brightspot CMS customer logo

Brightspot plays the role of a service provider in most scenarios.

As it works in Brightspot, when a new application is enabled to work with SAML, the application gets configured to a domain and settings from Brightspot’s Dari architecture point to it. Typically, the IDP then sends Brightspot an XML file that has an embedded certificate that is used for authentication.

The certificate is unchanging and can be used more than once to validate user information, which is helpful since SAML enables authentication across multiple service providers, not just one.

Once Brightspot receives the XML file, its data (like email address) is mapped to Brightspot’s username data point. The XML file may also contain emails that are associated as part of a "group," which Brightspot maps to any roles that may have been set up by an organization (saving significant configuration time in the CMS).

This configuration process establishes the connections between the IDP and any relevant service providers.

So what does it all look like?

If not sent directly to the IDP to authenticate, users will see a login button on the service provider login pages that are part of the SAML implementation. At that point, it’s as simple as clicking a login button, and the IDP validates that the user is, in fact, signed in. If true, the user is logged into that site, preventing the hassle of having to remember their login credentials.

Multiple service providers can be fitted under the same SAML implementation, and once a user authenticates on the IDP (which can be initiated from Brightspot or any other site in that IDP), the gates are unlocked for the others. If the SAML implementation also includes a connection to JIRA or Confluence, for example, then the user need only click a login button on those pages as well.

As far as implementation, Brightspot comes out of the box with SAML application login code that can be used by customers to add SAML implementations to the many mission-critical applications they may use.

Other methods of single sign-on authentication

SAML isn’t the only method Brightspot has employed to achieve SSO operability for customers. In one case, Brightspot set up a login page containing iFrames that were used as the source of truth to determine whether a user was signed in.

In this use case, Brightspot can capitalize on this by embedding an authorization token into the iFrame and then using a second iFrame to validate the presence of the token once the login process is initiated.

Example use case of iFrame method

Brightspot performed exactly this kind of SSO work for a company who wanted to make it easier for subscribed users to navigate not only through their base website, but also to their subscription site. The idea—as with most SSO projects—was to authenticate once, and then give the user free reign over the content to which they are subscribed after authentication occurs.

In process, it works like this:

  1. An unauthenticated user lands on a login page that Brightspot sets up that contains an iFrame that confirms whether or not the user is logged in.
  2. If the user is not logged in, they click “Login” and a popup opens where the user enters their login credentials and proceeds to Site A with a one-time authentication token, stored in their browser as a cookie.
  3. The user navigates to Site B, which calls the iFrame from the login page to confirm the user is logged in, which it does by detecting the cookie that has the one-time authentication token. 

These are the simple steps in short, but Brightspot also created steps in the process for failed logins, failed redirects, and behavior upon logout.

illustration showing single sign-in authentication workflow for Brightspot

The best single sign-on authentication solution

SAML and iFrame are just two ways Brightspot can enable SSO for organizations and the applications teams rely on. With further operability across OAuth, JToken, and—thanks to a highly extensible architecture—any number of other SSO solutions, Brightspot is there to help organizations tackle their SSO efforts in a way that works best for them.

Visit our Docs site for more about security configuration on Brightspot

Share
About the Author
Mark is a Manager, Digital Content at Brightspot. When he's not gleaning insights from various developers from the company, he spends his time cooking new dishes at home with his wife and two hyperactive cats.

Related resources

To celebrate International Women’s Day, our recent webinar on "The Future of Women in Tech" explored some of the varied paths available to women looking to build a career in technology.
GraphQL is a query language that enables the connection of programming APIs that enable headless CMS integrations like those possible through the Brightspot CMS. For digital-media teams, GraphQL supports two of the most important factors in content development: speed and flexibility.
GraphQL, a query language for APIs used in many headless CMS implementations, has enjoyed much popularity in recent years as companies look for ways to remain competitive and appealing to their audiences in an ever-changing technological landscape. But what does GraphQL actually look like, and how is it used?