Hi,
On Sun, Jul 3, 2016 at 3:20 PM, Guillermo González de Agüero <
z06.guillermo_at_gmail.com> wrote:
> 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?
>
Yes, the Servlet EG back then did extensive research into using
@RolesAllowed for Servlets. They initially had that, but then found out it
couldn't work and reverted it all, and introduced the current ones.
See Shing Wai's explanation here:
https://blogs.oracle.com/swchan/entry/follow_up_on_servlet_3
In short, the problem is with inheritance and the service() method.
We've been looking at this issue a while back, and potentially a CDI-fied
"Servlet" may work here, which would be a true CDI bean with a number of
1:1 methods and no service method, that's called from a bridge regular
Servlet. However getting this prototyped at all and then getting it through
the JCP may no be easy.
Kind regards,
Arjan Tijms
>
> 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
>>>>
>>>>
>>>>
>