Introduction
By integrating your Docebo with Microsoft ADFS 2.0 (and thus, Docebo's SAML App), your Docebo users will be able to log in to their platforms without entering Docebo user credentials, provided that they are already logged into your AD domain.
Docebo does not provide support for ADFS or other third party technologies implementing the SAML 2.0 protocol. This document is to be intended only as a set of best practices for IT administrators. Docebo cannot be held liable for any damage or malfunctioning due to an incorrect ADFS configuration.
This SAML integration will also work with Azure AD, though the Azure setup may differ slightly from the steps and screenshots provided here for ADFS Enterprise. Learn more about setting up OpenID Connect with Azure AD.
Step 1: Enable HTTPS on Your Platform
ADFS requires that any Service Provider (such as Docebo) implements the HTTPS protocol. You should therefore ensure that you have HTTPS enabled on your platform before going through the next steps. For more information, please see Activating and Managing the HTTPS App.
Step 2: Retrieve SAML 2.0 Configuration from ADFS
Now, you need to open the ADFS 2.0 Management via Start → Administrative Tools → ADFS 2.0 Management. Then, right-click on Service in the left panel, and choose Edit Federation Service Properties from the menu.
The General Tab contains the Federation Service Identifier, which is the Identity Provider URL. Copy this URL into your clipboard, as you’ll have to enter it into your platform later. Our Identity Provider example for this tutorial will be http://adfs.adatum.com/adfs/services/trust
.
Step 3: Activating the SAML Docebo App
Activate the SAML app as described in the Managing Apps & Features article of the Knowledge Base. The app is listed in the Single Sign On tab.
Once it’s activated, you can begin the configuration. Please refer to the Configuring the SAML Docebo App section to learn more.
Step 4: Configuring the SAML Docebo App
To begin the configuration for this app, access the Admin Menu by scrolling your mouse over the gears icon. Then, find the SAML Settings section in the Admin Menu, and press the Settings subitem. You will then be redirected to the settings page. Select the Active checkbox in order to enable the configuration. This option is not enabled when activating the app in your platform. Therefore, enable it to proceed with the app configuration in your platform.
Begin by inserting your identity provider ID, XML metadata, and username attribute into the corresponding text boxes on this page:
- Identity Provider ID
- This is the Federation Service Identifier from Step 2.
- XML Metadata
- Open your web browser and go to the following URL:
https://domain.name/FederationMetadata/2007-06/FederationMetadata.xml
Replacedomain.name
with your ADFS 2.0 domain name, such asadatum.com
. Then, open the downloaded XML file with a text editor, such as Notepad, and copy its entire content. Then, paste it into the XML Metadata field in your platform. - Username Attribute
- This is the attribute statement identifier configured in Step 5. (e.g.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
).
Please note that the Download button only appears after you have inserted all of the mandatory information on this page and pressed Save Changes. Once it appears, press the Download button at the bottom of the page, then save the XML file to your computer.
Now, you can flag which encryption algorithm (SHA-1 vs SHA-256) to use to validate the Identity Provider. For new configurations, the default value will be SHA-256. If you already have a valid configuration in your platform, the default value will be SHA-1. SHA-256 is recommended for security reasons.
Then, you can flag the option to enable a service provider certificate. Some Identity Providers or Federations may require that Service Providers hold a certificate. If you enable a certificate for your Service Provider, you will be able to sign requests and responses sent to the Identity Provider. If you flag this option, press the Choose File buttons that will appear below to upload your Private Key File and your Certificate File. Please note that you cannot upload only one of these files. You must upload both files.
SSO Behavior


Logout Behavior
User Provisioning

Step 5: ADFS 2.0 Relying Party Trust Configuration
The quickest way to configure the Relying Party Trust in ADFS is to download the Service Provider metadata XML file from Docebo, then import it inside ADFS. Begin by logging into your platform (remember to use HTTPS) as a Superadmin. Then access the Admin Menu by scrolling your mouse over the gears icon. Then, in the SAML Settings section, press the Settings subitem. Now, return to your ADFS Management Console, then select Relying Party Trusts in the left panel under Trust Relationships. Right-click on Relying Party Trusts and choose Add Relying Party Trust from the menu that will appear.



Step 6: ADFS 2.0 Claim Rules Configuration
In order to configure proper communication between your ADFS and Docebo, you should define the Claim Rules by right-clicking on the relying party you’ve just created (e.g. Docebo ADFS) and then selecting Edit Claim Rules.
On the Issuance Transform Rules tab, press Add Rules. Then, select Send LDAP Attributes as Claims and press Next. Now, define the Claim Rule name and select Active Directory in the Attribute Store dropdown menu. Under Mapping of LDAP attributes to outgoing claim types, select all of the attributes that you want to export as claims for the SSO. Examples are:
- LDAP Attribute: E-Mail-Addresses; Outgoing Claim Type: E-Mail Address
- LDAP Attribute: Given-Name; Outgoing Claim Type: Given Name
- LDAP Attribute: User-Principal-Name; Outgoing Claim Type: UPN
Add a second rule by following the same procedure. Select Transform an Incoming Claim, then press Next. Now, define the Claim Rule name, and set the Incoming claim type as one of the previously configured attributes. Then, set the Outgoing claim type as Name ID. Finally, set the Outgoing name ID format as Transient Identifier. Then, press Finish. The incoming claim type should match the username of your users inside Docebo for the SSO to work properly.
Step 7: SSO in Action
Even after you’ve successfully configured SAML for ADFS, you'll notice that your users will still see the standard Docebo login form (with username and password). To change this, you need to give your platform access to a subset of users currently not in your AD user registry. Alternatively, if you want to let your users use SSO inside Docebo, you should use this URL:
https://yourlms/index.php?r=site/sso&sso_type=saml
Replace yourlms
with your custom platform domain.
Appendix: User Provisioning from AD to Docebo
Once SAML and ADFS are properly configured, any user logged into your Windows AD domain can access the platform without entering any credentials. However, this requires that the following requirements are met:
- The user trying to use SSO should have a valid Docebo account created before SSO is attempted. You can learn more about creating users with SAML, or you can learn more about creating users in your platform.
- There must be a match between the platform username and the Username claim attributed (see Step 5).
Best Practices
- In order to make the most of this integration, you should set up groups that are auto-populated, then use Docebo's Enrollment Rules App to automatically enroll these groups into courses or learning plans. Thus, when a new user is created, you do not have to manually assign them to groups, courses or learning plans. Additionally, you can use the following SSO links to automatically access some areas of your Docebo platform with an SSO login:
- Docebo Homepage:
/lms/index.php?r=site/sso&sso_type=saml
- Into a Specific Course:
/lms/index.php?r=site/sso&sso_type=saml&id_course=18
- Catalogs Area:
/lms/index.php?r=site/sso&sso_type=saml&destination=catalog
- Learning Plans:
/lms/index.php?r=site/sso&sso_type=saml&destination=learningplan
- Clients can rely on a growing set of REST APIs to implement their own user provisioning logic (see our API documentation page).
- When an SSO integration and a custom domain are set up at the same time, it is strongly suggested to configure the Custom Domain first. The endpoint URLs needed for the SSO integration are dependent on the URL of the platform. For more information about custom domains, please see Managing the Custom Domain App.