Single sign-on (SSO) enables users to access a number of web-based applications using only one set of login credentials. The benefits of SSO are that users do not have to remember multiple passwords and the organization has centralized control of authentication and access privileges.
SAML (Security Assertion Markup Language) is an XML-based standard, used by many enterprise products, for managing SSO. SAML enables applications to communicate with each other, exchanging information to ensure a user is authorized to access an application.
BRYTER integrates with any identity provider that supports SAML.
This article assumes that you are familiar with setting up an SSO Integrations. If you have no knowledge of this process, please contact your technical administrator for assistance.
SAML communication components
There are three actors in the communication process when logging in via SSO:
- the client — the user requesting access
- the service provider (SP) — the web-based application the client wants to access (for example, BRYTER)
- the identity provider (IdP) — the system that authenticates and authorizes the client (for example, MS Active Directory or Okta)
Clients log in via their organization’s IdP. Having authenticated the client, the IdP allows access to the SP. Typically, the client will gain access to a number of SPs that they have been authorized to use. Each SP must have SSO configured to use the IdP for authentication.
SAML single sign-on process
Assuming the client has not already authenticated, the single sign-on process is as follows:
- In a browser session, the client requests access to a web-based application (SP)
- The request is directed to the IdP
- The IdP prompts the user to enter log in credentials, authenticates the user, and generates a SAML token (an XML file) that is sent to the SP
- The SAML token allows the client to now access the SP
If the client has authenticated previously, and their user session has not timed out, the IdP will grant access to the SP immediately. The client will not be prompted to log in again.
SAML single sign-on setup
Communication between the client, SP, and IdP is based on the exchange of information located in XML metadata files.
To facilitate this communication:
- the IdP must set up a record for the SP using data provided in the SP’s XML metadata file (usually downloaded from the SP’s website)
- the SP must set up a record for the IdP using data provided in the IdP’s XML metadata file (usually downloaded from the IdP’s website)
- where role mapping is supported by the IdP, exactly equivalent roles must be configured in the SP and the IdP. Failure to do this will result in the client being unable to access the SP.
Implications of BRYTER single sign-on integration
We recommend that you consider each of the issues outlined below before implementing single sign-on for BRYTER.
- Each SSO Admin and Author account represents an account in your BRYTER quota
- Managing user credentials and roles must be administered in your identity provider not in BRYTER
- BRYTER SSO integration involves a 1:1 mapping of roles between the user account in your identity provider and the user account in BRYTER. Any user account without this mapping will not be able to log in to BRYTER
- Each authentication request requires the exchange of first name, last name, email address, and the roles associated with the user account. This information is captured *each* time the user authenticates — any user, whose account is disabled, will immediately be unable to log in
- Because each identity provider has a slightly different configuration, you need to pay particular attention to the factors in your organization’s configuration that may be affecting the success of your implementation. Is there anything in your unique environment that may need consideration before and during SAML integration with BRYTER?
We have a Troubleshooting page that outlines the most common issues our customers encounter and how to resolve them. If you can’t find answers to your questions there, contact your BRYTER contact person who will be happy to help you succeed with your implementation.
Definitions
| Assertion | A message, from the IdP, via SAML, containing authentication, attribute, and authorization values to inform an SP that a user is signed in and authenticated. |
| Authentication | The process of verifying the identity of a user (or process). Ensuring that the user (or process) is who they claim to be. |
| Authorization | Assigning roles to users to enable them to access different levels of information and perform specific functions based on those roles. |
| Claim | Information that an IdP states about a user, typically contained in the SAML Attribute Statement. |
| Identity provider (IdP) | A cloud software service that stores and confirms user identities, usually via a login process. |
| Mapping | BRYTER roles are mapped to assertions to enable users to access appropriate parts of the application or service. |
| Role | BRYTER supports three roles: Admin, Author, and User. |
| SAML | SAML (Security Assertion Markup Language) is a technology enabling users to assert that they are who they say they are. |
| Service provider (SP) | A cloud-hosted application or service that a user wants to access. |
| Tenant | A customer-specific BRYTER environment, separated from other customers’ tenants. A tenant is accessed via, for example, https://acmecorp.bryter.io or https://bigcorp.bryter.io, where acmecorp or bigcorp are the tenant names. |