Jan Høydahl commented on SOLR-12131:

{quote}I'm wondering how exactly is this role information sent. Did you say 
that the role information is sent as part of the request itself? what are the 
security implications if you do so? 
The role info is provided as part of the Principal object, typically by an 
Authentication plugin which has already validated the user and roles. There is 
no way for the end user to forge a list of roles as part of the request, since 
the Principal object is filled in either by the servlet container or the 
application (in our case JWTAuthPlugin).

> Authorization plugin support for getting user's roles from the outside
> ----------------------------------------------------------------------
>                 Key: SOLR-12131
>                 URL: https://issues.apache.org/jira/browse/SOLR-12131
>             Project: Solr
>          Issue Type: New Feature
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: security
>            Reporter: Jan Høydahl
>            Assignee: Jan Høydahl
>            Priority: Major
>             Fix For: 7.4, master (8.0)
>          Time Spent: 10m
>  Remaining Estimate: 0h
> Currently the {{RuleBasedAuthorizationPlugin}} relies on explicitly mapping 
> users to roles. However, when users are authenticated by an external Identity 
> service (e.g. JWT as implemented in SOLR-12121), that external service keeps 
> track of the user's roles, and will pass that as a "claim" in the token (JWT).
> In order for Solr to be able to Authorise requests based on those roles, the 
> Authorization plugin should be able to accept (verified) roles from the 
> request instead of explicit mapping.
> Suggested approach is to create a new interface {{VerifiedUserRoles}} and a 
> {{PrincipalWithUserRoles}} which implements the interface. The Authorization 
> plugin can then pull the roles from request. By piggy-backing on the 
> Principal, we have a seamless way to transfer extra external information, and 
> there is also a natural relationship:
> {code:java}
> User Authentication -> Role validation -> Creating a Principal{code}
> I plan to add the interface, the custom Principal class and restructure 
> {{RuleBasedAuthorizationPlugin}} in an abstract base class and two 
> implementations: {{RuleBasedAuthorizationPlugin}} (as today) and a new 
> {{ExternalRoleRuleBasedAuthorizationPlugin.}}

This message was sent by Atlassian JIRA

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

Reply via email to