Hey @tommyVan you can’t ask too many questions! 

Disclosure - I have mcguyvered my way into understanding and setting up saml but I’m not an expert and my knowledge is pretty homegrown so I might be mix up some terms here and there.

One thing that might save some time is to open a support ticket and be sure to turn on saml logging. They’ll be able to pull a log that will provide information on what we’re seeing on our side that might provide some insights. 

The biggest issues I remember from working with clients were the following: 
 

1. Ensure that the username attribute matches the format you’ve put here. I’ve seen with some AD implementations that clients think they’re passing the value as something like “user.login” but in reality are sending it as “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”
    

   

   
   
    
2. Ensure that you’re passing the attribute information in the claims array and not as a parameter in the URL. 
   
   Here’s an example of what it would look like on our side.
   
    

   json:
   currentDomain:customerdomain.com
   headers:{}
   logTime:2022-07-14T10:33:57.117+02:00
   message:SAML returned these claims: Array
   (
       hhttp://customerdomain.com/claims/emailaddress] => Array
           (
               a0] => customvaluecustomvalue=
           )
   
       lhttp://customerdomain.com/claims/emailaddress] => Array
           (
               a0] => customvaluecustomvaluecustomvalue
           )
       uhttp://customerdomain.com/claims/emailaddress] => Array
           (
               a0] => customvaluecustomvalue=
           )
   
       lhttp://customerdomain.com/claims/emailaddress] => Array
           (
               a0] => customvaluecustomvaluecustomvalue
           )
   
   )

    

So a quick question @pmo and @tommyVan - the screen from @tommyVan  looks like the choices for the just in time provisioning screen.

And Tom’s question is centered on change. Will a change in the IDP change the value in the LMS for a given user?

I have typically used an SSO for both - just in time provisioning to connect an IDP as well as a blended approach where I had an HRIS system sending metadata to generate and change records and an SSO just for the authenticating only...but the HRIS system handled the updates.

I hope this is not confusing the story.

Now I feel like a boob…

Ignore my query….

@tommyVan - last note - when we exhausted all of our options? Eventually we got someone from Docebo on the line and they took a look at what was happening….it was something small.

More specifically, we want the fields provisioned to change when the users sign in. We also want new users to be created in Docebo when they click the SSO button for the first time, never previously having an account. Neither thing is currently happening, though extant users in this branch can login. I have several support tickets open, have reached out to our AM, and @pmo here has started me down the right path I believe. 

As of right now, my best guess as to why this isn’t working is that the username and email in the IDP are both set to the same attribute statement: 

I am waiting on the team to change this in the IDP to see if this is the solution. Will 100% update this when I know more.

So, if anybody is using Azure with Docebo, it’s a total nightmare, but we did get it working. The trick was using the schema.xmlsoap links as attribute statements. Here is a picture of the final state that provisions users for the listed fields:

The biggest problem we are still having is the fact that Docebo does not allow Direct Manager to be provisioned. We all talked about this on another thread at one point, and the Docebo employees confirmed that this is not possible, as Direct Manager is a relational field. Well, in Azure (as with other IDPs) it is a user field. The latter is certainly the better way to set up manager management.

Now, though our customer had us purchase Extended Enterprise to set up a domain on which they could have SSO (with the leading intention of doing away with CSV uploads), we still need to use our previous, clunky workflow to accomplish the same goal. If they aren’t disappointed in this functionality (they are), I am. 

Even though the product works now, it really doesn’t. 

Not sure if this will help, but we found a lot of issues about auto provisioning and user data updates were resolved when we turned off the “lock provisioned user fields” on our SSO instance. For any of the fields other than the First name, Last name, Language, we used the Field Name as the Attribute Statement, which was suggested by Docebo Support when we set it up. Seems to populate the data for us without issues.

Hope that helps.

We also slimmed down our SSO fields and automate a CSV file daily to update additional user fields.

We have a similar issue that we are attempting to resolve with docebo support for user provisioning. Where can access a full list of schema?

https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Thank you!

So, if anybody is using Azure with Docebo, it’s a total nightmare, but we did get it working. The trick was using the schema.xmlsoap links as attribute statements. Here is a picture of the final state that provisions users for the listed fields:

The biggest problem we are still having is the fact that Docebo does not allow Direct Manager to be provisioned. We all talked about this on another thread at one point, and the Docebo employees confirmed that this is not possible, as Direct Manager is a relational field. Well, in Azure (as with other IDPs) it is a user field. The latter is certainly the better way to set up manager management.

Now, though our customer had us purchase Extended Enterprise to set up a domain on which they could have SSO (with the leading intention of doing away with CSV uploads), we still need to use our previous, clunky workflow to accomplish the same goal. If they aren’t disappointed in this functionality (they are), I am. 

Even though the product works now, it really doesn’t. 

@tommyVan would you know what the schema.xmlsoap links for Job Title and Department are?

The department one is a custom field in our instance of docebo and in Azure it’ll be something like: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/department but that’ll depend on your azure instance if I’m remembering correctly.

Job title is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/jobtitle

@tommyVan 

Thank you for the additional information. I had to get our tech team to create claims for department field. All is working now.

Glad you got it working!

Just a small note from painful experience. Make sure your UserPrincipalName doesn’t change. Ours does (when they get married/change name) so we coudn’t use that as our username. We had to use our ObjectID from the network. If it DOES change, it will create a new account.

@Maz Thank you for the heads up. For sure, I’ll  definitely look into switching to ObjectID instead of the UserPrinciplaName. Would you have any guidance on how to accomplish this? 

Practise it in a sandbox to make sure it’s not going to negatively affect how you have Docebo set up.

Have a manually created super admin account set up with a password, and the login box turned ON, incase anything goes awry with SSO setup.

Export all your users into a csv, I did just username, names and email. Modify the username in excel from a list provided from your network (I did a vlookup). Have the SSO configuration changed and immediately import the csv back into docebo.

After ironing out some minor issues in the sandbox, mine went very smoothly in live.