Agreed, I think these are some great suggestions. Couple things to consider:
1. management app abilities to add individual params per mapping - think Ambari and CM 2. parsing complexity - I found the splitting on ORs simplified what be needed to be done there 3. whether we need to front load simple cases to meet some specific needs On Tue, Feb 8, 2022 at 8:57 AM Phil Zampino <[email protected]> wrote: > 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> > > ------------------------------ > > >
