LDAP Authentication vs SSO in Moodle and Totara

Email “AD SSO / authentication / user provisioning for Totara”, 20201116

Hello,

Or is this option not available if you’re using Azure, because it’s a cloud service? (They have a AD Premium P1 license).

That’s correct. Azure on Cloud does not allow direct LDAP access to the AD. To be able to use LDAP, they will also need to set up AD DS.

But then again, they will need an IT team with knowledge in how to perform this set up; that’s something very convoluted, thus why I recommend avoiding it and settling up for an actual SSO solution.

Here are some references they can use to understand better how to set up everything. I strongly recommend they go through these tutorials, where they also talk about the security implications of using Domain Services – in short enabling LDAP over the internet is just like enabling MySQL access over port 3305 publicly:

• Domain Services product page: https://azure.microsoft.com/en-us/services/active-directory-ds/

• How to set up Domain Services: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-instance

• How to set up LDAP using AD DS: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-configure-ldaps

But there’s a specific LDAP auth plugin, which is available by default under Moodle and Totara, which should in principle allow SSO, right?

The LDAP plugin, in practice, does allow authentication, but not SSO – it is generally used when you have on-premises AD software and Moodle has easy access to it through the local network/intranet.

A SSO solution handles authentication in a central application, removing the necessity of authentication in different platforms and providing an abstraction around the data source, be it an AD, a DB, a Web service, etc.

Here’s a quick example:

Let's say we have three Moodle instances: A, B and C.

Using LDAP, this is how authentication is handled within each instance:

• Instance A

  1. User logs in using the login page

  2. Moodle connects to LDAP and queries the credentials against a matching document in AD

  3. Moodle check if user exists; if not, create it

  4. Moodle creates user session

• Instance B

  1. User logs in using the login page

  2. Moodle connects to LDAP and queries the credentials against a matching document in AD

  3. Moodle check if user exists; if not, create it

  4. Moodle creates user session

• Instance C

  1. User logs in using the login page

  2. Moodle connects to LDAP and queries the credentials against a matching document in AD

  3. Moodle check if user exists; if not, create it

  4. Moodle creates user session

But using SSO, this is how authentication looks like:

• Instance A

  1. User choose to log in and is forwarded to the SSO application

  2. User logs in the SSO app (just once), ignorant of where it checks against (db, ldap, web service, etc)

  3. Redirects back to the instance with outcome and user data

  4. Moodle check if user exists; if not, create it

  5. Moodle creates user session

• Instance B

  1. User choose to log in and is redirected to the SSO application

  2. User is already logged in, so just redirects back to the instance with outcome and user data

  3. Moodle check if user exists; if not, create it

  4. Moodle creates user session

• Instance C

  1. User choose to log in and is redirected to the SSO application

  2. User is already logged in, so just redirects back to the instance with outcome and user data

  3. Moodle check if user exists; if not, create it

  4. Moodle creates user session

So you see there is a slight difference (highlighted in bold) in terms of how user authentication is handled:

• LDAP authentication is made locally: Moodle has to know where to check the credentials against, very similar to the regular authentication but using an external data source.

• SSO the authentication is made in an external application: Moodle doesn’t know where the user credentials actually come from; it just receives the outcome (if successful or not) and the profile information of the user.