Security Assertion Markup Language (SAML) is an open-source framework for exchanging authentication and authorization data between an identity provider and a service provider where:
- An identity provider (IdP) authenticates a consumer and provides a SAML Assertion to service providers.
- A service provider (SP) verifies the Assertion and provides access to the consumer.
Note: To know about SAML, its component, and benefits, refer to the sections below.
LoginRadius supports both SAML 1.1 and SAML 2.0 flows. LoginRadius Dashboard lets you do SAML configurations by allowing you to customize the assertions, keys, and endpoints to match any SAML provider requirements.
The following are some key points providing better clarity about LoginRadius acting as an Identity provider:
- LoginRadius acts as an identity provider (IDP), which means that LoginRadius can authorize your app, and your app will act as a service provider (SP).
- LoginRadius supports both Identity Provider Initiated Login and Service Provider Initiated login flows.
- LoginRadius supports Single Logout (SLO).
- LoginRadius does not support HTTP Artifact.
For the IDP initiated login, a consumer is logged on to the LoginRadius site and attempts to access a protected SP resource. LoginRadius redirects the consumer to LoginRadius SAML IDP initiated URL. The SAML IDP initiated URL automatically posts a SAML response to the SP. Then SP verifies the response. The login URL for this process is:
The following sequence diagram summarizes the steps while proceeding with IDP Initiated Login:
In the Service Provider initiated login, a consumer attempts to access a protected resource directly on an SP Website without logging on. The SP sends an authentication SAML request as a string query parameter in the HTTP GET or HTTP POST parameter (after it has been deflated, base64 encoded, and URL encoded) depending on the binding configuration to the SP initiated LoginRadius URL.
The following sequence diagram summarizes the steps while proceeding with SP Initiated Login:
A SAML request will look like this :
<samlp:AuthnRequest ID="_3f603af1-c3be-4463-b25f-7e2b0701d690" Version="2.0" IssueInstant="2019-08-30T17:03:52.179Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline </Issuer> <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/> </samlp:AuthnRequest>
The IDP validates the contents of the Request and prompts the consumer to provide login credentials. If the consumer is authenticated successfully, the IDP sends a SAML response via HTTP POST* to Service Provider Assertion Consumer Service URL.
A SAML response will look like this:
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_4650c174-7063-426a-b259-ad7ffdd9f633" Version="2.0" IssueInstant="2020-01-06T05:22:20.769Z" Destination="https://login.microsoftonline.com/login.srf" InResponseTo="_3f603af1-c3be-4463-b25f-7e2b0701d690"> <saml:Issuer>https://<Your LR SITE>.hub.loginradius.com/</saml:Issuer> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:Status> <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_edf670ea-a82f-4872-ba00-71a00acc5c39" Version="2.0" IssueInstant="2020-01-06T05:22:20.769Z"> <saml:Issuer>https://<Your LR SITE>.hub.loginradius.com/</saml:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <ds:Reference URI="#_edf670ea-a82f-4872-ba00-71a00acc5c39"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>MALQA9d3QWPBzpba4cZq8CbdITwOIU+ CzIPGesJz6Jk= </ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>D5py5Z6wOR+QtrjqsdJyXMYqV9yJD7uMXrr74pKaRHRbO7KSIuBnYQLwsJ2SlKh1p... </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIIDLDCCAhSgAwIBAgIJALwtdp+dP0F0MA0GCSqGSIb3DQEBCwUA...</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">aa51c695b7b24ae3836a9222db3892ca </saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData NotOnOrAfter="2020-01-06T06:12:20.769Z" Recipient="https://login.microsoftonline.com/login.srf" InResponseTo="_3f603af1-c3be-4463-b25f-7e2b0701d690"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2020-01-06T05:22:20.769Z" NotOnOrAfter="2020-01-06T06:12:20.769Z"> <saml:AudienceRestriction> <saml:Audience>urn:federation:MicrosoftOnline</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2020-01-06T05:22:20.769Z" SessionIndex="4717eb31-52bc-40d3-8f48-dfc623a1dd4c"> <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute Name="user.userprincipalname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">firstname.lastname@example.org </saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="user.givenname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">jay </saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="user.surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">agarwal </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> </samlp:Response>
The following explains some critical fields of the SAML response:
- InResponseTo contains the value earlier sent as an ID in the SAML Request. The Service Provider matches this with the SAML request ID.
- IssueInstant NotBefore and NotOnOrAfter define a time interval for which the SAML Response is valid.
- The issuer in assertion contains the URI of SAML response issuer. The Service Provider uses this value to verify that the assertion is coming from the expected Identity Provider.
- AudienceRestriction in the assertion defines that this assertion is targeted for a specific Service Provider and cannot be used for any other Service Provider.
- The subject in the assertion identifies the authenticated principal(user).
- The AttributeStatement in the assertion contains attributes and their values for the specific user that comes as authenticate.
The Assertion or the whole SAML Response is signed with an XML Signature that protects the integrity of the Assertion (or response) and verifies that it has not been modified in transit. Upon receiving the SAML Response, the SP can verify its contents and structure, validate the signature, and subsequently treat the user as authenticated by initiating a web session.
You can request to be logged out of LoginRadius, which will cause your consumer to be logged out from all SSO sites. To enable the Single Logout feature, the service provider must support the SAML Single Logout protocol. The various logon sessions are not terminated if the SP does not support this protocol. Additionally, the user will not receive the appropriate notification of this failure. The logout URL for this request is
This document goes over how you can enable Single-sign-on in Loginradius Dashboard using the SAML supported app. Your SAML app will act as an IDP and LoginRadius as SP.
Each authentication system is unique and might require different configuration settings. Please use the following values for configuring LoginRadius as a service provider in your application to enable SAML flow.
- Login in to your SAML supported app.
- Enable and configure Single-sign-on method SAML.
Configure LoginRadius as a Service Provider in your application with the following values:
- Enter https://lr.hub.loginradius.com in Start URL.
- Enter https://lr.hub.loginradius.com/ in Entity Id.
- Enter https://lr.hub.loginradius.com/saml/serviceprovider/AdfsACS.aspx in ACS URL.
- Select Name Id format: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified.
Download the metadata for SAML configuration.
- Log in to your LoginRadius Dashboard.
- Select your app, then from the left Navigation panel, click the Integration section and click Add in Configured Integration section
- Search SAML in the searchbar.
- Click Add Me button in SAML Widget that has appeared.
Add SAML app by clicking Add App or Add From Metadata File
If the Add From Metadata File option is selected, then add the metadata file of the SAML file to connect with SSO.
The below steps are if the Add App option is selected.
Select SAML version, Loginflow(SP or IDP), and add the SAML App name.
Enter LoginRadius’ Certificate and Key in ID PROVIDER CERTIFICATE and SERVICE PROVIDER CERTIFICATE KEY.
ID Provider Certificate: Certificate of SAML supported app working as identity Provider in this case.
Generate LoginRadius’ Certificate and Key Self-signed certificate and key can be generated by one of the following ways:
- Using online tools, for example, with Bits and Digest Algorithm 2056, SHA256, respectively.
- Using the following OpenSSL commands (currently, LoginRadius is only supporting the PKCS1 private key format):
Generate the ID Provider Certificate key from the following command:
openssl genrsa -out private.key 2048
View the private key from the last step:
vi private.key (for Linux OS)
Generate certificate form the private key:
openssl req -new -x509 -key private.key -out certificate.cert -days 365 -subj /CN=<loginradius-app-name>.hub.loginradius.com
View certificate from the last step:
vi certificate.cert (for Linux OS)
Note: To view the ID Provider Certificate key and ID Provider Certificate for Windows OS, go to the folder where you are running the command, and the key will generate in the private.key and certificate.cert file within the same folder.
Copy the values of LoginRadius’ certificate and key with headers and paste in the Id Provider Certificate and Id Provider Certificate fields, respectively.
Add the key-value pairs in the Attibutes section(optional).
Select the Name Id format from the Dropdown.
Default is urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
Enter the URLs of the page that users will be redirected to for authentication in Login URl and After Logout URL
Enter the Service Provider endpoints and settings that LoginRadius will communicate with to establish a SAML session in the Service Provider Details section.
In Assertion Consumer Service Location, enter the IdP-Initiated Login URL, which you will get from the SAML supported app dashboard or metadata file.
In the Audiences section, add the intended recipients of the assertions issued.(optional)
Select the SSO method from the dropdown list.
The other methods are:
- HTTP Post
- HTTP Artifact
- Once all the required fields are completed, scroll down and click Save.
Note: The consumer should have an account with the same email address in your SAML application as well as in LoginRadius before using your SAML application to log in to the LoginRadius Dashboard.
SAML is an XML-based markup language for creating, requesting, and exchanging security assertions between applications. SAML enables web-based, cross-domain single sign-on (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to the user.
Before going into the in-depth detail of SAML, let’s first see the advantages or benefits that SAML provides.
- Standardization: SAML is a standard format that allows seamless exchange of information between systems, independent of implementation, platform-specific architecture, and implementation.
- Platform neutrality: SAML abstracts the security framework away from platform architecture and particular vendor implementations. Making security more independent of application logic is an important tenet of Service-Oriented Architecture.
- Loose coupling of directories: SAML does not require user information to be maintained and synchronized between directories.
- Better UI experience: SAML enables single sign-on by allowing users to authenticate at an identity provider and then access service providers without additional authentication. In addition, identity federation (linking of multiple identities) with SAML allows a better-customized user experience at each service while promoting privacy.
- Reduced complexity: Using SAML to ‘reuse’ a single act of authentication (such as logging in with a username and password) multiple times across multiple services can reduce the cost of maintaining account information. This burden is transferred to the identity provider.
- Centralized Risk Management: In SAML, the responsibility for proper management of identities lies with the identity provider. This is more manageable and desirable rather than handling multiple service provider systems.
SAML framework consists of three sets of components:
A SAML assertion is a package of data produced by a SAML authority. Alternatively, you can say that a SAML Assertion is the XML document containing the user authorization that the identity provider sends to the service provider.
SAML specifies three types of assertions:
- Authentication Assertion: It indicates that the user has been authenticated, and it includes the time and method of authentication.
- Attribute Assertion: It is a characteristic or trait of a user that describes the user. It is a name: value pair. An attribute assertion conveys user information from Cloud Identity to the service provider.
- Authorization Decision Assertion: It indicates whether a request to access a resource by the subject has been approved or declined.
SAML protocols describe how certain SAML elements (including assertions) are packaged within request and response elements, and give the processing rules that SAML entities must follow when producing or consuming these elements.
SAML defines several request/response protocols. The protocol is encoded in an XML schema as a set of request-response pairs. The protocols are defined as follows:
- Assertion Query and Request Protocol: It defines a set of queries by which existing SAML assertions may be obtained. The query can be based on a reference, subject, or statement type.
- Authentication Request Protocol: It defines a message that causes a response to be returned containing one or more assertions. The flow begins at the service provider who issues an explicit authentication request to the identity provider. A Service Provider issues the response with the Identity Provider returning the message to enable the Web SSO workflow.
- Artifact Protocol: It provides a mechanism to obtain a previously created assertion by providing a reference. The reference is called an artifact. Thus, a SAML protocol can refer to an assertion by an artifact, and when a service provider obtains the artifact, it can use the artifact Protocol to obtain the actual assertion using this protocol.
- Name Identifier Management Protocol: It provides mechanisms to change the name of a user’s value or format. The issuer of the request can be either the Service Provider or the Identity Provider. This protocol also provides a mechanism to terminate an association of a name between an Identity Provider and Service Provider.
- Single Logout Protocol: It defines a request that allows the simultaneous log out of all sessions associated with a user. The logout can be directly initiated by the Principal or due to a session timeout.
- Name Identifier Mapping Protocol: It provides a mechanism to enable account linking. Refer to the subsequent sections on the Federation.
SAML bindings describe how a SAML message must be mapped on non-SAML messaging formats and communication protocols. For example, SAML requests can be bound to interactions using different application protocols, including:
- Simple Object Access Protocol (SOAP)
- Hypertext Transfer Protocol
- Simple Mail Transfer Protocol
- File Transfer Protocol, BizTalk
- Electronic Business XML (ebXML)
Below are some examples of Bindings that are supported by SAML.
- SAML SOAP Binding: It defines how SAML protocol messages are transported within SOAP1.1 messages. In addition, it also defines how the SOAP messages are transported over HTTP.
- Reverse SOAP (PAOS) Binding: It defines a multi-stage SOAP/HTTP message exchange that permits an HTTP client to be a SOAP responder. Used in the Enhanced Client and Proxy Profile and particularly designed to support WAP gateways.
- HTTP Redirect Binding: It defines how SAML protocol messages can be transported using HTTP redirect messages (i.e., 302 status code responses).
- HTTP POST Binding: It defines how SAML protocol messages can be transported within the base64-encoded content of an HTML form control.
- HTTP Artifact Binding: It defines how a reference to a SAML request or response (i.e., an artifact) is transported by HTTP. It defines two mechanisms, either an HTML form control or a query string in the URL.