[
https://issues.apache.org/jira/browse/SOLR-10814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16041860#comment-16041860
]
Hrishikesh Gadre edited comment on SOLR-10814 at 6/7/17 11:23 PM:
------------------------------------------------------------------
[~ichattopadhyaya]
bq. Also, this is a significant backcompat break for kerberos+authorization
setups that would prevent them from upgrading.
bq. How about using the getUserPrincipal or getUserName based on some
configuration / property? That is, if someone wants to setup Solr for a variety
of authentication mechanisms, he could enable some configuration property after
which the getUserName() would be used instead of getPrincipal (or other way
around)?
I agree. We can make this behavior *configurable* for
RuleBasedAuthorizationPlugin
bq. Also, I don't think dropping the realm is a good idea for an organization
that has setup cross realm authorization. Imagine that ishan@REALM1 and
ishan@REALM2 maybe completely different users.
I disagree. We are not dropping the RELM from the principal name. The kerberos
authentication plugin applies a set of "kerberos name rules" to the
authenticated principal and uses the result as the "short user name". Hence it
is possible for the system administrators to tweak the output of this process
by modifying the kerberos name rules parameter. Here are few pointers for more
details,
https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.1/doc/krb5-admin/realms--krb5.conf-.html
https://www.cloudera.com/documentation/enterprise/latest/topics/cdh_sg_kerbprin_to_sn.html
bq. However, I don't think we should deprecate getUserPrincipal() in
AuthorizationContext, since many admins who only want kerberos would prefer to
keep the realm in their authorization configurations.
I disagree. This is not just restricted to RuleBasedAuthorizationPlugin, but it
applies to all future implementations of AuthorizationPlugin (e.g.
SENTRY-1475). Specifically - if AuthorizationContext provides both
user_principal and user_name, which of these should be used by the plugin
implementation?
I know that Apache Sentry *always* uses short user name for configuring
permissions (even when kerberos is used).
I found that Apache Ranger is converting the kerberos principal to the short
username as part of the authorization plugin implementation,
https://github.com/apache/ranger/blob/16f3dd3c350ac9ea85b157b81ceddfcdb761e128/plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java#L170
The problem I have with this implementation in Apache Ranger is that the
details of authentication mechanism are spilling into the authorization logic.
e.g. take a look at following comment,
https://github.com/apache/ranger/blame/16f3dd3c350ac9ea85b157b81ceddfcdb761e128/agents-audit/src/main/java/org/apache/ranger/audit/provider/MiscUtil.java#L560
Ideally I would expect the authorization plugin to deal with just short user
names and be completely agnostic of underlying authentication mechanism.
So to summarize - here is my proposal,
* I agree that we need to be backwards compatible with respect to
RuleBasedAuthorizationPlugin. Hence we should make the switch from principal
name to user_name configurable.
* I don't agree with the rationale of not deprecating getUserPrincipal(). Most
of the role based authorization solutions are using short user names. Hence if
we deprecate getUserPrincipal() for Solr 7.0 (and/or 6.x), we can wait until
8.0 to clean this up. That will provide sufficient time for the administrators
to migrate their authorization settings to user short user-names.
Please let me know your thoughts.
was (Author: hgadre):
[~ichattopadhyaya]
bq. Also, this is a significant backcompat break for kerberos+authorization
setups that would prevent them from upgrading.
bq. How about using the getUserPrincipal or getUserName based on some
configuration / property? That is, if someone wants to setup Solr for a variety
of authentication mechanisms, he could enable some configuration property after
which the getUserName() would be used instead of getPrincipal (or other way
around)?
I agree. We can make this behavior *configurable* for
RuleBasedAuthorizationPlugin
bq. Also, I don't think dropping the realm is a good idea for an organization
that has setup cross realm authorization. Imagine that ishan@REALM1 and
ishan@REALM2 maybe completely different users.
I disagree. We are not dropping the RELM from the principal name. The kerberos
authentication plugin applies a set of "kerberos name rules" to the
authenticated principal and uses the result as the "short user name". Hence it
is possible for the system administrators to tweak the output of this process
by modifying the kerberos name rules parameter. Here are few pointers for more
details,
https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.1/doc/krb5-admin/realms--krb5.conf-.html
https://www.cloudera.com/documentation/enterprise/latest/topics/cdh_sg_kerbprin_to_sn.html
bq. However, I don't think we should deprecate getUserPrincipal() in
AuthorizationContext, since many admins who only want kerberos would prefer to
keep the realm in their authorization configurations.
I disagree. This is not just restricted to RuleBasedAuthorizationPlugin, but it
applies to all future implementations of AuthorizationPlugin (e.g.
SENTRY-1475). Specifically - if AuthorizationContext provides both
user_principal and user_name, which of these should be used by the plugin
implementation?
I know that Apache Sentry *always* users short user name for configuring
permissions (even when kerberos is used).
I found that Apache Ranger is converting the kerberos principal to the short
username as part of the authorization plugin implementation,
https://github.com/apache/ranger/blob/16f3dd3c350ac9ea85b157b81ceddfcdb761e128/plugin-solr/src/main/java/org/apache/ranger/authorization/solr/authorizer/RangerSolrAuthorizer.java#L170
The problem I have with this implementation in Apache Ranger is that the
details of authentication mechanism are spilling into the authorization logic.
e.g. take a look at following comment,
https://github.com/apache/ranger/blame/16f3dd3c350ac9ea85b157b81ceddfcdb761e128/agents-audit/src/main/java/org/apache/ranger/audit/provider/MiscUtil.java#L560
Ideally I would expect the authorization plugin to deal with just short user
names and be completely agnostic of underlying authentication mechanism.
So to summarize - here is my proposal,
* I agree that we need to be backwards compatible with respect to
RuleBasedAuthorizationPlugin. Hence we should make the switch from principal
name to user_name configurable.
* I don't agree with the rationale of not deprecating getUserPrincipal(). Most
of the role based authorization solutions are using short user names. Hence if
we deprecate getUserPrincipal() for Solr 7.0 (and/or 6.x), we can wait until
8.0 to clean this up. That will provide sufficient time for the administrators
to migrate their authorization settings to user short user-names.
Please let me know your thoughts.
> Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos
> authentication
> ---------------------------------------------------------------------------------------
>
> Key: SOLR-10814
> URL: https://issues.apache.org/jira/browse/SOLR-10814
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.2
> Reporter: Hrishikesh Gadre
>
> Solr allows configuring roles to control user access to the system. This is
> accomplished through rule-based permission definitions which are assigned to
> users.
> The authorization framework in Solr passes the information about the request
> (to be authorized) using an instance of AuthorizationContext class. Currently
> the only way to extract authenticated user is via getUserPrincipal() method
> which returns an instance of java.security.Principal class. The
> RuleBasedAuthorizationPlugin implementation invokes getName() method on the
> Principal instance to fetch the list of associated roles.
> https://github.com/apache/lucene-solr/blob/2271e73e763b17f971731f6f69d6ffe46c40b944/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L156
> In case of basic authentication mechanism, the principal is the userName.
> Hence it works fine. But in case of kerberos authentication, the user
> principal also contains the RELM information e.g. instead of foo, it would
> return [email protected]. This means if the user changes the authentication
> mechanism, he would also need to change the user-role mapping in
> authorization section to use [email protected] instead of foo. This is not
> good from usability perspective.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
