On Sat, 2016-11-19 at 08:29 +0000, msarmadi@xxxxxxxxxxxxxx wrote: > Thank you for the reply > > Please take a look at https://fedorahosted.org/389/ticket/49036 > I tried to be descriptive and explaining an environment from a point of view > It might help me explain better. > > By Users, I'm referring to End Users which can use applications - those they are permitted. And I should say that an application checks user's authentication credentials by binding to the directory using them. > > The expected behaviour is: there be a mechanism where I could place a Rule that userA(DN corresponding to End UserA) can bind to directory only from App1 and not App2 (based on his manager's request). > I think, that mechanism must be an ACI Like behaviour in which bind operation(initiated by an application software, say App1) for a user(User DN corresponding to, say, UserA) could be controller by IP (if UserA is allowed to user App1, App1(from IP1) can bind using UserDN of UserA), and if not it should be defined as Deny Rule. > Moreover, having that mechanism, like what is doable in directory ACI on other operations(read,write,search,...), we could expect more mature constraints, e.g. time, a certain user attribute, etc. > > Please let me know what sort of other details could help? or what can I explain. > 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* from an IP address. 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: '(&(uid=%s)(memberOf=cn=Application-A,...))' Application B: '(&(uid=%s)(memberOf=cn=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: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10.1/html/Administration_Guide/Advanced_Entry_Management.html#Advanced_Entry_Management-Using_Groups https://fy.blackhats.net.au/blog/html/2016/05/25/acis_for_group_creation_and_delegataion_in_ds.html PS: I'm copying this text to the ticket also. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
