We have gathered answers to some of the most common issues our customers encounter when implementing single sign-on (SSO) for BRYTER. If you cannot find answers here, contact your BRYTER contact person who will be happy to help you succeed.
Supported technologies
- When using SSO, login accounts are managed through your IdP. You must configure your two-factor authentication (2FA) with your chosen IdP.
- SCIM (System for Cross-domain Identity Management) is currently not supported out of the box. If you require SCIM, please reach out to your BRYTER contact person.
Identity Providers
- You can enable and test multiple identity providers (IdP) but only one can be used as the default.
- You can update certificates in the IdP configuration in your Admin console. BRYTER supports multiple certificates. Be aware that providing the wrong certificate may result in users being unable to log in.
- When switching to a new IdP or amending an existing configuration, you cannot change the login URL in the IdP configuration — the SSO link between the user on BRYTER and your IdP would break. You must create a new configuration to forge a new SSO link between BRYTER and the new IdP.
Identity Provider Claims Configuration – See specific page
Connectivity
- Check for DNS or firewall changes.
- Ensure the login URL is publicly available.
User administration
- Once SSO is configured, all user administration must be completed in the IdP interface not in BRYTER. Changing the role of users also happens in the IdP if this option has been activated.
- Claims attributes are pushed to the BRYTER Admin Console when the user next logs in via your IdP. Those changes will be reflected in the User list — a lock icon displays in the SSO user column.
- To remove a user account, revoke the claims for the user in your IdP. The account will still be visible in BRYTER until it is removed manually.
- When an existing user, author, or admin logs in for the first time after SSO is activated, they must click the Add to existing account button displayed on the Welcome! screen and confirm their account through an activation link via email.
Error messages
Message | Resolution |
AADSTS900561: This endpoint only accepts POST requests. Received a GET request |
Because you cannot choose the binding type in BRYTER, this message is reporting a mis-configuration in the IdP. The Login URL has been configured to use a GET request when it should be a POST request. |
‘InvalidfederatedIdentityActionMessage’ |
Check that the Certificate is correctly set |
Definitions
Term or abbreviation |
Definition |
SSO |
SSO (Single Sign On) is a technology that enables users to authenticate to a system once and be authorized to use multiple applications and services. |
SAML |
SAML (Security Assertion Markup Language) is a technology enabling users to assert that they are who they say they are. |
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. |
Identity provider (IdP) |
A cloud software service that stores and confirms user identities, usually via a login process |
Service provider (SP) |
A cloud-hosted application or service that a user wants to access. |
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. |
Role |
Bryter supports three roles: Admin, Author, and User. |
Mapping |
Bryter roles are mapped to assertions to enable users to access appropriate parts of the application or service. |
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. |
Claim |
Information that an IdP states about a user, typically contained in the SAML Attribute Statement. |