Identity Providers overview

Paid feature

The Identity Providers feature requires a paid subscription. To activate this feature, please contact Aembit by submitting the Contact Us form.

The Identity Providers feature allows you to offer alternate authentication methods when users sign in to your Aembit tenant. The default authentication method is to use an email and password with the option to enable and require MFA.

Requiring your users to remember and manually enter a username and password every time they sign in to your Aembit tenant is tedious, error-prone, and insecure long-term. To improve the user experience and provide more secure authentication methods, set up SAML Single Sign-On (SSO) through integrating an external SAML-capable Identity Provider (IdP) such as Okta.

To enforce the exclusive use of SSO and prevent your users from authenticating with their username and password, enable Require Single Sign On.

Tip

The Identity Providers feature is only available on the following subscription plans:

• Teams plan

• Enterprise plan

To enable Identity Providers, please contact Aembit by completing the Contact Us form.

SAML overview

SAML 2.0 (Security Assertion Markup Language) is an open standard created to provide cross-domain Single Sign-On (SSO) authentication. SSO allows a user to authenticate in one system (the Identity Provider) and gain access to a different system (the Service Provider) by providing proof of their authentication from the IdP.

SAML Identity Provider

The SAML Identity Provider (IdP) enables SSO user authentication where Aembit acts as the Service Provider. Common SAML Identity Providers include Okta, Google, Microsoft Entra ID, and many others.

Service Provider

The Service Provider takes this information and implicitly trusts the information given and provides access to the service or resource. The Aembit Service Provider is an example of a resource that accepts external Identity Provider data.

Aembit SSO authentication process

The following occurs during the SSO authentication process on your Aembit tenant:

1. A user selects the option to authenticate through an IdP on the Aembit tenant login page.

2. Aembit redirects the user to the IdP’s log in page.

3. The IdP prompts the user to authenticate.

4. If the IdP authentication is successful, the IdP redirects the user back to your Aembit tenant.

5. Aembit logs the user in through the successful SSO authentication.

About automatic user creation

When you enable the automatic user creation feature, Aembit automatically generates new user accounts on your behalf when your users go through the SSO authenticate process. This automation not only saves time and resources by reducing or eliminating the manual effort needed to manage user accounts but also minimizes errors associated with manual account management. Also, this feature provides granular control of what user roles Aembit assigns to new users it creates.

The automatic user creation feature works by extracting certain SAML attributes in the SAML response from the IdP after successful authentication with that IdP. It’s important to know, however, that not all IdPs configure their SAML attributes the same way. Different IdPs use distinct attribute names to pass user group claim information.

To alleviate these inconsistencies, Aembit allows you to map your IdP’s SAML attributes to the user roles available in your Aembit tenant. See Configure automatic user creation for details.

How automatic user creation works

During the SSO authentication process, when Aembit verifies the incoming SAML response message, if no user account exists for that user, Aembit initiates the automatic user creation process.

Aembit requires an email address to uniquely identify users of your Aembit tenant. If it can, Aembit populates the first and last name of the users it automatically creates. If not, Aembit just uses the user’s email address.

Aembit looks for the presence of the following group claim elements in the SAML response to try to create the new user account:

• A NameID element containing the user’s email address. If Aembit finds the NameID element isn’t present or the value isn’t a valid email address, Aembit searches for the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress claim instead. If Aembit finds neither, the automatic user creation process stops. If this happens, you must Configure automatic user creation

• Both http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname and http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname to populate a user’s first and last names, respectively. Otherwise, Aembit populates a user’s first and last names with their email address.

• A AttributeStatement element with at least one Attribute child element with an attribute value matching the configuration data entered on the Mapping tab of the Identity Provider page. This match is necessary to determine which roles Aembit assigns to the new user account. If Aembit doesn’t find a matching attribute value, Aembit won’t create the new user account.

Additional resources

The following pages provide more information about working with Identity Providers:

• Automatic User Creation - Configure automatic user creation with Identity Providers
• Creating Identity Providers - Set up new Identity Providers in your Aembit tenant