How to configure SAML Connector

Business Case:

KPI to be measured

Bookmark this resource Follow

Ask a question

Was this article helpful? 0 out of 0 found this helpful


  • SAML: stands for Security Assertion Markup Language, an authentication and authorization protocol based on XML. SAML was developed to meet the need to authenticate the users of an organization in all the tools used at the enterprise level. SAML is currently at version 2.0, fully supported by the THRON connector.
  • SCIM: stands for System for Cross-domain Identity Management. It is a standard for automating the exchange of user identity information between identity domains, or IT systems.
  • Identity Provider: is a system that allows you to centrally manage the identities of users, offering the ability to connect with various tools that support secure authentication protocols (such as SAML). In addition, Microsoft Active Directory Federation Service and Oracle Identity Federation are well known.
  • Single Sign-On or SSO: is the process that allows users to authenticate themselves on all the services made available in a given network (for example the company intranet, DAM, CRM, etc.) with a single shared user, which is managed from a single tool.


SAML Connector


SAML Connector was developed to allow customers using their SAML 2.0-based Identity Provider for user management to connect those users to the THRON platform. This centralizes the management of the user's identity, userID, passwords and password policy in a single system.
Thanks to the connector, credentials, and authentication of all users present in the customer's IdP will not be managed and duplicated in the THRON platform. Users can be created at the same time as their first access to the THRON platform and assigned to a specific corporate group in order to acquire appropriate roles and permissions to use the platform.
The SCIM standard allows to manage the automatic provisioning of users and groups to THRON from external IdPs. Users imported through SCIM will be able to authenticate themselves to the platform only through the integration provided by the SAML connector.




For a proper functioning the SAML connector needs:

  • An IdP installed by the customer based on SAML 2.0 protocol This parameter is a URL provided directly by the IdP.
    • IdP provider Metadata, accessible through public URL, an XML file that identifies the public keys and information that the IdP makes available to the service that uses the service.
  • The SAML Connector, properly configured in THRON


IdP configuration


  1. Each identity provider has its own specific configuration flow to enable an external SAML client to perform an SSO. Make sure that your company uses an IdP that supports the SAML 2.0 standard, such as Microsoft Active Directory Federation Service.
  2. Make sure that the THRON Platform Administrator has created a specific group in which the users inserted by the connector will be included. This will allow the connector to keep track of all new users, give them the appropriate roles and, once done, remove them from this entry group to be included in the correct groups.
  3. Create a new SAML integration (normally this process is done by configuring an access app). The information to indicate is:
    1. THRON SSO URL: https://[clientId][clientId]/[appId] this is the URL to the SAML application created in THRON. Use this URL as both "Recipient Url" and "Destination URL". The APPID parameter can be found in the URL of the THRON application configuration page https://[clientId][appId]
    2. Define the "Service provider Entity ID": https://[clientId][clientId]. The same identifier will be used in the configuration of the SAML Connector in THRON.
    3. Define the name of the attributes for the user's username, email, lastname, firstname fields. This information is needed by the THRON SAML Connector to understand how to map the user information provided by SAML.


THRON Configuration


  1. Go to the Marketplace section and install a SAML Connector.
  2. Configure the integration by providing the URL to your provider's Metadata IdP. Each IdP should provide an accessible URL.
  3. Define a Service Provider Entity Id, for example: http://[clientId][clientId]
  4. Download and install the provided XML file and use it for the IdP side configuration (if requested by your provider)



[dropdown: Configuring SAML Connector with Microsoft Azure]

In this section we are going to describe how to configure the SAML Connector in order to integrate with the IdP included in Microsoft Azure. Please consider that in order to install the application you need the Premium version of Azure AD

The first thing to do is to activate a SAML Connector within THRON. Once you have completed the activation phase of the connector, leave all the parameters blank, make sure you retrieve the appId as illustrated here:




At the same time, in Microsoft Azure, access "Azure Enterprise Applications", after clicking "Azure Active directory" in the left menu:




Once there, click on "+New application" and make sure you create a "Non-gallery application", providing it with a proper name.

Now that the application has been created in Azure, click on "Getting Started" and then on "Configure Single Sign On":




Now click on "Saml" to set THRON SAML Connector parameters. Use the following configuration:

  1. Basic SAML Configuration:
    1. Identifier: https://<yourclientId><yourclientId>-<yoursamlconnectorname> (this corresponds to the "Service Provider Entity Id" field in the SAML Connector's configuration panel).
    2. Reply URL: https://<yourclientId><yourclientId>/<appId>
  2. User attributes & Claims:
    1. Givenname: user.givenname
    2. Surname:user.surname
    3. Emailaddress: user.userprincipalname
    4. Username: Join (user.mailnickname, ".", ""idp")
    5. Unique User Identifier: user.objectId
  3. SAML Signing Certificate:
    1. Retrieve the "App federation metadata URL" and paste it into the "IdP metadata URL" field of the SAM Connector's configuration panel.
    2. In order to configure the name of the user attributes within the SAML Connector, access the "User attributes & Claims" section in Azure, copy the respective "Claim name" and paste it into the field related to the corresponding attribute in the SAML Connector configuration panel.
      Note: nameidentifier MUST BE user.objectid in Persistent configuration, see screenshot below:





SCIM Configuration

Now you can move on to setup user provisoning  (SCIM). Go back to the application menu and click on "Provisioning", then set "Provisioning mode" to "Automatic":




In the "Admin credentials" section, use the following configuration:

  1. Credentials: http://<yourclientId><yourclientId>/<appId>
  2. Secret Token: Contact THRON Customer Service to get your SAML Connector secret key

Under the "Mapping" section, make sure that both mappings are enabled, click on each element and configure it with the following parameters:

  1. Users:
    1. ObjectId:externalId
    2. accountEnabled:active
    3. userPrincipalName:email[type eq work].value
    4. Append([mailNickname], ".idp"):userName
    5. givenName:name.givenName
    6. surname:name.familyName
  2. Group attribute mapping:
    1. ObjectId:externalId
    2. displayName:displayName
    3. members:members

Now under "Settings" set the parameter: "Sync only assigned users and groups", so to avoid that all the users in your AD are synced with THRON.

Finally, enter the "Users and groups" section and assign to the application all the users and groups that must be synced with THRON:



[/dropdown][dropdown:Configuring SAML Connector with Microsoft ADFS]

THRON supports single sign-on (SSO) logins through SAML 2.0 if you're on the Professional or Enterprise plans. A SAML 2.0 identity provider (IDP) can take many forms, one of which is a self-hosted Active Directory Federation Services (ADFS) server. ADFS is a service provided by Microsoft as a standard role for Windows Server that provides a web login using existing Active Directory credentials. 



To use ADFS to log in to your THRON instance, you need the following components: 

  • An Active Directory instance where all users have an email address attribute. 
  • THRON SAML Connector configured. 
  • A server running Microsoft Server 2012 or 2008. This guide uses screenshots from Server 2012R2, but similar steps should be possible on other versions. 
  • An SSL certificate to sign your ADFS login page and the fingerprint for that certificate. 

If you meet these basic requirements, you need to install ADFS on your server. Configuring and installing ADFS is beyond the scope of this guide, but is detailed in this Microsoft KB article. 

When you have a fully installed ADFS, note down the value for the 'SAML 2.0/W-Federation' URL in the ADFS Endpoints section. If you chose the defaults for the installation, this will be '/adfs/ls/'. 


Step 1 - Adding a Relying Party Trust


At this point you should be ready to set up the ADFS connection with your THRON account. The connection between ADFS and THRON SAML Connector is defined using a Relying Party Trust (RPT). 

Select the Relying Party Trusts folder from AD FS Management, and add a new Standard Relying Party Trust from the Actions sidebar. This starts the configuration wizard for a new trust.




In the Select Data Source screen, select the last option, Enter Data About the Party Manually.




On the next screen, enter a Display name that you'll recognize in the future, and any notes you want to make. 




On the next screen, select the ADFS FS profile radio button.




On the next screen, leave the certificate settings at their defaults.




On the next screen, check the box labeled Enable Support for the SAML 2.0 WebSSO protocol. The service URL will be: https://<yourclientId><yourclientId>/<appId>




On the next screen, add a Relying party trust identifier. https://<yourclientId><yourclientId>-<yoursamlconnectorname> (this corresponds to the "Service Provider Entity Id" field in the SAML Connector's configuration panel).




On the next screen, you may configure multi-factor authentication but this is beyond the scope of this guide. 




On the next screen, select the Permit all users to access this relying party radio button.




On the next two screens, the wizard will display an overview of your settings. On the final screen use the Close button to exit and open the Claim Rules editor. 




Step 2 - Creating claim rules


Once the relying party trust has been created, you can create the claim rules and update the RPT with minor changes that aren't set by the wizard. By default, the claim rule editor opens once you created the trust.




To create a new rule, click on Add Rule. Create a Send LDAP Attributes as Claimsrule.




On the next screen, using Active Directory as your attribute store, do the following: 

  1. From the LDAP Attribute column, select E-Mail Addresses. 
  2. From the Outgoing Claim Type, select E-Mail Address.




Click on OK to save the new rule. Create another new rule by clicking Add Rule, this time selecting Transform an Incoming Claim as the template.




On the next screen: 

  1. Select E-mail Address as the Incoming Claim Type. 
  2. For Outgoing Claim Type, select Name ID. 
  3. For Outgoing Name ID Format, select Email. 
  4. Leave the rule to the default of Pass through all claim values.




Finally, click OK to create the claim rule, and then OK again to finish creating rules. 

Add the following claims to map LDAP attributes with SAML: 

  • LDAP username -> username 
  • LDAP first name -> firstname 
  • LDAP last name -> lastname 

Note: Your instance of ADFS may have security settings in place that require all Federation Services Properties to be filled out and published in the metadata. Check with your team to see if this applies in your instance.  If it is, be sure to check the Publish organization information in federation metadata box. 

[/dropdown][dropdown:Configuring SAML Connector with Google Apps]

  • Access the admin console of Google Apps:
  • Access to security section


  • Set up Single Sign On


  • Download the IdP Metadata
    • Keep the file and upload it to an accessible URL.


  • Enter the Apps section > SAML Apps


  • Create a new SAML application



  • Set the Attribute Mapping


  • Use the same denominations even in the THRON SAML App configuration.[/dropdown][dropdown:Configuring SAML with OKTA]
  • Create a new authentication app


  • Configure the app with SSO URL and Service Provider Entity ID


It will then be necessary to associate the registered users within the service to the application just configured.




SAML Usage in THRON Login


Once the SAML Connector has been configured, in the THRON platform login page the user will also see access available through the company IdP.
Users integrated through the SAML Connector, will be able to:

  • Press the "Login with ..." button
  • A popup will open with the IdP Login configured with SAML.
  • In the login form the user can authenticate with the credentials provided and managed by the company IdP.
  • After the authentication, the popup will close and the user will access directly to the THRON platform.




  1. It is not possible to deprovision users automatically, so it will be necessary to keep the user lists aligned manually or through a specific integration.
  2. The integration with IdP through SAML2 is done only with web technology (browser).
  3. The integration is active only in Bulletin Board (web) and only on some Apps specified in the Marketplace.
  4. There is no mapping of roles, groups or permissions configured in the IdP with the roles, groups or permissions of THRON.
  5. The "Remember me" feature of the login is managed by the IdP and not by the THRON platform.
  6. The THRON session is not synchronized with the IdP session, so the authentication is checked again only when the THRON session expires.
  7. The IdP logout does not invoke any THRON side callbacks to close the session.
  8. The automatic provisioning of users occurs only if the user has ALL the required fields in THRON complete (username, first name, lastname and email).
Was this article helpful?
0 out of 0 found this helpful

Have any question?

Open a ticket