#49036 Allow Bind Operation on Views
Closed: wontfix a year ago by spichugi. Opened 4 years ago by k38echo.

I'm aware that views are used for search operations. and they cannot be used to bind users in ldap.
I'm looking for a mechanism to restrict bind operation. for example only users with an specific attribute can bind against ldap. and by doing so, limiting every application in my environment to it's own users.
there are several methods for doing such thing now. most of them assume a search operation is done prior to bind, and if a user does not appear in search result the bind wont be done. of course in this method both search filters and ACLs can be used to restrict the search operation. Another approach is using different suffices but for doing so, I must accept redundancy and complexity.

If it was possible to bind a user within a view (see DN below), I could easily control which users are allowed to bind (simply by using the appropriate DN which consists of the right view). it would be a good feature for restricting bind operation without the problems mentioned above.

DN: uid=user1,ou=myview,dc=mydomain,dc=com

Let me state my interpretation:

  • The Environment
    There are multiple ldap clients(software application), say App1, App2, .. AppN. And. Also there are a number of users say 3K. Organization policy says each user can be authenticated in zero or multiple Applications.

  • The requirement
    To Control certain application(recognized by IP Address)-say App1- to be able(or not) to Bind using a certain UserDN(e.g. "uid=user1,ou=People,dc=mydomain,dc=com").

  • More
    Users are categorized based on an attribute filter, e.g nsApp, which is filled per user, based on administrator/organization policy. Say "uid=user1,ou=People,dc=mydomain,dc=com" has its nsApp attribute filled by a Value "App1". So that a nsView(ou=myview,dc=mydomain,dc=com) could be created by "nsViewFilter=(nsApp=App1)" has that user. And so on for other Apps and Users.

  • What I see in the problem
    I see a form of ABAC on Bind Operation to be used in Directory Server. And you are proposing a bind operation on nsView, which could help/be-used in user access control - a form of ACI.
    Another definition of controlling Bind Operation(ACI on Bind), could be Role based (permission are defined on Roles and users are entitled to some roles - instead of user's attribute)

  • Analysis
    We should look what is provided in 389ds/Directory Server.
    . ACI in Directory Server could not control Bind Operations. Bind is always allowed. There are no contraints.
    . By definition, We cannot put a certain user in two different simple OU containers. So that it provide Bind if the user is in a certain OU and prevents it when it is not in that OU. Also a user could only exist in one OU, so
    . There are some dynamic containers(operational,structural) like Dynamic Groups, nsRoles and Directory nsViews(they could be created based on users' Attribute-filters). All of them could categorize/group users bye a certain attribute's value, but they do not support Bind operation. If it was provided each application would have its own View which only contains users are eligible to bind and login from that certain app(e.g. identified by IP)

-- My Opinion about Bind Operation on Views proposal
In my opinion having Bind operation possible on entries in a View(nsView) will be very useful. It could complete virtualization which nsView brings as a container type.

-- Additional Proposal
Moreover, I think having ACI on bind operation is very useful, too. Especially when it has policy like mature features. For example think of ACI's(or other type of rules) which determine and restrict user authentication based on Client IP, UserDN, Time, comparing an arbitrary user attribute with a value, Role or Group Membership, or other possible constraints.

Okay, I believe I understand now.

Based on some "attribute", you wish to allow a user to authenticate to some application A, but not to application B depending on the attribute state.

I want to break this down.

Directory Server is used for providing Authentication and Authorisation.

Authentication is the process of saying "are you really who you claim to be". This is the process of saying "is your password correct" for example.

Authorisation is the process of saying "do you have the permission to use some resource?"

What you are confusing here is you are trying to solve an authorisation problem by disallowing authentication.

This is not the right way to approach this in my experience. My former email is in fact the solution,

You want a user who can always authenticate. But then based on memberShip of a group, you can deny the authorisation to the application.

For example:

uid=user1,ou=People,dc=... is a member of cn=Application-A but is NOT a member of cn=Application-B

Most applications support a "filter" on their LDAP settings. In that filter, you would provide something like:

Application A:

Application B:

When user1, who is a memberOf cn=Application-A went to authenticate to Application A, the filter is run. Because the object would be matched by this filter, the application has now authorised that this user can authenticate to the application.

When user1, who is NOT a memberOf cn=Application-B went to authenticate to Application B, the filter is run. Because user1 would not match the filter, not object is returned. The application knows the user is not authorised for this, and fails to allow the user to login, no matter if their password is correct or not.

This is exactly the behaviour you want!

Another benefit of this, is that there is no way to do secure delegation of an attribute on the user for application permissions. You would have to allow a manager to change all authorisation permissions, or none.

A benefit of users and groups is that the managers can be through ACI's only allowed to edit groups they are responsible for. For example, the finance manager could add users to the finance application group, but could not add users to the linux system administration group!

You can read more about secure group delegation here:



Metadata Update from @msarmadi:
- Issue set to the milestone: FUTURE

4 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Issue close_status updated to: None
- Issue tagged with: RFE

2 years ago

Metadata Update from @mreynolds:
- Issue tagged with: Access Control

a year ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2095

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.