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.
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: