Hi,
This one came in as a request from the community;
https://java.net/jira/browse/SERVLET_SPEC-157 and corresponding JSR 375
issue:
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-39
It's part of the authorization epic which we haven't actually started with
(our pace is unfortunately a bit low it seems)
The request concerns dynamically (programmatically) adding web resource
constraints (resulting in permissions).
An obvious implementation of this would be based on JACC, which provides
all machinery for this already. See e.g. this:
http://arjan-tijms.omnifaces.org/2015/04/how-java-ee-translates-webxml.html
In short, JACC builds up a collection of permissions based on the
constraints expressed in web.xml and via the corresponding annotations.
This collection is currently internal to the so-called JACC provider.
Compatible Servlet implementations consult the JACC provider every time a
resource access decisions needs to be made. Therefor, as JSR 375 we "only"
have to install our own JACC provider and provide a standard API to update
this internal collection. I have already written the code for a basic JACC
provider and can donate this to Soteria so we have something to start with.
The problem however is that JACC doesn't offer a programmatic SPI to
install such a JACC provider (which e.g. JASPIC does offer for
authentication modules). Lacking such JACC SPI we could alternatively make
this an implementation specific integration issue, meaning that we provide
the JACC code, but then every Java EE vendor that wishes to integrate JSR
375 has do something specific for its server to make it work.
Finally, as you may all have noticed the speed at which we're progressing
is not that high. With the multi-identity store and multi-authentication
mechanism proposals still open for the authentication epic I'm not sure if
we'll still be able to address this at all.
Thoughts?
Kind regards,
Arjan Tijms