Community Single Sign On

Introduction

Single sign-on, or SSO, is a technical authentication method for multiple related, but independent software systems or applications. It allows users to login with a single ID (such as email address or username) and password, to instantaneously gain personalized access to a series of integrated systems.

The main advantage for users is not needing to provide their credentials over and over for different applications within a combined platform, let alone needing different or separate credentials for each. Conversely, SSO-enabled systems will also provide single sign-off capabilities, whereby a single action of signing off terminates a user’s access to all integrated software applications.

World-wide adoption
SSO methods are adopted and implemented by companies worldwide, including brands such as Microsoft, Amazon and Facebook, serving over a billion people. A widely known example is that of Google, who has its customers gain immediate entry into all of its applications after logging in only once. Using their Gmail or Google Apps email address as authorization, people are able to use personalized versions of Google Calendar, Google Drive, Google Play, YouTube and many more. This shows that this practice has become widely adopted by millions of people, which has eased their online workflows on a daily basis.

Authentication Mechanisms
This page outlines the functional use cases and technical requirements related to the various SSO authentication mechanisms that inSided supports to set up on its communities

• OpenID Connect & OAuth2
• Token (JWT)
• SAML2
• Facebook

We will also address the most important advantages and considerations that are associated with SSO, after integrating systems to share such sign-on and sign-off capabilities.

Business case

Providing single sign on and single sign off functionality will enable users to easily move around an array of integrated Service Providers, such as a community, while enjoying full access and functionality granted to their (online) identities.

At the same time, SSO enables you as the governing organization hosting the SSO module, also called Identity Provider, to manage your users in a central location, saving time and costs of administration.

This central database enables organizations to have direct control over users’ characteristics, permissions and behavioral data, acquired across a series of applications. This is true for “My Acme”-type customer environments, usually provided by commercial organizations to facilitate self-service to consumers, but also for third parties such as social networks, acting as a hub for the users which it identifies.

The positive characteristics of an SSO-enabled series of integrated applications don’t stop at benefits involving efficiency. Often cited advantages cover areas of user experience, community integrations, information security, customer service, segmentation and data profiling as well. Let’s have a quick look.

User Experience

Registration

The amount of time saved spending re-entering passwords for the same identity is easy to imagine. But the implications this has for the user are more far-reaching. While having registered once at the Identity Provider, customers using SSO do not need to exchange information like their email address and customer number multiple times in order to get accounts for each Service Provider, including the community. If verifiable customer data such as customer or telephone number are involved while setting up a user profile, the Identity Provider has the advantage of verifying this immediately in the back office. And when logging in using social media, even the profile picture gets adopted automatically into a community avatar, saved with their account.

Activation
Regardless of the type of SSO authentication mechanism used, the inSided platform will trust the Identity Provider in having verified all email addresses already. This effectively means that those users do not need to receive and respond to additional confirmation emails, to activate their community accounts. This will encourage the usage and boosts activation of web applications such as the online community due to easier access, and help increase customer satisfaction.

Password fatique
Because of the one password needed for authorization, customers also experience less friction in terms of cognitive load, or mental effort. Especially in this day and age where we use many different services online, remembering these details often becomes hard and unreliable. If no SSO solution is provided, this can result in users having trouble logging in to many web applications, by guessing of various username and password combinations, also known as password fatigue. If these users do not succeed in doing so, they either need to retrieve a new password (time-consuming and frustrating experience), contact customer service (also adding up to organizational cost) or give up on the use of the Service Provider altogether (lowers engagement and increased risk of the customer churning).

Community integrations

The inSided community platform allows for deep functional integrations with any digital channel, using the inSided REST API. A popular use case is enabling users to interactively share comments to certain content on the main website, for example, a company blog. These comments will automatically be saved within the community, starting new topics based on the blog’s content, reflecting the conversation on both locations in real-time and actively luring additional people to this content. If SSO is in place to authenticate users’ identities, it will be possible to allow for a user-friendly flow in which the user can be already logged in to the website while posting to the community, without additional registration or even authorization. Without having SSO in place, this use case will become more complicated and practically limits certain user behavior and data connectivity.

Information security

As SSO Identity Provider must centrally translate and store credentials, while providing authorization and decoupling services for secondary integrated applications, risks involving information security (confidentiality, integrity and availability) are limited to one system only. This drastically eases the technical effort it will require to safely maintain such a system, while also increasing auditing and compliance opportunities. Furthermore, it enables the authorizing system to enforce any password characteristics business rules or identification measures it sees fit, independently from integrated service providers.

Reducing Personal Data Storage
Service Providers using SSO, such as an online community, require only processing and storing the bare user details explicitly necessary to perform certain tasks. This may only be a user’s email address, for sending activity notifications. And depending on community configuration, possibly some other meta information such as place of residency or service level. Most importantly, passwords don’t have to be transferred in any way, neutralizing the risk of high impact personal data loss in the event of a security breach on any of the secondary applications.

Customer Service

One of the business cases making the most use out of SSO is that of providing customer service. Without SSO, customer service agents would have to manually determine if a certain user, having a problem, is already a customer and if so, what is known about his or her case. This could be done using the email address as a unique identifier, provided by the user while having registered on the community, but this will often fail. Email addresses used for both services (commerce and community) can diverge from each other, or another family member could be the one having subscribed, for example. If SSO integration is setup, the unique identifier known for the community user will most often be the CRM customer ID (or “SSO ID”) used within the organization. This will enable company agents to easily and reliably identify community users and recall historical and commercial case details from each customer.

Data Profiling and Segmentation

SSO solutions are great in building a 360° customer view. A logged-in community user who automatically carries its personal meta information regarding CRM details, such as commercial subscriptions, can be exposed to a whole new set of experiences. For example, the community can be configured to have various user roles, or groups, related to possible subscriptions. By automatically placing the user in their appropriate group, dependent business rules can then allow for personalized access to subforums, ranks or badges. This will allow marketers to target certain content towards the user. It can also provide for a fully integrated experience overlapping several channels, for example by awarding the user with relevant gamification perks on the community, based on their purchases made earlier elsewhere within the company. This can be a great commercial differentiator and raise customer satisfaction.

Considerations of unfavorable impact

We have seen many SSO-enabled communities thrive, partly because of the cohesive and practical advantages listed in this document. There are, however, some logical limitations or implications to having SSO in place.

These considerations will be explained and weighed here.

Allowing prospect users

Your community success partly depends on who’s participating, and possibly, also from who’s not. Guest users (i.e. not signed-in or registered users) will always be capable of searching and viewing your public content, but in order to start posting, liking, messaging etc., they will need a community account. The inSided platform is very flexible in setting up permissions per user role, which act as groups you can apply. For instance, you can choose to make content publicly available to guest users of the community. Posting topics and replies, sharing messages and liking will then be restricted to registered users. This means that considering to implement, upfront, either a restrictive or welcoming policy on people who aren’t customers at your company yet, will be wise. If only one SSO method is configured on your community, and this integration refers to a self-managed Identity Provider such as a “MyCompany” environment, this is crucial.

Migrating to/from SSO

One of SSO’s advantages in terms of security and efficiency, which is not having to process or store user passwords at Service Provider such as the community, can cause difficulties if SSO is to be introduced or discontinued on a running community. This is because in both cases, the Identity Provider will be moved, requiring another system to adopt the user table, of which in almost any case user passwords will be encrypted differently of what’s supported in the inSided platform. Consequently, this will most often require a one-time solution, asking for all users to manually update their passwords by requesting a password reset link, which will be shared with them by email. The community platform does support this, so this challenge will be mostly affecting community communication and user commitment.

OpenID Connect & OAuth2

An OpenID Connect based authorization mechanism is a common way to safely integrate “My Acme”-type customer environments (Identity Provider) with inSided communities (Service Provider).

OpenID Connect is an authentication standard for single sign-on and identity provision on the internet. Its formula for success: simple JSON-based identity tokens (JWT), delivered via the OAuth 2 framework to suit web, browser-based and native / mobile apps.

This setup is using an extra level of indirect authorization to prevent the exchange of passwords during the sign on flow, by replacing user credentials with an authorization grant and an access and identity tokens. These elements will only be valid for a limited timeframe and for a specific authorization request, allowing for the community and the identity provider to reliably validate the authorization requests, the access token and the identity token.

The access token will be used to authorize requests and the identity token will contain who the user is. The community platform validates the access and identity tokens and processes the user’s sign on request only if it checks out. It may then proceed to synchronize various user profile data from the Identity Provider.

Flows

Sign on

1. The user, who is navigating the community, indicates wanting to sign on (i.e. register or login) by clicking a button or requesting to interact (e.g. wanting to create a topic)
2. The community, which acts as a Client, directs the user towards the Identity Provider. This step is called the Authorization Request. While doing so, it sends along a return_url which has the community sign-on endpoint, as well as the user’s initial location where it intended to go in step 1
3. The Identity Provider’s sign-on page either recognizes and validates the user (for those already logged in on the company website), and if that’s not the case, it asks the user to authorize themselves to the system
4. The Identity Provider uses the return_url from steps 1 and 2 and prepends it to a unique code, called Authorization Grant, and redirects the user back to the community, using this constructed community sign-on endpoint
5. The community will issue a server side request to the Identity Provider in order to get the access and identity tokens for the user. The code retrieved during step 4 will be used to identify the authorization flow
6. The Identity Provider will verify the code and respond to the server side request described in step 5 with the access and identity tokens
7. Depending on the implementation of the Identity Provider, the identity token might only contain the ID of the user. If more user data is needed by the community, the community will issue an additional server side request to the Identity Provider, called ‘user info’ request
   • If step 7 happens, the Identity Provider will return an additional identity token with extra data for the user
8. The community matches the unique user identifier (ID) or user’s email with its community user database and tries to locate the user account
   • If there is none yet, the user is presented with a short flow requesting to manually provide any additional user profile information, usually a username, depending on community configuration. It then creates a new community user account arranged from profile data provided by Resource/Authorization Server within the response, completed with the manually provided data by the user
   • The community synchronizes already known user profiles with any fresh profile data the Identity Provider provided for the user (e.g. email address, avatar, username, custom roles), enclosed within the response
9. The (now signed on) user is again automatically redirected, now by the community, using the user’s initial location within the return_url from steps 1, 2 and 4, presenting the community page that’s most relevant to the user’s requested flow (e.g. start creating a new topic).

Technical setup

For the OpenID Connect SSO setup to work, both platforms should adhere to the OpenID Connect specification described here: https://openid.net/specs/openid-connect-core-1_0.html

The format of the data that inSided platform expects to find in user info response is described in the User data format section at the end of the page.

Requirements for the setup
Provide configuration parameters in order to access the Identity Provider for every environment that needs to be set up (eg: acceptance/production):

1. Authentication URL
2. Issuer
3. Token URL
4. Client Secret
5. Client ID
6. Scope
7. User Info URL

return_url: https://sso.api.insided.com/auth/openidconnect/return

OAuth2

In case of a custom implementation that is not fully in line with the OpenID Connect specification, we support customization of certain request parameters of the SSO flow.

return_url: https://sso.api.insided.com/auth/oauth2/return

Token (JWT)

A JWT-based authentication mechanism is a common way to safely integrate “My Acme”-type customer environments (Identity Provider) with inSided communities (Service Provider).

Users, who are customers at the company the community belongs to, will have their credentials already available and automatically carry relevant metadata along with their profiles, such as their CRM customer ID.

This setup is using an extra level of indirect authentication to prevent the exchange of passwords during the sign-on flow, by replacing them with security tokens. Each token is signed by the client, for inSided to decipher, using verified cryptographic algorithms and shared secret keys which will be provided by inSided. Users’ security tokens will only be valid for a limited timeframe, allowing for the community to reliably validate the token sign-on request and hence the user’s identity.

The security token will contain who the user is, and the cryptographic proof of the Identity Provider authorizing the Service Provider to enable the user to access its personalized content and functionality within the community. The community platform validates each security token and processes the user’s sign-on request only if it checks out. It may then proceed to synchronize various user profile data from the Identity Provider.

Flows

Sign on

1. The user, who is navigating the community, indicates wanting to sign on (i.e. register or login) by clicking a button or requesting to interact (e.g. wanting to create a topic)
2. The community, which acts as Service Provider, directs the user towards the client’s sign-on endpoint, which acts as Identity Provider. While doing so, it sends along a return_url which has the community sign-on endpoint, as well as the user’s initial location where it intended to go in step 1
3. The Identity Provider’s sign-on page either recognizes and validates the user (for those already logged in on the company website), and if that’s not the case, it asks the user to authorize themselves to the system
4. The Identity Provider uses the return_url from steps 1 and 2 and prepends it to a uniquely encrypted code, also known as a security token, and redirects the user back to the community, using this constructed community sign on endpoint
5. The user automatically follows the URL to the community, providing it with the security token, which the community decodes, verifies its legitimacy and processes the authorization by logging the user in onto the community
6. The community matches the unique user identifier (ID) or user’s email with its community user database and tries to locate the user account.
   • If there is none yet, the user is presented with a short flow requesting to manually provide any additional user profile information, usually a username, depending on community configuration. It then creates a new community user account arranged from profile data provided by Identity Provider within the token, completed with the manually provided data by the user.
   • The community synchronizes already known user profiles with any fresh profile data the Identity Provider provided for the user (e.g. email address, avatar, username, custom roles), enclosed within the token
7. The (now signed on) user is again automatically redirected, now by the community, using the user’s initial location within the return_url  steps 1, 2 and 4, presenting the community page that’s most relevant to the user’s requested flow (e.g. start creating a new topic).

Automatic logout
By default, unless determined and configured otherwise, the user’s session will automatically be revoked on the community after 48 hours of inactivity.

Technical setup

For the token SSO setup to work, there need to be various endpoints in place on both ends. The to be constructed security token, exchanged from the client as Identity Provider, to the community as a Service Provider, has to meet certain criteria, in order for the process to work.

Identity Provider Endpoints
The client needs to deliver two endpoints to inSided, on which the token SSO Identity Provider sign on and sign off modules will be offered. Towards these URLs, inSided will direct all users who want to interact with the community, and those who want to terminate their sessions. Along with the endpoint URLs, inSided will embed an URL-encoded return_url parameter which is used to redirect the user back to the community after the user is authenticated.

Requirements for the setup

• Provide Identity Provider sign on endpoint, e.g., which could be triggered by the Service Provider by appending the return_url, e.g.
• Provide Identity Provider sign off endpoint, e.g., which could be triggered by the Service Provider by appending the return_url, e.g.

Sign on endpoint

At the client, the endpoint should follow these steps.

Step 1: Verifying user identity
As Identity Provider, the system both recognizes and validates the user, and if that’s not the case, it asks the user to authorize themselves to the system.

Step 2: Gathering token content
In order to provide all input needed for the authorization and functional processes, the security token needs to be built up by the Identity Provider, out of the variables described in User data format at the end of the page. This information with the exact field names must be contained in the payload of JWT token.

Step 3: Signing the token
JWT tokens are used to pass the user data between the identity provider and inSided platform. The token should be signed using a private key and the only thing that inSided platform requires is the public key which can be provided in the control environment for verifying the authenticity of the received token.

Step 4: Finalizing return endpoint
The return_url parameter, which the Identity Provider received along with the sign on endpoint request can now be used by appending ?token={token} and redirecting the user towards it, sending them back to the community.

Sign off endpoint

At the client, the endpoint should follow the following steps:

Step 1: Terminating user session
As Identity Provider, the system terminates the user session by retracting all permissions and removing related cookies and such.

Step 2: Returning the user
The return_url parameter, which the Identity Provider received along with the sign off endpoint request, can now be used to direct the user towards it, sending them back to the community.

return_url: https://sso.api.insided.com/auth/token/return

SAML2

A SAML2-based authentication mechanism is, next to token, another common way to safely integrate “My Acme”-type customer environments (Identity Provider, or SAML authority) with inSided communities (Service Provider, or SAML consumer).

Users, who are customers at the company the community belongs to, will have their credentials already available and automatically carry relevant metadata along with their profiles, such as their CRM customer ID.

Security Assertion Markup Language 2.0 (SAML2) is a version of the SAML standard for exchanging authentication and authorization data between domains. The XML-based protocol uses security tokens containing assertions to pass information about a principal (the user) along to the community. 

The secured transfer XML form will convey who the user is, and the cryptographic proof of the Identity Provider authorizing the Service Provider to enable the user to access its personalized content and functionality within the community. The community platform validates the connection and processes the user’s sign-on request only if it checks out. It may then proceed to synchronize various user profile data from the Identity Provider.

Flows

Sign on

1. The user, who is navigating the community, indicates wanting to sign on (i.e. register or login) by clicking a button or requesting to interact (e.g. wanting to create a topic)
2. The community, which acts as Service Provider, provides the user with a document containing a SAML2 request XHTML form, including a return_url which has the community’s so-called assertion consumer service endpoint, as well as the user’s initial location where it intended to go in step 1
3. The user’s browser will automatically POST this form towards the client’s sign-on endpoint, which acts as the Identity Provider
4. The Identity Provider’s sign-on page either recognizes and validates the user (for those already logged in on the company website), and if that’s not the case, it asks the user to authorize themselves to the system
5. The Identity Provider provides the user with another document containing an XHTML form, including the user’s profile data
6. The user’s browser will automatically POST the form to the community’s assertion consumer service endpoint
7. The community verifies the response and processes the authorization by logging the user in onto the community
8. The community matches the unique user identifier (ID) or user’s email with its community user database and tries to locate the user account.
9. The (now signed on) user is again automatically redirected, now by the community, using the user’s initial location within the return_url from steps 1 and 2, presenting the community page that’s most relevant to the user’s requested flow (e.g. start creating a new topic).

Automatic logout

By default, unless determined and configured otherwise, the user’s session will automatically be revoked on the community after 48 hours of inactivity.

Technical setup

For the SAML2 SSO setup to work, both platforms should adhere to the open SAML2.0 standard. The format of the data that inSided platform expects to find in user attributes is described in the User data format section at the end of the page.

return_url: https://sso.api.insided.com/auth/saml/return

Requirements for the setup

• Provide export of SAML metadata, including certificate
• Provide Identity Provider login endpoint
• Provide Identity Provider sign off endpoint (optional)

Facebook

Offering the authentication mechanism through social media Identity Providers like Facebook is a widely used way for users to sign onto thousands of online applications such as the inSided community.

As of early 2016, 1,65 billion registered users were known to have been monthly active on the Facebook platform. This means chances are virtually all of your customers will be able to make use of this method, which enables them to quickly set up their community profiles. This drastically lowers the bar by avoiding friction in user experience, generated through boring user registration forms.

Besides the world-wide adoption of the Facebook platform, providing social media login brings another advantage to the table, in terms of SSO. Usually in contrast to clients acting as their own Identity Provider, by integrating SSO through token or SAML2 and Facebook provide the profile picture along with the email address and user authorization confirmation, for each sign-on. This means that the community profile avatar will be automatically set, enriching many more user profiles with images that will personalize the community.

Flows

Sign on

1. The user, who is navigating the community, indicates wanting to sign on (i.e. register or login) by clicking a button or requesting to interact (e.g. wanting to create a topic)
2. The community, which acts as Service Provider, directs the user towards the Facebook platform, which acts as an Identity Provider. While doing so, it sends along the user’s initial location where it intended to go in step 1
3. The Identity Provider either recognizes and validates the user, and if that’s not the case, it asks the user to login with their Facebook account
4. The Identity Provider then specifically requests the user to authorize them providing the community with the user’s public profile and email address. Once this permission has been given by the user, this step will be skipped during subsequent sign on flows from this user to the community
5. The Identity Provider redirects the user back to the community
6. The user automatically follows the URL to the community, providing it with a secure hash, which the community decodes, verifies its legitimacy and processes the authorization by logging the user in onto the community
7. The community matches the unique user identifier (ID) or user’s email with its community user database and tries to locate the user account. If there is none yet, the user is presented with a short flow requesting to manually provide any additional user profile information, usually a username, depending on community configuration. It then creates a new community user account arranged from the email address and profile picture provided by the Identity Provider, completed with the manually provided data by the user
8. The (now signed on) user is again automatically redirected, now by the community, using the user’s initial location from steps 1 and 2, presenting the community page that’s most relevant to the user’s requested flow (e.g. start creating a new topic).

Technical setup

The Social SSO integration works by creating and managing a developer app in Facebook platform, which will be given a title after the community name and a brand logo.

Appendix: User Data Format

This table describes the format of user data that inSided platform expects from every SSO protocol. The only required field is ID field, all other fields are optional.