Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for permission stores #296

Open
arjantijms opened this issue Oct 17, 2023 · 0 comments
Open

Add support for permission stores #296

arjantijms opened this issue Oct 17, 2023 · 0 comments
Assignees
Milestone

Comments

@arjantijms
Copy link
Contributor

arjantijms commented Oct 17, 2023

Jakarta EE has supported the concept of a "permission store" for a long time.

A permission store is an entity that stores permissions, typically either globally, or per role (role-based permissions). This entity then performs a business / data operation where a query and an identity go in, and a yes/no answer goes out. For instance, a query such as "can access /foo/bar?" along with the identity for user "John" with roles "bar" and "kaz" would return "yes" if that identity is authorized to access "/foo/bar", and "no" if not authorized.

Examples of permission stores are the Jakarta Authorization usage of the Policy class, or the internal data structure where a Servlet Container such as Tomcat or Jetty stores the security constraints an application defined.

The concept is very powerful, but using the Policy in Jakarta Authorization is not trivial; it has to be installed inside a Jakarta EE server in a server specific way (e.g. in a jar inside say [product folder]/lib) and it's an all or nothing approach; it completely replaces the existing permission logic. See https://arjan-tijms.omnifaces.org/2014/03/implementing-container-authorization-in.html

The goal of the permission store in Jakarta EE is to provide a modernised and easier to use approach; provide an implementation in a simplified way (e.g. like how an identity store or authentication mechanism is provided today in Jakarta Security) and make use of extension points so existing logic can be augmented instead of being completely replaced.

An early prototype of this was developed for Jakarta Security 1.0, but because of resource issues wasn't taken further than this prototype stage.

See

Existing implementations / designs of this concept:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant