I personally prefer the provider-param-per-virtual-group concept over the one param for all group mappings approach. I think it is more readable and easier to modify with less potential for error. However, we should thoroughly think through any implications this choice may have for Knox deployments.
I also like the prefix notation for describing the virtual group associations, whether they are specified in one or numerous params. On Tue, Feb 8, 2022 at 6:47 AM Attila Magyar <[email protected]> wrote: > 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> > ------------------------------ >
