[ 
https://issues.apache.org/jira/browse/SOLR-10814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob resolved SOLR-10814.
------------------------------
    Fix Version/s: master (9.0)
         Assignee: Mike Drob
       Resolution: Fixed

[~noble.paul] - responding to your question on the PR - the public touch points 
are covered in the ref guide. If the example there is insufficient, please let 
me know.

> 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
>    Affects Versions: 6.2
>            Reporter: Hrishikesh Gadre
>            Assignee: Mike Drob
>            Priority: Major
>             Fix For: master (9.0)
>
>         Attachments: SOLR-10814.patch
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to