[
https://issues.apache.org/jira/browse/SOLR-10814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100832#comment-16100832
]
Hrishikesh Gadre edited comment on SOLR-10814 at 7/25/17 9:42 PM:
------------------------------------------------------------------
[~noble.paul]
bq. If there is a Ranger Authorization plugin, you want them to implement this
flag as well?
AFAIK Ranger plugin does not need this flag (or this fix in general) since they
have already implemented logic to parse Kerberos principal -> short userName.
https://github.com/apache/ranger/blame/16f3dd3c350ac9ea85b157b81ceddfcdb761e128/agents-audit/src/main/java/org/apache/ranger/audit/provider/MiscUtil.java#L560
The concern here is that it "assumes" kerberos authentication. I don't know if
this works for any authentication type other than Kerberos (e.g. basic auth).
bq. The framework is supposed to take care of these things.
I agree. In the hindsight, it was a mistake for Solr authorization framework to
provide java.security.Principal as part of AuthorizationContext (instead of
short userName) since the Principal representation depends upon the type of the
authentication scheme.
bq. All authentication plugins should extend the AuthenticationPlugin class.
So, it should decide what details it should return. This has nothing to do with
what underlying authentication is used.
How would we do that? By overriding getUserPrincipal() method in the
HttpServletRequest class ? I would be concerned with that. Since
getUserPrincipal() is a public method and can be used by downstream components
(e.g. custom request handlers, plugins etc.), this would be a backwards
incompatible change.
A safer alternative may be to let authorization framework handle this global
flag and return short username (or user principal) accordingly.
https://github.com/apache/lucene-solr/blob/10875143b2eb4c6cd72c7a93e657833444498b66/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L1034
{code:theme=FadeToGrey|linenumbers=true|language=java|firstline=0001|collapse=true}
@Override
public Principal getUserPrincipal() {
if (Boolean.getBoolean("solr.authorization.useShortName") {
return new BasicUserPrincipal(getReq().getRemoteUser());
}
return getReq().getUserPrincipal();
}
{code}
was (Author: hgadre):
[~noble.paul]
bq. If there is a Ranger Authorization plugin, you want them to implement this
flag as well?
AFAIK Ranger plugin does not need this flag (or this fix in general) since they
have already implemented logic to parse Kerberos principal -> short userName.
https://github.com/apache/ranger/blame/16f3dd3c350ac9ea85b157b81ceddfcdb761e128/agents-audit/src/main/java/org/apache/ranger/audit/provider/MiscUtil.java#L560
The concern here is that it "assumes" kerberos authentication. I don't know if
this works for any authentication type other than Kerberos (e.g. basic auth).
bq. The framework is supposed to take care of these things.
I agree. In the hindsight, it was a mistake for Solr authorization framework to
provide java.security.Principal as part of AuthorizationContext (instead of
short userName) since the Principal representation depends upon the type of the
authentication scheme.
bq. All authentication plugins should extend the AuthenticationPlugin class.
So, it should decide what details it should return. This has nothing to do with
what underlying authentication is used.
How would we do that? By overriding getUserPrincipal() method in the
HttpServletRequest class ? I would be concerned with that. Since this is a
public method and can be used by downstream components (e.g. custom request
handlers, plugins etc.), this would be a backwards incompatible change.
A safer alternative may be to let authorization framework handle this global
flag and return short username (or user principal) accordingly.
https://github.com/apache/lucene-solr/blob/10875143b2eb4c6cd72c7a93e657833444498b66/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L1034
{code:theme=FadeToGrey|linenumbers=true|language=java|firstline=0001|collapse=true}
@Override
public Principal getUserPrincipal() {
if (Boolean.getBoolean("solr.authorization.useShortName") {
return new BasicUserPrincipal(getReq().getRemoteUser());
}
return getReq().getUserPrincipal();
}
{code}
> 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 f...@example.com. This means if the user changes the authentication
> mechanism, he would also need to change the user-role mapping in
> authorization section to use f...@example.com instead of foo. This is not
> good from usability perspective.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
