I find this part a little bit difficult to read.
<param>
<name>virtual.group.mapping</name>
<value>user:lmccay,pzampino=datalake-admin||group:admin&&group:datalake=datalake-admin</value>
</param>
Maybe it would be simpler if we put the virtual group name into the
property param name:
<param>
<name>virtual.group.mapping.datalake-admin</name>
<value>user:lmccay,pzampino||group:admin&&group:datalake</value>
</param>
This way the value only contains the predicate while the virtual group name
comes from the property name.
If we want to support arbitrary logical expressions, we should consider
using prefix or postfix notation instead of infix. With infix we need to
deal with operator precedences and parentheses. Parsing logic can be
significantly simpler with pre- and postfix notation.
LDAP search filters
<https://confluence.atlassian.com/kb/how-to-write-ldap-search-filters-792496933.html>
also use prefix notation so users might be already familiar with that.
With prefix notation the above example would look something like this:
<param>
<name>virtual.group.mapping.datalake-admin</name>
<value>(or (and group:admin group:datalake)
user:lmccay,pzampino)</value>
</param>
Or a more explicit and flexible version would look like this:
(or
(and
(= group "admin")
(= group "datalake"))
(or
(= user "lmccay")
(= user "pzampino")))
You can write it in one line, I just formatted it for ease of readability.
This syntax is unambiguous and trivial to parse and interpret. We don't
need to deal with precedence rules. Plus it allows us to extend the syntax
further with no limitations.
For example:
(or (starts-with "aprefix-" group) (matches "user[0-9]+" user))
This is just a demonstration on language extension, with regexp and string
manipulation support.
Even if we don't need this amount of flexibility I think we should still
consider this because of the low implementation cost.
Postfix notation is even simpler to implement but not widely used so some
users might find it unusual. Other than this it has the same
characteristics as the prefix version.
group "admin" = group "datalake" = and user "lmccay" = user "pzampino" = or
or
Thoughts?
On Sat, Feb 5, 2022 at 7:36 PM larry mccay <[email protected]> wrote:
> All -
>
> I've thrown together a proposal KIP for adding Virtual Group Mapping to
> Knox identity assertion providers. [1]
>
> Being able to create virtual groups based on aspects of the established
> security context, identity, group memberships and attributes from the
> request or other things will enabled a number of new capabilities. Things
> like, more advanced and dynamic authorization policies and acls, custom
> routing, throttling, QoS levels, etc.
>
> Thoughts?
>
> thanks,
>
> --larry
>
>
> 1.
>
> https://cwiki.apache.org/confluence/display/KNOX/KIP-16+-+Virtual+Groups+in+Apache+Knox
>
--
*Attila Magyar* | Staff Software Engineer
cloudera.com <https://www.cloudera.com>
[image: Cloudera] <https://www.cloudera.com/>
[image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
on LinkedIn] <https://www.linkedin.com/company/cloudera>
------------------------------
