Hi,
Basic method level "roles allowed" security for CDI beans and therefore MVC
should be relatively simple. We "only" have to agree on the exact
functionality and names etc. But there are several caveats if you go beyond
the basic case.
JAX-RS is a bit more troublesome as JAX-RS resources are not CDI beans, and
even though they look to be CDI-ish in nature, the fact that they aren't
becomes clear here as they don't support Interceptors.
Servlet security annotations are btw not the simple @RolesAllowed or method
level ones, since in Servlet the http methods (get, post, ...) don't have a
1:1 connection to a Java method. Servlet also has the "problem" that
Servlets are not native CDI beans.
Implementation wise we have to find out the best way to universally check
roles. In a web request we can always grab the HttpServletRequest, but in
EJB we need the SessionContext and in JAX-RS theoretically the JAX-RS
SecurityContext. Here too, actually, JACC already provides this universal
way to check roles. But JACC is not activated by default in every server
(e.g. WebLogic) or the default provider is not even present, even when it
should be (WebSphere, Liberty), or it contains critical bugs (JBoss,
WildFly).
We could also make this universal role check a new unique JSR 375
implementation detail, and require that vendors implement it specifically
for their server. Soteria would then be tied to GlassFish (like Ozark is
actually tied to GlassFish/Jersey). But given the existing options I'd
rather not go that way.
Simplest for now (for a 1.0 release) would be to say that for now we only
support role checking for (http servlet) web requests, and optionally via
JACC.
Kind regards,
Arjan Tijms
On Sunday, July 3, 2016, Ivar Grimstad <ivar.grimstad_at_gmail.com> wrote:
> 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
>>
>>
>>