[
https://issues.apache.org/jira/browse/SOLR-10814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117059#comment-16117059
]
Hrishikesh Gadre commented on SOLR-10814:
-----------------------------------------
bq. What I meant was, all existing code will continue using getPrincipal(). And
for anyone writing new authorization plugin, they can use either of the two
methods. Those who want to keep to play it safe, can use getShortName() and not
worry about the underlying authentication mode. And those who want to do
additional processing then can use getPrincipal().
[~bosco] Thanks for your feedback. I think it make sense. I would prefer to use
short userName for Sentry plugin (instead of requiring some special
configuration from user).
[~noble.paul] it looks like Apache Ranger and Sentry plugins would not need
special flag if the short username is exposed via AuthorizationContext. But as
you said RuleBasedAuthorizationPlugin (and other third-party implementations)
may benefit from a global flag. After thinking about it, I am not sure if we
can have one solution which would benefit all plugins.
So I suggest following approach,
* Expose short userName via AuthorizationContext. This will allow new plugin
implementations to work without any special configuration.
* Add a parameter in security.json which can define the result of the
AuthorizationContext#getPrincipal() API (i.e. a fully qualified principal name
vs short userName). This will allow RuleBasedAuthorization plugin as well as
other third party implementations to work without any changes. (Note - user
will need to set this parameter for that though).
Does that make sense?
> 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.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
