• Shortcut InChain 'member' and 'memberof' into a use of 'memberof' attribute looks a very nice idea. Documentation should warn that InChain 'member' relies on 'memberof' properly updated (risk of enable/disable memberof plugin)
Yep - we already have that data, so we can rely on it and use it. I think we should change memberOf to enabled by default TBH.
Updating the design with your feedback I am facing a difficulty. There is a kind of agreement that a search like '(member:1.2.840.113556.1.4.1941:=uid=foo,dc=com)' that computes all groups 'foo' is memberof, should shortcut the membership computation to use 'memberof' value that is in 'foo' entry.
My concern is related to access control. Let assume we have
dn: G0 member: G1
dn: G1 member: G2
dn: G2 member: foo
dn: foo memberof: G0 memberof: G1 memberof: G2
Then ACI definition, allows (to the inChain bound user) read/search access to
• 'memberof' on 'foo' • 'member' on G2 and G0 but not on G1. InChain MR computation will retrieve G2 (because of access granted on G2.member), then will not retrieve G1 (because of lack of rights to access to G1.member) and so not retrieve G0. => returns 'G2'
Shortcut InChain MR, retrieve G0, G1 and G2 (because of access granted to foo.memberof). If it returns G0, G1, G2 it violates lack of access to G1. If it tests access of 'member' on G0, G1, G2. It may return G0 and G2 (because access is granted) but it violates the fact that G0 was hidden behind G1. So even if the 'member' are pre-computed, we still have to access (srch) each of the member value to evaluate rights and also to create a graph of the membership to detect "hidden" entries. In clear I am unsure of the benefit of the shortcut
The benefit is "not wrecking server performance".
Even in freeipa, memberOf is not hidden ... I can't think of any situation where it is hidden ...
Today, the inverse risk exists. You can't read member from group hidden, but you can see user X is memberof: hidden. But we don't seem to worry about "that" for access controls.
Or even nsRoles? We also don't seem to worry about dynamic groups for that. Or cos templates. Or many of the other ways we generate attributes .... There is ALWAYS a trade here of exposing infomation via a generated attribute that a user otherwise couldn't ask for
If someone truly was "that worried" about access to this attribute they need to disable memberOf and this inchain control.
any thoughts.
best regards thierry
-- Sincerely,
William Brown
Sesion Software Engineer, Identity and Access Management SUSE Labs, Australia