Single Sign-On with SAML authentication


At this stage, you need to provide a name for the configuration and fill in the required fields.

Pay close attention when selecting "Android Device policy" in the corresponding DPC field.

Additionally, you can learn how to obtain the JSON for the "DPC extras" field here 

SAML 2.0 is the last version of the Security Assertion Markup Language specified by the OASIS organization.
This standard was defined for exchanging authentication and authorization data between security domains.

SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, that is, an identity provider (IdP), and a SAML consumer, that is, a service provider (SP).

This is one of the most popular authentication systems that can be easily configured in most of the Identity Providers su as Azure Active Directory, Okta, OneLogin and many others.

Step by step tutorial to guide you through the integration of Azure AD authentication in Applivery

Step by step tutorial to guide you through the integration of Okta authentication system in Applivery

SAML authentication enables web-based authentication and authorization scenarios including cross-domain single sign-on (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to the user.
It allow a strengthened corporate security, and a simpler user provisioning.

The main benefits of using a SAML Identity Provider are multiple:

  • Your users will never input their credentials outside of your IdP web-based authentication system and we will never store their passwords.
  • Your user base is centralized and shared between all your internal and external services. You can now provision new users and restrict authorizations at a global level.

SAML authentication workflow #

  1. The user goes to your App Store domain or subdomain and clicks the LOGIN button.
  2. The user is redirected to you Identity Provider (IdP) login website
  3. The user uses the IdP web-based authentication system to log in and the IdP sends a SAML Response to the Applivery callback endpoint
  4. If the user is logged in and has the appropriate permissions in Applivery, he/she is allowed to access the App Store where will see only the authorized Apps.

Mapping SAML attributes #

You can map attributes in the identity provider (IdP) response to custom attributes used in the Applivery. For example, by default, a user email address is expected in the nameID element in the IdP response or, alternatively in If your IdP sends the user email address in an attribute instead of in the nameID element, you can map that attribute name to a custom attribute (for example, Email or so that the value of the attribute is used for the user email address.

You can also leave it black to retrieve the default value. Below you can find some examples for the different default values that we use to retrieve user data:

  • Email:
    • Standard: nameID
    • Azure AD: EmailAddress
    • Auth0:
  • First Name:
    • Standard:
    • Azure AD:
    • Auth0: Auth0:
  • Last Name:
    • Standard:
    • Azure AD:
    • Auth0:
  • User Name:
    • Standard:
    • Azure AD:
    • Auth0:
  • User Groups:
    • Standard:
    • Azure AD:

Mapping SAML groups to Applivery groups #

In some cases you will need to map SAML Groups from your IdP to the actual groups namings in Applivery. This is an optional step that is only needed for those IdP that do not send the real name of the group. Instead they normally send some kind of ID associated with the group in the IdP. You can do that from the Settings of each SAML configuration using key/value pairs.

Applivery will automatically discover new groups from each authentication and will add them to the list. However you can map them out upfront if you know the IDs.

Updated on June 19, 2024
Was this article helpful?

On this page

— talk to an expert —

Schedule a demo