Check the availability in our pricing page.
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, Ping Identity and many others.
Step by step tutorial to guide you through the integration of Ping authentication system in Applivery
- 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 #
- The user goes to your App Store domain or subdomain and clicks the LOGIN button.
- The user is redirected to you Identity Provider (IdP) login website
- The user uses the IdP web-based authentication system to log in and the IdP sends a SAML Response to the Applivery callback endpoint
- 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 #
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress. 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 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email) 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:
http://schemas.auth0.com/email
- Standard:
- First Name:
- Standard:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname - Azure AD:
http://schemas.microsoft.com/identity/claims/displayname - Auth0: Auth0:
http://schemas.auth0.com/given_name
- Standard:
- Last Name:
- Standard:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname - Azure AD:
http://schemas.microsoft.com/identity/claims/displayname - Auth0:
http://schemas.auth0.com/family_name
- Standard:
- User Name:
- Standard:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname - Azure AD:
http://schemas.microsoft.com/identity/claims/displayname - Auth0:
http://schemas.auth0.com/nickname
- Standard:
- User Groups:
- Standard:
http://schemas.xmlsoap.org/claims/Group - Azure AD:
http://schemas.microsoft.com/ws/2008/06/identity/claims/groups
- Standard:
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.
