Question

Extended Enterprise Logins

  • 1 September 2021
  • 5 replies
  • 280 views

We have a use case where we have internal users & external users. 

Internal users must login via SSO (ADFS), and should not be able to change their Docebo passwords.  External users should have the ability to login via a different SSO (Salesforce) or login directly, and should be able to reset their passwords.  We are hoping to have the embedded experience in both internal Salesforce & our external Salesforce lightning community, but also have both groups be able to login to the platform directly.  None of the actual content will be public.

It seems like we’re going to need to upgrade to Extended Enterprise to accommodate the multiple SSO situation.  However, how does this work for the login behavior?  We would expect both groups to go to the same home/landing page.  Is there any way to set up this kind of home/landing to have two links, one for internal & one for external, which directs users to the correct login experience for their branch?


5 replies

Userlevel 7
Badge +7

Hi @JP77 if you do go ahead with Extended Enterprise, you will have the ability to enable domains for each group where you van configure SSO independently for each domain; or one using SSO and the other not, etc. We have 6 domains in use today and 3 are using SSO and the other 3 use manual login. Also, when you enable SSO you have an option to display (or not) the login screen for any users who are not part of the SSO group on your servers. 

Hope this helps...if you need more info, check out the KB article or ask away

https://help.docebo.com/hc/en-us/articles/360020124899-Managing-the-Extended-Enterprise-App

https://help.docebo.com/hc/en-us/articles/360020083080-Enabling-SSO-in-Docebo-through-a-Salesforce-Identity

 

Thank you for your response @lrnlab

 

Your setup seems to be similar to what we are looking for.

 

How does the login experience work for your different client domains?  Are all of your different clients able to access their subdomains from the root domain?  For example, if my main site/domain is www.mycompanyacademy.com, & we have two clients set up as employee.mycompanyacademy.com and customer.mycompanyacaedmy.com...would users in both client groups be able to access their distinct login experiences from www.mycompanyacademy.com?

Also, if employees are only allowed to login via SSO (no direct login option), but they stumbled over to the customer domain that does have direct login...would those employee users be able to request a password reset from the customer login screen, even though their branch is not tied to that subdomain?

I hope that all makes sense lol, and I appreciate any insight you could provide to help us understand this login behavior with multiple subdomains.  Thanks!

Userlevel 7
Badge +7

HI @JP77 re” root domain question...yes all users can access the LMS via the root domain but I think where you have those using SSO they would always be redirected to their domain with SSO (if I recall out tests correctly). I would recommend you test this if you can just to be sure.

With sub domains in place, if a user attempts to access their profile via a sub domain they do not belong to, a warning message appears stating they cannot access and provides them with a clickable link to their own domain. it looks like this:

 

Userlevel 2
Badge

@JP77 

Hi JP, 

Yes you need the extended enterprise to configure different sign in workflow: 

See an example of our sign in page : 

regular sign in and then the Red button for SSO identity provider, redirect to sso and then after authentication, then redirect to our parent domain. 

 

 

However we ran into an issue recently and it is being investigated by Docebo. The password change policy should not apply to the users who sign in from SSO, but it keeps affecting the users, so these users ended up in a loop of password reset. I am waiting for Docebo to give me an estimated time to fix this. 

Hope this helps. 

Userlevel 2
Badge

@JP77 

You may also look at what Gerrod did for adding an extra button in the header for the separate sign in workflow: 

 

Reply