Increase Gluu-LDAP security

[mzico]

From: https://support.gluu.org/identity-management/increase-default-opendj-aci-security-2517

[madumlao]

My current suggestion for managing LDAP-based client applications is to simply have a gluu user (which is also an LDAP user) with a boolean attribute for LDAP readonly access.

Perhaps gluuIsLdapReader?

Pro: simplicity Con: no easy way to list all Ldap readers from the Gluu interface. not clearly separated from the other types of SSO client applications.

---

Another approach might be to have a special LDAP readers group that you add a user to. This could also be implemented as a Virtual Group that queries for the presence of the entry above. Or the opposite could be done: a specially marked group of LDAP readers is set in oxtrust, and gluuIsLdapReader is a virtual attribute that checks for the membership of that group.

Pro: simplicity Con: not clearly separated from the other types of SSO client applications.

---

A third approach, but it takes more work, is to have a separate section in oxTrust for LDAP-based clients, so that in the menu, "adding an LDAP client" is at the same level as "adding an OpenID Connect client" or "adding a SAML Trust relationship". Adding a client will just create a user in OpenDJ (which is not necessarily a gluuUser with a profile) with the credentials to read LDAP. You might add dialogues for more granular LDAP access of that user.

Pro: more intuitive. "legacy" applications are more easily identifiable for auditing purposes. Con: takes significantly more work, and probably not good for a point release.

[yurem]

I offer to combine 2 and 3 points. In next release we can add new base RDN like: ou=ldap_users,o=gluu And allow users from this group read/write access to LDAP. We need to do this first before adding GUI or order to make sure that it's working approach. And there is no hidden problems.

On next step we can add GUI which you described in point #3 to allow user permissions.

[madumlao]

@yurem, that's a very flexible and forward compatible approach. Existing deployments can add that LDAP base and any LDAP users moving forward without interfering with their current user database. Then come the time for the update, they may export their existing ldap users to the new tree as needed.

Perhaps we should advise existing users to replace their ACI of

ds-cfg-global-aci: (targetattr!="userPassword||authPassword||changes||changeNumber||changeType||changeTime||targetDN||newRDN||newSuperior||deleteOldRDN||targetEntryUUID||changeInitiatorsName||changeLogCookie||includedAttributes")(version 3.0; acl "Anonymous read access"; allow (read,search,compare) userdn="ldap:///anyone";)

with this

ds-cfg-global-aci: (targetfilter="objectClass=gluuPerson")(targetattr!="userPassword||authPassword||changes||changeNumber||changeType||changeTime||targetDN||newRDN||newSuperior||deleteOldRDN||targetEntryUUID||changeInitiatorsName||changeLogCookie||includedAttributes")(version 3.0; acl "Authenticated read access"; allow (read,search,compare) userdn="ldap:///ou=ldapUsers,o=ORGANIZATION_INUM,o=gluu??sub?(objectClass=gluuLdapUser)"; allow(read,search,compare) userdn="ldap:///self";)

EDIT: changed ACI subject of suggestion from gluuPerson to gluuLdapUser

[yurem]

@madumlao thank you for your help with this. I like this approach. I'm going to reassign this issue to @ganesh-at-wiw he worked on initial support issue: increase-default-opendj-aci-security-2517 He should add: 1) new ldif with this new user definition and load it during setup. 2) add additional ds-config call to apply rule which you offer to use.

Also I offer to add new additional empty ObjectClass for users under: ou=ldapUsers,o=ORGANIZATION_INUM,o=gluu We will use this new OC to add more attributes later.

[nynymike]

1. We discourage use of the LDAP by applications other than the Gluu Server
2. Root DN's bypass aci, search limits and other user constraints.
3. If you wanted to create a seperate Root DN account, the right place to do so would be under cn=Root DNs,cn=config
4. If you want to add other system users (non-root), then you can make a different ou under cn=config. System account should not go in the data (i.e. under o=gluu)

Net-net, I'm not a big fan of this change.

[madumlao]

I'd also prefer to not have to support LDAP, Mike. But LDAP supported by a lot more legacy apps than OIC or SAML and not all of these we can change.

My opinion is, if you don't show users a limited, tightened up interface for ldap accounts, they are just going to end up deploying it wide open to work with their existing apps just because it's convenient. Might as well be explicit as to what their limits are early on, even if the solution ends up being "just deploy a readonly LDAP replication server of objectClass=gluuUsers". But even then you'd need to tighten up the security of that, and IMO is a more complicated / brittle solution than @yurem's approach.

Anyways, I don't think you want to create additional Root DNs, just users that have similar privileges to OIC/SAML client applications (basically, access to user info). And even then you still need to tighten up the directory access because all users have access to the whole directory and community-edition-setup's templates does not bind on localhost only, but on the public IP.

[yurem]

@Zico, is OpenLDAP requires this fix?

[mzico]

@madumlao : Would you mind to give a shot with our latest 3.x servers, OpenLDAP is included there. If you think we need to apply this settings in OpenLDAP, let us know please.