The current 'Rule based" Authorization plugin dates back to 2015 (

Jira
server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key SOLR-7692

). At that time in 5.x Solr was transitioning from a security posture of "don't let anyone you don't trust make requests to Solr" to "We will support authentication and authorization". Solr sorely needed an authorization implementation that it cold ship and for over a decade the Rule Based Authorization Framework has filled that need. However, over the last decade some of the shortcomings of that implementation have become clear.

Rule Based Design

Note: This is based on Jason's excellent talk at Activate 2019, we need to identify to what extent the tweaks to the code may have changed/violated this, but it generally represents the underlying design

• Allow by default
• Permissions have roles 
• Users have roles
• Requests imply a single permission
• If no permission matched the request or the request-required permission specifies a role that the user has, all code implied by the request may be executed.

Shortcomings

• It follows an "Allow by Default" model - This means that anything we fail to check is allowed and any misconfiguration is a leak. Most modern systems take a "Deny by Default" approach and thus a user that is less than thorough, or is approaching our system with habits developed on other systems is at risk of leaving gaping holes in their authorizations scheme. Since we allow by default these holes can only be detected by extensive negative/penetration testing. If we deny by default, anything inadvertently omitted will be detected as users unable to perform the unexpected action (and thus naturally be investigated as a bug in the system that Solr is supporting).
• The permissions that the system relies upon are arbitrary strings, often relating to CRUD aspects of various features, but also allowing arbitrary naming. Permission names are essentially a free-for all. org.apache.solr.security.PermissionNameProvider.Name already shows some permissions with a CRUD component but no functionality, and the 'health' permission lacks the expected 'read' qualifier. Code that wants to reason on things like "read only" are forced into enumeration of every possible read permission and a human needs to determine  which ones are "read" at the time of implementation (and this has to be maintained as the code changes) 
• The logic for resolving access takes the very unusual perspective of attempting to match permissions to requests. Typically in most systems a permission is something needed to execute a block of code, regardless of what request was used to reach that code. Our rule based system however tries to decide which permissions relate to the request, meaning that the set of permissions considered is dependent upon the request. In turn that means reaching code via an unexpected request may not be handled properly (this interacts badly with the fact that we allow by default)
• Solr resolves the request to a single permission, meaning that some seemingly applicable permissions may be ignored.
• Solr considers permissions in an invisible "specificity" based order. This means that the user attempting to configure authorization must fully understand permission specificity and apply that to the entire set of permissions in their head to understand how the configuration will be applied by the system. Most users expect permissions to be applied in a linear fashion (first one wins) and mistakes are therefore very easy to make.
• In addition to the specificity order, the system applies admin permissions entirely separately from collection oriented permissions, adding even more "code that the user must run in their head"
• Solr will start up (or continue running) with a broken security.json, and given the above complexity, a single mistake can lock or unlock features when it's failure to match now falls through to some other permission (or none).

More Common: User>Role>Permission Design 

By way of contrast the following is a more common design for authorization of user activities in applications

• Deny by Default
• Users have roles
• Roles have permissions
• Code requires permission
• When the code is reached, the user's roles are expanded to a list of permissions and if the role imply the required permission the code executes

Benefits of User>Role>Permission

• Permissions are checked at the point of code execution regardless of the path that lead there - lower maintenance burdent
• Permissions typically checked in iteration order - easy to understand
• No complex resolution or path matching logic to account for while designing an authorization scheme.

Conclusion

The current system can  secure Solr, if the author of the security configuration is careful, and maintainers are diligent about not providing alternate request paths to dangerous code but it's a major departure from the way most users expect security systems to work, and the benefits of this departure are unclear.

Status 

Current state: Under Discussion

Discussion thread: here (<- link to https://lists.apache.org/list.html?dev@solr.apache.org)

JIRA: here (<- link to https://issues.apache.org/jira/browse/SOLR-XXXX)

Released: <Solr Version>

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast). Confluence supports inline comments that can also be used.

Motivation

Security that is difficult to understand or implement is security that will be unused, or worse yet used with a false sense of safety. The goal is to provide a new alternative that is

Public Interfaces

Coming Soon

Proposed Changes

Work In Progress 

Add a new plugin based on Apache Shiro that is

• Deny by default
• Composed of structured permissions such as GET:select:myCollection 
• Support wildcard permissions such as GET:*:myCollection to perform any GET operation on a collection or GET:select:* to query any collection.
• Resolve permissions in iteration order and display this order in API or UI representations.
• Short circuit on first allow
• Follows the traditional design of roles implying permissions, and code requiring permissions regardless of how the code was reached.
• Supported by our project.

More details to come example permissions above subject to change, possibly 4 sections, or different sections.

Additionally Solr should refuse all requests if the security.json fails to parse, or is otherwise broken. We need to take the position that a breach is far worse than downtime, because once data is exposed on the internet, it can NEVER be hidden again.

Sun-setting the existing rule based system can happen if this plugin is well adopted, but need not be tied to this implementation.

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?
  • Broken security.json will disable the server until it is fixed. Users will want to verify that they are not getting errors in the logs regarding security.json before upgrading, and back up known good copies of security.json before updating it in zookeeper.
• If we are changing behavior how will we phase out the older behavior?
  • n/a
• If we need special migration tools, describe them here.
  • none
• When will we remove the existing behavior?
  • Perhaps in a future version, tbd

Security considerations

This will likely involve careful review of our plugin architecture and possibly some tweaking of existing code where it hard-codes dependence on the existing rule based system to make such code more pluggable. 

Test Plan

Describe in few sentences how the SIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

Apache Ranger

There is an Apache Ranger plugin for Solr,  but it only supports 8.x and has now fallen 2 major releases behind.

Apache Sentry

The Apache Sentry project was moved to the attic in 2021

Path-Based or URL-Based Authorization

Path based authorization is reasonable for static web sites full of pages because they are fundamentally tree structures and URL based authorization is viable for simple REST apis providing data access without significant logical processing. Systems with significant logic that were designed from the start to use path or url based auth schemes can also work, but Solr spent 4 major versions being developed and enhanced with zero thought for authorization, and there are often many way to run the same code, so any URL based approach will be fraught with peril at this point.