SSO SAML is not LDAP

Every so often we get a question similar to: We want to replace our LDAP authentication with SSO SAML authentication without losing any functionality. Is that possible?

Unfortunately no. SAML is not a direct replacement for LDAP. This is a technical, protocol, limitation and this article with walk through what limitations SSO SAML has over LDAP and possible workarounds.

Please note that most of the issues are limitations with the procotols SAML vs LDAP, not LiquidFiles implementation issues.

What is LDAP?

LDAP (Lightweight Directory Access Protocol) is in its most basic form a protocol that can be used to look up objects in a directory. LDAP is a back-end protocol that happens between a server (like LiquidFiles) and a LDAP server/directory (like Active Directory).

LDAP can also be used for authentication and when someone authenticates to the server (LiquidFiles in this case), the server will attempt to authenticate to the LDAP directory and if successful grant the user access. The main difference from SAML below is exactly that — the server will attempt the authentication. There's nothing LDAP that happens between the web browser/Outlook plugin or any other client and LiquidFiles. LDAP happens between the server (LiquidFiles) and the LDAP server/directory.

What is SAML

SAML (Security Assertion Markup Language) is a front-end protocol built for web browsers to provide Single Sign-On (SSO) for web applications. There's no user lookup facilities in SAML and it doesn't work without a browser.

Technically, SAML works by redirecting the web browser to the SAML server, the SAML server authenticates the user and redirects browser back to the server (LiquidFiles in this case) with a signed response in the URL. The server (LiquidFiles) verifies the signature using the SAML servers certificate fingerprint and if successful will grant access to the user.

So in direct opposite from LDAP above, with SAML, there's no SAML exchange that happens between the server (LiquidFiles) and the SAML server when the user authenticates. The only thing that happens is that the web browser gets redirected between the server (LiquidFiles) to the SAML server and then back to the server to complete the authentication.

Summary of Differences

Authentication and possible workarounds

Web Browser

Both LDAP and SAML supports Web browser authentication. Nothing special's needed.

Outlook Client

Starting with the version 2.1, the Outlook plugin is able to display a browser window and execute SAML flow.

A possible workaround which we do not recommend any longer is to use the Windows Authentication Proxy which will authenticate existing users but not new users (because we need LDAP to lookup users to see if they exist).

Mac/IOS Clients

The Mac/IOS client is not a web browser so cannot authenticate using SAML directly. If/when we build the browser window authentication for the Outlook plugin, it's likely that this will be extended to the Mac/IOS Client as well.

Windows/Unix/Linux CLI apps

Again, the CLI apps are not web browsers so cannot authenticate with SAML. All CLI apps have the ability to authenticate with their API keys directly though so for existing LiquidFiles users, it's possible to use the CLI apps with the API key.

Windows CLI app is able to execute SAML flow in the default browser starting with version 3.7.7

It will never be possible to authenticate currently non-existent LiquidFiles users because we need LDAP to look up users.

Custom API integration

Depending on what you have built and how that works, this may or may not be a problem. Typical custom API integrations would be for instance a payroll system that uses LiquidFiles to securely send staff their payment details when they receive their payments. For something like that, you would use a long term LiquidFiles user account so wouldn't rely on any external authentication.

User Lookup Issues and possible workarounds

By now it should be clear that the main difference between SAML and LDAP is that SAML is authentication using web browsers only, and that it cannot lookup user accounts. Here are some scenarios you need to be aware of that may not work as expected if you've previously relied on LDAP.

Secure Messages

By default, LiquidFiles is configured so if an external user tries to send a message to joe.user@company.com, LiquidFiles will first search in the local database for that user, and then try to lookup that user in LDAP. If the user exists, or could exist, then the external user is permitted to send a message to joe.user@company.com. If the user doesn't exist, or we don't have LDAP to lookup the user, the external user will not be permitted to send the message.

A possible workaround is that in Admin → Groups, edit the group you want (Externals Users in this case), you can set Limit Recipient Domains to company.com, and any other local email domain you may have, then any external user will be permitted to send to users in that domain. But if for instance the external user makes a typo to a nonexistent user (like joe.ser@company.com) then this will still be permitted even if that message will ultimately fail to be delivered.

User Filedrops

It's common that companies setup User Filedrops like https://liquidfiles.company.com/filedrop/joe.user@company.com and with LDAP it doesn't matter if that user account exist or not. If someone visits that URL, LiquidFiles will first search the local user database and then lookup the user in LDAP to see if that user exists, and if the user exist then the joe.user@company.com account will be automatically created and when the files are uploaded joe.user@company.com will receive the Filedrop even if they never before logged into the LiquidFiles system. Without LDAP to look up the user details, this Filedrop will simply return a 404 not found instead.

This issue will become worse if you automatically delete users after a period of inactivity which could lead to this User Filedrop URL suddely stops working because the account was deleted and without LDAP we cannot automatically re-created it.

The only workaround would be to manually create (and delete) user accounts. Possibly using the LiquidFiles User Admin API.

Automatically Assign Users to Groups

In LDAP, we can lookup group belongings using the memberof attribute and match LDAP/AD groups to LiquidFiles groups and automatically assign users to group. There's no similar well-defined attributes in SAML but definitely something that we will be looking into further in future releases.

Summary

As you can see, SAML is not a direct replacement for LDAP and was never designed to be. If you remove LDAP from LiquidFiles where you previously had LDAP enabled, there are certain things that will not work, or work the way they did before. Depending on your situation, this may or may not be a problem for you.