Hi Arjan,
Thanks again for the great work you are doing in moving things forward here!
We should try to address
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-39 even with the progress
we're having...
But I think that, it is more important to standardize the annotation-based
approach so that it is possible to to like this:
@ServletSecurity(@HttpConstraint(rolesAllowed = "foo"))
for applications that are not based on Servlet, such as MVC 1.0
applications.
Ivar
On Sat, Jul 2, 2016 at 11:50 PM arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>
>
>