lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hrishikesh Gadre (JIRA)" <>
Subject [jira] [Commented] (SOLR-10814) Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication
Date Tue, 08 Aug 2017 20:21:00 GMT


Hrishikesh Gadre commented on SOLR-10814:

Thanks [~noble.paul] and [~bosco] for your feedback!

I have updated the pull request based on our discussion:

BTW I found that SecurityConfHandler in Solr does not support configuring top-level elements
of the security.json file. Users are expected to upload the security.json file manually to
Zookeeper. Once this is done, the individual authentication/authorization plugins can edit
their own configuration via Solr HTTP APIs. Hence I think the ability to update this flag
(as well as initial configuration of plugins) via HTTP API should be handled as part of a
separate jira. Does that make sense?

[~noble.paul] [~anshumg] Please include this fix in the Solr 7.0 branch as it will simplify
the Solr/Sentry integration. 

> Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication
> ---------------------------------------------------------------------------------------
>                 Key: SOLR-10814
>                 URL:
>             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
class. The RuleBasedAuthorizationPlugin implementation invokes getName() method on the Principal
instance to fetch the list of associated roles.
> 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 foo@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 foo@EXAMPLE.COM instead of foo. This is not good from usability perspective.   

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message