> On Feb. 1, 2017, 8 p.m., Robert Nettleton wrote: > > ambari-logsearch/ambari-infra-solr-plugin/src/main/java/org.apache.ambari.infra.security/InfraRuleBasedAuthorizationPlugin.java, > > line 63 > > <https://reviews.apache.org/r/56179/diff/1/?file=1621369#file1621369line63> > > > > Would there be any cases in the future where we might want to make this > > a pluggable strategy? > > > > This current implementation is fine, but I was just wondering if it > > would be worth the effort to abstract out this operation into an interface, > > and have the plugin class only handle that. > > > > If Solr doesn't provide a way to configure the creation of this plugin > > instance, then perhaps this wouldn't be helpful anyway. > > > > I'm not opening this as an issue, rather I'm just trying to see if this > > can be more flexible. If there's no benefit to abstracting out the > > operation, then this code should stay as-is.
1. we still not have ambari-infra module (which would be good idea just the assembly module needs to be splitted, therefore it would be some change on release eng side ... keeping the code in a different project means more change there as well), we build solr rpm/deb in logseaerch assembly module, so for now, the plugin is in "right" place (i put that jar into the rpm/deb mappings). 2. the original file uses apache license, also i mentioed in the javadoc, that is a modified copy of the file. 3. i tried to just extend the real RuleBasedAuthoizationPlugin, but in the end i should almost implement everything, so it would be better to just copy the whole file with a small change. 4. I do not think we should create that strategy pluggable, the reason is why i created that is mainly because then we can see what is the difference between that and a real one. adding pluggable options would be better in the real code itself, but i thhink that is more like a Bug in Solr (with Kerberos). - Oliver ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/56179/#review163860 ----------------------------------------------------------- On Feb. 1, 2017, 5:16 p.m., Oliver Szabo wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/56179/ > ----------------------------------------------------------- > > (Updated Feb. 1, 2017, 5:16 p.m.) > > > Review request for Ambari, Miklos Gergely, Robert Nettleton, and Sebastian > Toader. > > > Bugs: AMBARI-19822 > https://issues.apache.org/jira/browse/AMBARI-19822 > > > Repository: ambari > > > Description > ------- > > Problem: > If an ambari cluster is secured and kerberos authentication is used for Solr, > we need (default) authorizations as well to make sure only the specific > service users (ranger, atlas, logsearch) can access their collections (and > solr user as well) > > Solution: > Although RuleBasedAuthorizationPlugin seems to be a good solution here, to > map default users to default permissions, unfortunately, permissions and > roles using principal name for mapping (not username) from the authentication > tokens. Also Solr name rules applied on the username and not on the > principal, therefore we need the fully qualified hostname as well in the > role-permission mapping. In order to avoid that issue, I added an own plugin > (org.apache.ambari.infra.security.InfraRuleBasedAuthorizationPlugin), to map > users with <name>@<DOMAIN> format. > > to problem is in here in RuleBasedAuthorizationPlugin.java: > https://github.com/apache/lucene-solr/blob/releases/lucene-solr/5.5.2/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L153 > > notice that InfraRuleBasedAuthorizationPlugin is only a copy of that file > (InfraUserRolesLookupStrategy class which I added and included in the new > plugin class) > > > Diffs > ----- > > ambari-logsearch/ambari-infra-solr-plugin/pom.xml PRE-CREATION > > ambari-logsearch/ambari-infra-solr-plugin/src/main/java/org.apache.ambari.infra.security/InfraRuleBasedAuthorizationPlugin.java > PRE-CREATION > > ambari-logsearch/ambari-infra-solr-plugin/src/main/java/org.apache.ambari.infra.security/InfraUserRolesLookupStrategy.java > PRE-CREATION > > ambari-logsearch/ambari-infra-solr-plugin/src/test/java/org/apache/ambari/infra/security/InfraRuleBasedAuthorizationPluginTest.java > PRE-CREATION > > ambari-logsearch/ambari-infra-solr-plugin/src/test/java/org/apache/ambari/infra/security/InfraUserRolesLookupStrategyTest.java > PRE-CREATION > ambari-logsearch/ambari-logsearch-assembly/pom.xml c486050 > ambari-logsearch/pom.xml 7aeb4a7 > > ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/package/scripts/params.py > 526baea > > ambari-server/src/main/resources/common-services/AMBARI_INFRA/0.1.0/properties/infra-solr-security.json.j2 > d8aea24 > > Diff: https://reviews.apache.org/r/56179/diff/ > > > Testing > ------- > > unit tests done, behavior validated with unit tests. other tests (FT) with > using ranger and atlas are in progress... > > > Thanks, > > Oliver Szabo > >
