Hi,
Interesting, specially the annotation inheritance issue... Anyway, I still
see a value in adding support for @RolesAllowed on Servlets. Not as a
replacement for @ServletSecurity, but as a unification of an already common
annotation. That's one of the most annoying things I find in Java EE:
annotations and functionality that only works on some kind of components.
That problems are specially common with CDI: injection not working on JSF
converters (solved with your great OmniFaces), JAX-RS resources not being
managed beans at all, etc.
@RolesAllowed is a simple but useful annotation and I think it'd be good to
have it available everywhere, *unless* the Security Spec comes with
something better that could replace current uses. It would work at (Java)
method level, as in EJBs. For HTTP method level restrictions,
@ServletSecurity should be used instead.
Only problem I see with this annotation is that it's static, but I suposse
that will be discussed when the Authorization epic starts.
Regards,
Guillermo González de Agüero.
On Tue, Jul 5, 2016 at 4:35 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>>>>>
>>>>>
>>>>>
>>
>