[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Dynamic group draft
Haripriya S wrote:
> One of the use-cases of dynamic group is to set a dynamic group as an
> ACL Trustee for a resource. For use in this situation, using the
> user's identity could be a problem with respect to both security and
> consistency. Imagine a case where a deny ACL is set using the dynamic
> group as a trustee with the expectation that the members of the
> dynamic group will match that. Now if the members get limited by the
> user's search rights, then an access could be granted where it should
> have not been. Using a separate identity (eg. dgIdentity) builds
> consistency and predictability into the dynamic group member list.
>
> imho the members of a dynamic group should be based on the intention
> of the administrator - not based on the rights of the user. However
> who can read the dynamic group attributes can be limited by the ACLs
> on the DG object.
Sorry for bothering again, but according to your above answer, it may
appear that you infer a (possibly unrelated and desirable) capability
from the need to work an implementation specific access control data
model around. This would be a poor way to define a potential standard.
I admit your example definitely makes sense, but it relies on a number
of issues that I'd treat as bugs of the underlying implementation,
rather than as advantages for administrators:
- the access data model is based on a grant/deny model, which is
confusing and error prone (if grants and denies have to be explicitated,
it's hard to tell what's the default that's going to apply to what's
left out of grants and denies)
- the access data model could use the operation's identity to perform
information harvesting in a non-consistent manner, so you need to
explicitly force the use of a given identity
- the data consistency and security workaround would defeat the purpose
of a dynamic group
The solution you propose, namely delocalizing access information
otherwise you would incur in limitations because in an implementation
it's based on a localized data model seems to me quite counterintuitive
and prone to further errors. In fact, administrators could be led into
believing that access is governed by local data, while there are items,
like dynamic groups, that can work those rules around.
Also, you state that further access checking on the contents of
dynamically generated membership may prevent disclosure in case of
direct lookups, and that's right, but this means that rules to check
access to dynamically generated data must duplicate data specific rules.
For example:
object A
grant dgIdentity read access
deny all any privilege, including disclose
object B: dynamic group, with query matching object A
grant all read privilege
any user is not even allowed to directly discover the existence of
object A; but object B allows any user to discover that existence.
According to your proposed definition of dynamic group, the dynamic
group would need a rule like
object B: dynamic group, with query matching object A
grant all read privilege
deny all any privilege on object B
thus defeating the purpose of a dynamic group, if per-dynamically
generated value access needs to be specified.
On the contrary, if you allow implementations to differentiate the
identity used for information harvesting based on the usage, access
information can remain localized while preserving access integrity.
The dgIdentity feature you desire, which may be of help to
administrators in other cases as well, could be added as an option (or,
which would be my second choice, data harvesting should be optionally
allowed to be performed with the operation identity).
Cheers, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati@sys-net.it
------------------------------------------
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext