LDAP is the de facto standard when it comes to managing identity information in an enterprise. It authenticates who you are, with a user name and password, and authorizes what you can do, by means of roles (groups). There are other interesting attributes associated with the ‘who’ such as your name, email address, manager etc. In a frevvo context, the name would typically be used to identify an applicant on a form, while the email and manager can be used to route notifications or escalations in a workflow. In order to route workflow tasks by role, we need to answer the question ‘who are the users that have this role?’. This is information that the LDAP can provide and is not the typical authentication or authorization function that it is used for. We need a direct connection to the LDAP in order to make this query which most organizations are happy to allow as long as the access is within their firewall. This approach has been used successfully in frevvo on-premise deployments for many years.
Let’s now consider a frevvo cloud tenant that needs to access the LDAP. The LDAP now needs to be exposed to the internet, raising visions of hackers stealing identities and personal information. The immediate reaction is to use the tried-and-trusted VPN to secure the connection or single sign-on protocols like SAML that abstract away the LDAP. On the other hand, there is the less popular solution of using a secure LDAP (over SSL or TLS) connection, which is the equivalent of the trusted HTTPS. What is the right approach? VPN offers no more security than secure LDAP as this blog argues, is harder to implement in a multi-tenant product like frevvo, and costs more. Single sign-on protocols like SAML (provided by commercial products like Microsoft ADFS or the open-source Shibboleth OpenSAML) are great for authentication and authorization (and single sign-on, of course) but will not satisfy the routing requirements. We would need to provide a back channel to upload role information to frevvo as we currently do for tenants that do not use LDAP (CSV file import). This is an additional integration that has to be managed by the customer who has the onus of keeping it synchronized, and comes with the risk of stale routing data.
Secure LDAP has the benefit of being just a configuration change (we support both the deprecated LDAPS and the recommended TLS in 6.1) with no change in functionality. Communication between frevvo and LDAP is encrypted, similar to HTTPS. On the other hand, the customer, being in control of security, has to take precautions to ensure that the LDAP information is accessible only to frevvo (origin IP address restrictions), that the data cannot be changed (read-only access), and only the required attributes are exposed (selective replication). In case of Active Directory (by far the most popular LDAP), Microsoft recommends the use of RODC (read-only domain controller) and provides guidelines to implement the above. With this in place, passwords need not be replicated to the RODC (as authentication will be forwarded to the associated writeable DC) and hence are not exposed even if the RODC is compromised.
So what is the right approach? Secure LDAP is, well, secure, has all the capabilities we need to provide the required product features, and requires the least integration effort. This would be our recommended approach. For the skeptical, there is SAML with data upload, which is planned for a later release.
|Routing||√||Need external data sync||√|