Overview of SAML
Security Assertion Markup Language (SAML) is an authentication standard for logging users into applications based on their user sessions in other applications. This single sign-on (SSO) login standard has significant advantages over logging in using a username/password:
-
No need to type in credentials
-
No need to remember and renew passwords
-
No weak passwords
Most organizations already know the identity of users because they are logged in to their Active Directory domain or intranet. It makes sense to use this information to log users in to other applications, such as web-based applications, and one of the more elegant ways of doing this is by using SAML.
SAML is very powerful and flexible, but the specification can be quite daunting due to the complex nature of systems integrations.
How SAML Works
SAML SSO works by transferring the user’s identity from one place (the identity provider) to another (the service provider). This is done through an exchange of digitally signed Extensible Markup Language (XML) documents. XML is an industry standard for allowing data to be transmitted from one server to another remote server.
There are two elements to a standard SAML SSO configuration, the Identity Provider (IdP) and the Service Provider (SP).
Identity Provider: The Identity Provider or IdP is the source of the identity of the user. This is the where the user login information will be referenced from when initializing a SSO request to login to another application.
Service Provider: The Service Provider or SP is the remote application that a user is attempting to login to with SAML SSO.
Consider the following scenario: A user is logged into a system that acts as an identity provider (Okta, Azure AD, Gmail). The user wants to log in to a remote application, such as Allbound (the service provider). The following happens:
-
The user accesses the remote application using a link on an intranet, a bookmark, or similar and the application loads.
-
The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the identity provider, asking for authentication. This is the authentication request.
-
The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider.
-
The identity provider builds the authentication response in the form of an XML-document containing the user’s username or email address, signs it using an X.509 certificate. This XML-document is known as the "assertion," which gets sent to the service provider.
-
The service provider, which already knows the identity provider and has a certificate fingerprint configured in SSO settings, retrieves the assertion and validates it using the certificate fingerprint.
-
The identity of the user is established and the user is provided with app access.
Consider an alternative scenario in the case of use cases for Allbound: A user is logged into Allbound. The user wants to log in to a remote application, such as Docebo, TalentLMS or Vartopia(the service provider). The following happens:
-
The user accesses the remote application using a link generated by Allbound based on the configuration ID found upon creating the SSO configuration and the application loads.
-
The application identifies the user’s origin and redirects the user back to Allbound, asking for authentication. This is the authentication request.
-
The user either has an existing active browser session with Allbound or establishes one by logging in.
-
Allbound builds the authentication response in the form of an XML-document containing the user’s username or email address, and any other additional information included in the attribute statement, signs it using an X.509 certificate. This is known as the "assertion," which gets sent to the service provider.
-
The service provider, which already knows Allbound and has a certificate fingerprint configured in SSO settings, retrieves the assertion and validates it using the certificate fingerprint.
-
The identity of the user is established and the user is provided with app access.
SAML SSO Flow
Dissecting the Metadata File
If you don't know how to read XML, looking at a metadata file is literally trying to read a foreign language. But, learning to understand what you're looking at is more straightforward once you understand HOW to read the file and what things to look for when implementing your first SAML SSO configuration. Lets go through an example of a metadata file that you may come across when implementing a SAML SSO.
<?xml version="1.0"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="https://partner-portal.allbound.com" ID="_d695f96f03eed87fc3ceb17a39144ec3852d0689ca">
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="false">
<KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIIEGTCCAwGgAwIBAgIUGUciK6xPP0x6P+IT5gbern+4iqYwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdBcml6b25hMRAwDgYDVQQHDAdQaG9lbml4MRMwEQYDVQQKDApDb250ZW50ZnVsMRMwEQYDVQQLDApjb250ZW50ZnVsMRgwFgYDVQQDDA9TdGVwaGVuIFJhenphbm8xJDAiBgkqhkiG9w0BCQEWFXNyYXp6YW5vQGFsbGJvdW5kLmNvbTAeFw0yMjA1MTAwMDM1NTdaFw0yMzA1MTAwMDM1NTdaMIGbMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHQXJpem9uYTEQMA4GA1UEBwwHUGhvZW5peDETMBEGA1UECgwKQ29udGVudGZ1bDETMBEGA1UECwwKY29udGVudGZ1bDEYMBYGA1UEAwwPU3RlcGhlbiBSYXp6YW5vMSQwIgYJKoZIhvcNAQkBFhVzcmF6emFub0BhbGxib3VuZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7UO2YAo+KKWO+g+qX+gFZLGRgyOl2m4ADiwb1inhdEoXZlTwee5DklrFIOcn7mLpghfF0AkbCCpDG0pC1jrjDd6jyls2JpzqVpibxRcnADdpolrwDHRYss/3oOGmahr92CTpXzDn+1NvX3ndoKZspnV0wdQbcY9IByeWTNZGOIi1+q7f9ucl6K5SoyV0h3IJvRpPJv9bvxnVsXyznRpofB/llpnk8zGIXf5UnULlXHYgBJan6TMxUVB4tzvF8NjksZ3PBpN0q3tVwWD72MFiyluypQQfub2w/vbqTvQqCLPg/z7td5q4HQhnjz/0NrtrWnoqeozcCZfjaKz51czF1AgMBAAGjUzBRMB0GA1UdDgQWBBSckpgGyZuptuNKJfiU9beCLxVLejAfBgNVHSMEGDAWgBSckpgGyZuptuNKJfiU9beCLxVLejAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQAgbpSsFfHQIuwFhp5lpvZ7LxcXSigSFYjCHoN95k48l0mcqPb8kQqf5cJDXUHAqUgDiHkBUuzjrfK6dJMxFCUXi5Sy4S0jtjt2wcyX1tpZo7qA0649HiKdtOuzg96DGlZzBudwKywf4RXTtfJnuEkJjec6QFHy403hoY3GO0ci9XLN0qRVaKcDXZ7VNLputAlhyya/SvwCA5RFCTBIeJdPxif/Ugky8MumK9PBG7LiCHAWkB+ozjCtz52kA0QOYrFG09ew1S5chG8+je/W+q2U0QDVnKBzyHB0xZSGVHHZscrxF0FhrObb1Pvqr9eSSeZk85/ZWrhXY9hz3fg/E5G7</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</KeyDescriptor>
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://partner-portal.allbound.com/" />
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://partner-portal.allbound.com/" />
</IDPSSODescriptor>
</EntityDescriptor>
We will be focusing on the areas of the above that are bolded and underlined.
entityID: The entityID is a requirement for every SSO implementation. It is a globally unique name for a SAML entity, i.e., your Identity Provider (IdP) or Service Provider (SP). It is how other services identify specific Allbound instances.
SingleLogoutService: This is the "Logout URL." The value is whatever is listed as the "Location" for this property. In the above example, Location="https://partner-portal.allbound.com/" the value for the Logout URL would be "https://partner-portal.allbound.com/"
NameIdFormat: Defines the name identifier formats supported by the identity provider. Name identifiers are a way for providers to communicate with each other regarding a user. Some systems require this to be a specific value to be able to work. In the above example:
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
the format required in this example would be "emailAddress," a common ID format accepted across most systems.
SingleSignOnService: This is the "Login URL." The value is whatever is listed as the "Location" for this property. In the above example, Location="https://partner-portal.allbound.com/" the value for the Login URL would be "https://partner-portal.allbound.com/"