>
>
>> • 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