On Sat, 2016-11-19 at 08:29 +0000, msarmadi(a)arissystem.com 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...
https://fy.blackhats.net.au/blog/html/2016/05/25/acis_for_group_creation_...
PS: I'm copying this text to the ticket also.
--
Sincerely,
William Brown
Software Engineer
Red Hat, Brisbane