[Prototype] Security (AuthN / AuthZ) with Shiro

[peternied]

Description

Here is a prototype of security systems using Apache Shiro. Given the broad scope of security, this isn't meant to cover all scenarios, within this PR is a README-SECURITY.md capturing some of the conclusions and reasonings for this implementation.

Feedback on the following would be most appreciated to help move forward:

• Given the thread basic security context, are there any concerns about a security information being accessible in this way?
• Shiro has a limited feature set (One reason I picked it) - are there any wonderful systems/features we feel we'd be missing out on?
• Open Questions in README-SECURITY.md are the next areas of investigation, are there other areas of functionality we'd like to see more depth in first?
• This prototype has been focused around TransportAction - is there another layer such as TaskExecutors that could provide better utility?

Issues Resolved

• Related to https://github.com/opensearch-project/OpenSearch/issues/3846

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions[bot]]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE :x:
• URL: https://build.ci.opensearch.org/job/gradle-check/1842/
• CommitID: 391210d1dd2a5aad23f69bd4980a3e0cb8197558

[dblock]

Would love to hear from @nknize @hardik-k-shah

[peternied]

I think we should add one more level of abstraction for AuthN/Z to make Shiro switchable out for something else.

@dblock Great callout, this is right around the corner and we can have a discussion with the more representative types.

[github-actions[bot]]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE :x:
• URL: https://build.ci.opensearch.org/job/gradle-check/2495/
• CommitID: 9910592e9248390d27f24360492c8fdd70bea703

[github-actions[bot]]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE :x:
• URL: https://build.ci.opensearch.org/job/gradle-check/2951/
• CommitID: 7a82f87b98c369a999767e0ce7f3209e17e65114

[github-actions[bot]]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE :x:
• URL: https://build.ci.opensearch.org/job/gradle-check/2953/
• CommitID: c693c62332469f0a3b035218fa5601e4efe36e11

[peternied]

I am ignoring Gradle Check (Jenkins)

Just wanted to make it clear, this is a prototype that I don't plan on merging directly so I'm not going to look into these check issues.

[dblock]

I am ignoring Gradle Check (Jenkins)

Just wanted to make it clear, this is a prototype that I don't plan on merging directly so I'm not going to look into these check issues.

Do you think we could turn the prototype into a feature branch and actually try to figure out an experimental way to release this? I think the interfaces could ship in core 3.0 and a particular implementation (eg shiro) could follow as a plug-in.

[peternied]

@dblock I just opened a slimmer PR #4515 that includes a subset of these components. I think we could do this work inside of main instead of a feature branch, since the default implementation would be the noop version. Let me know what you think over there.

[peternied]

Closing this out in favor of work in the feature/identity branch - we will still be incorperating the great feedback as we move forward