How to configure SSO with Microsoft Active Directory Federation Services 2.0 (ADFS 2.0) Identity Provider

TalentLMS supports Single Sign On (SSO), a process that allows users to authenticate themselves against an external Identity Provider (IdP) rather than obtaining and using a separate username and password handled by TalentLMS.

Under the SSO setup, TalentLMS can work as a Service Provider (SP) through SAML (Secure Assertion Markup Language) allowing you to provide Single Sign On (SSO) services for your domain.

The SSO SAML Integration is available in Basic, Plus and Premium subscription plans.

What you will need, is a ADFS 2.0 Identity Provider (IdP) which will handle the sign-in process and will eventually provide the authentication credentials of your users to TalentLMS. TalentLMS users authenticated through your ADFS 2.0 IdP are handled from your IdP and any change they perform on their account (namely first name, last name, and email) are synced back to their TalentLMS account. The only user data that is necessary for TalentLMS is a unique identifier for each user, user's first name, last name and email. TalentLMS does not store passwords.

Step 1. ADFS 2.0 Configuration

Consider that for the current procedure, your ADFS 2.0 server is hosted in (Do not forget to replace with your ADFS 2.0 server actual domain name when following this procedure).

Open the ADFS 2.0 Management through Start→Administrative Tools→ADFS 2.0 Management.

  • Right-click on Service from the left tree-view and click on Edit Federation Service Properties.

  • In the General Tab you can find the Federation Service Identifier, which is the Identity provider URL. You’ll need to fill this up in the TalentLMS Single-Sign-On (SSO) configuration page. For the current procedure the Identity provider URL is Check the rest values in General Tab and confirm that they match your DNS settings for your server.

  • Click on the Certificates Entry from the left tree-view, right-click on Token-Signing certificate and then click on View Certificate

  • In the Details Tab click on Copy to File and theCertificate Export Wizard launches. Click on Next, select DER encoded binary X.509 (.cer) format, and then click Next. Choose where you want to save the certificate and click on Finish.

  • TalentLMS requires a PEM format certificate. So you will need to convert the certificate to PEM format using any appropriate tool or even online tools such as ( Convert the certificate from DER to PEM format. You will need it during TalentLMS configuration in Step 4. Keep in mind that TalentLMS will work with RSA certificates. DSA certificates are not supported.

Step 2. ADFS 2.0 Relying Party Trust Configuration

At this step you are going to define the TalentLMS endpoints in your ADFS. You can do this manually or you can import the metadata XML provided by TalentLMS. You are advised to do the latter, since it is more easier to implement.

Given that your SSO enabled TalentLMS domain is you can find The Metadata XML file at the following address (you should replace with your actual TalentLMSdomain):

Go to this address and download the XML file.

In the case where you find it difficult to access this URL, the Metadata XML looks like the following (again do not forget to replace with your actual TalentLMS domain:

<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="">
<md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol">
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location=""/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location=""/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="" index="0"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="" index="3"/>
  • Select Relying Party Trusts from the left tree-view under the Trust Relationships,right-click on the Relying Party Trusts and click on Add Relaying party Trust. The wizard launches.

  • Click on Start and Choose Import data about the relying party from a file.Click on Browse and locate the Metadata XML file of your TalentLMS domain.

  • Click on Next, ignore the pop-up message and type a distinctive Display Name (eg. Talentlms) and click Next.

  • Select Permit all users to access the relying party and click Next to Finish.

  • On the center Column right-click on the relying part you’ve just created (eg TalentLMS) and the select Properties.

  • On the Advanced Tab select SHA-1 for the Secure hash algorithm and click on OK

Step 3. ADFS 2.0 Claim Rules Configuration

In order to configure a proper communication between your ADFS and TalentLMS, you should define the Claim Rules

  • On the center Column right-click on the relying part you’ve just created (eg TalentLMS) and then select Edit Claim Rules.

  • On the Issuance Transform Rules Tab click on Add Rules. The wizard launches.

  • Select Send LDAP Attribute as Claims and click on Next

  • Define the Claim rule name (eg. Get LDAP Attributes) and select Active Directory in Attribute Store. In the Mapping of LDAP attributes to outgoing claim type select the following:
    LDAP Attribute: E-Mail-Addresses, Outgoing Claim Type: E-mail Address
    LDAP Attribute: Given-Name, Outgoing Claim Type: Given Name
    LDAP Attribute: Surname, Outgoing Claim Type: Surname
    LDAP Attribute: User-Principal-Name, Outgoing Claim Type: UPN
    and then click on Finish 


  • Add a second Rule following the same procedure. Select Transform an Incoming Claim and click on Next.

  • Define the Claim rule name (eg. Email to Name ID) and set Incoming claim Type as E-Mail Address (the same one from the previous rule), Outgoing claim type as Name ID and Outgoing name ID format as Email. Then click on Finish. Have in mind that the email should be defined in all users to achieve a proper communication between your ADFS and TalentLMS.


Step 4. Configure authentication policies

In order to ensure that single logout (SLO) works properly, especially in the case where multiple users login from the same machine, you need to configure authentication settings for the relying party trust you've just created.

Expand  Authentication Policies from the left tree view, and click on the Per Relying Party Trust option. Then in the center Column, right-click on the Talentlms relying party trust, and select Edit custom Primary Authentication. At the Primary tab, check the option Users are required to provide credentials each time at sign in and then click on Ok.

Step 5. Enabling SAML SSO in your TalentLMS domain

Login to your TalentLMS domain as a super-admin and go to Account & SettingsUsers. If your subscription plan supports SSO Integrations (currently supported in Basic, Plus and Premium plans), you can click on Single Sign-On (SSO) link.

In this page you should fill-in information regarding your Identity Provider (ADFS 2.0). All the required information can be retrieved from the IdP’s Metadata XML that can be found in the following URL:

Do not forget to replace with the domain name of your ADFS 2.0

  • SSO integration type: Choose SAML2.0 from the drop-down list

  • Identity provider (IdP): type the Identity Provider's (IdP) URL

  • Certificate fingerprint: Locate the certificate in PEM format extracted in Step 1, open it with your favorite plain-text editor and copy its contents. Then paste them in the text area that will appear when you click on the “paste your SAML certificate (PEM format)” link. The SHA-1 Certificate fingerprint will be computed when you click on the Save button. Keep in mind that TalentLMS will work with RSA certificates. DSA certificates are not supported.


  • Remote sign-in URL: fill-in the remote sign-in URL of your IdP. This is the URL where TalentLMS will redirect your users for signing-in.

  • Remote sign-out URL: fill-in the remote sign-out URL of your IdP. This is the URL that TalentLMS will redirect your users when they sign-out.

The rest of the fields are used to define the variable names of the SAML protocol containing user data provided by your IdP, that is essential for TalentLMS. Avoid the use of variable names with underscores ( _ ). For example do not configure your IdP to send First Name with the variable "given_name". Instead prefer to use "givenname".

  • TargetedID: this is the username of the user account and should be a unique identifier for each user. In our case this is the User-Principal-Name defined in Claim Rules in Step 3.

  • First name: the first name of the user.

  • Last Name: the last name of the user.


  • Email: the email address of the user.
    Note that email is essential for TalentLMS communication, so you should make sure that all users have valid email addresses.

  • Group: the group(s) name(s) that the user is member of. This SAML variable may hold a single string value (group name) or an array of string values (groups names). If group with the same name exists in your Talentlms domain, then the user will be assigned in that group and will get all courses of that specific group on his/her first login. The option “Add assigned groups with each login” can be selected to force group assignment on each login. Have in mind that with this option the user is not removed from groups to match those send by your IdP. Instead, only assignments to new groups are performed.

User Account Matching

At the time of writing of this document TalentLMS provides a passive mechanism for User Account Matching. This means that existing TalentLMS user accounts are matched against SSO user accounts based on their username.

User account matching is only possible in the case where the username provided from your IdP is exactly the same with the an existing TalentLMS account's username. In this case the TalentLMS user account state will remain unchanged during SSO login process. However first name, last name, and email will be pulled from your IdP and will replace existing values.

If the username provided by your IdP, for an existing Talentlms user, is different from his/her TalentLMS username, a new account will be created with the IdP provided username. In this case there will exist two different accounts for the same person.

To ensure that User Account Matching will performed successfully, you should configure your IdP to sent the same username for existing user accounts. The SAML 2.0 attribute name that carries the username can be defined in the  TargetedID field at the Talentlms SSO configuration page.

User Profile

Even though your users are allowed to change their profile (first name, last name, email and username) this is strongly discouraged. Changing first name, last name and email will impact only the current session. The next time a user signs-in, those values will be pulled from your IdP server. Changing the username, will result on the undesirable effect of user mismatching, since users are matched based on this value. So, you should notify your users how SSO affects your TalentLMS domain and avoid changing first name, last name, email and especially username form their profile.

If your users are authenticated only through SSO it is a good practice to disable profile updates for your users by changing the specific user group permissions. To disable profile updates for your learners go to dashboard click on User Types →Learner-Type→ Generic → Profile and make sure that "Update" and "Change password" are not checked.


You have now configured your TalentLMS domain to provide SSO services. Your users may login to your TalentLMS domain using the username and password stored in your ADFS 2.0 Identity Provider.

Feedback and Knowledge Base