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, and a SAML consumer, that is, a service provider.
SAML 2.0 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.
SAML authentication workflow
A user authentication goes as follow:
The user use its specific SAML link or subdomain link to access the Appaloosa platform
The Appaloosa platform redirect the user's browser to its specific IdP
The user uses the IdP web-based authentication system to log in and the IdP sends a SAML Response to the Appaloosa callback endpoint
If the user is logged in, he is allowed to use the platform
The benefits of using a SAML Identity Provider are multiple:
Your user never input its credentials outside of your IdP web-based authentication system
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 2.0 Metadata
To connect Appaloosa as a Service Provider to your Identity Provider (your authentication server implementing the SAML V2 specification, called IdP in the rest of this document), you have to provide us your SAML metadata.
Those metadata (amongst a lot of other usages) allow a service provider and an IdP to connect to each other.
In order to connect your Identity Provider to the Appaloosa platform, you have to provide us its configuration.
This can be done in several ways:
Provide us an URL to your IdP's metadata (preferred method for smooth updates)
Provide us the content of your IdP's metadata
Provide us the relevant configuration tokens (To use only if methods 1 and 2 are not available)
Default name identifier format
Appaloosa uses the email as user identification. The SAML endpoint thus has to support the following name identifier : urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
You also have to make sure that your SAML identity provider send us the following attribute on a positive authentication (casing and underscore are importants):
first_name: First name of the connected user
last_name: Last name of the connected user
Those attributes will be set in the administration console of your identity provider, and depend on the implementation you are using.
Metadata URL and Metadata content
The metadata from an IdP contains:
The Entity ID that allow to identify uniquely your SAML IdP.
A redirect URL to which your users are sent, allowing them to use your SAML IdP web-based authentication page.
An optional authentication certificate.
The preferred configuration method is through an URL referencing the Metadata file of your IdP. This allow an easy refresh of the Service provider configuration if you happen to update your IdP configuration.
Alternatively, you can provide us the content of the Metadata XML file.
Appaloosa supports certificate signed requests from the Identity Provider side (SAML endpoint) and the Service Provider side (Appaloosa). However, we strongly encourage not to enforce Service Provider request signing. Such configuration requires then both certificate to be updated at the same time when they expire which may result in a downtime of the service.
Alternate manual configuration
If your IdP does not provide metadata access (which is very unlikely), we can also build a specific configuration from yours.
What we'll need is:
Entity ID: The entity id of your IdP. This is an URL.
SSO Target URL: Single Sign-On endpoint of your IdP (URL)
SLO Target URL (optional): Single Logout endpoint of your IdP (URL)
Certificate (optional): X.509 certificate of your IdP (default: none)
Certificate fingerprint (optional): fingerprint of the certificate of your IdP (default: none)
Certificate fingerprint algorithm (optional): Algorithm used to generate the fingerprint of your IdP's certificate (default: SHA1)