Hi,
HttpServlet has a 1:1 mapping for HTTP methods. One could of course
override the service method and change its behaviour. Are you referring to
that?
I'd personally see the @RolesAllowed annotation a more convenient way of
configuring security than the current @ServletSecurity annotation. One
could also annotate the service() method in order to restrict the whole
servlet.
If I'm not mistaken, MVC controllers will already be CDI beans, so
interceptors would work on them. The spec could simply enable the
@RolesAllowed declaration on all CDI managed beans. Then, if (when) JAX-RS
resources becomes beans, they will be already covered. Until that, one
could already annotate resources with @RequestScoped or @Stateless to
achieve the same behaviour. Specific wording may be needed in order to
acommodate to each different component (Servlet, EJB, JAX-RS), but
basically it will fallback to the HttpServletRequest in everything that's
nothing more that a CDI bean.
Regards,
Guillermo González de Agüero.
On Sun, Jul 3, 2016 at 9:51 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>>>
>>>
>>>