----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/56179/#review163965 -----------------------------------------------------------
In my past experience if a service runs on multiple hosts in kerberised environment each service has its own principal. e.g service_name/host1@realm, service_name/host2@realm etc. As these are separate principals authorisation should be granted for each principal separately even though it's the same service. E.g service running on host1 is considered to be secure as host1 is in a trusted domain thus for the service which identifies itself as service/host1@realm more permissions can be granted. If the service is running on host2 which is in an untrusted domain than for the service which identifies itself as service/host2@realm only limited permission is given. Authorisation enforced based only on the service name and not the fully qualified principal could lead to security breach. - Sebastian Toader On Feb. 1, 2017, 9:46 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, 9:46 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 > >
