Hi,
I don't think it's a good idea for JAX-RS (or any other) to natively
support @RolesAllowed. With this Security spec, it's up to us to provide
the mentioned interceptor that everyone could use.
Would that be AND semantics then? Multiple roles in a single annotation is
> OR.
>
What about a @RequiredRoles annotation? @RolesAllowed belongs to the Common
Annotations spec, which just got a MR. Review ballot ends on 25th July, so
this is the moment if we want to add new classes.
Regards,
Guillermo González de Agüero.
On Thu, Jul 7, 2016 at 9:22 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Wed, Jul 6, 2016 at 8:04 PM, Ivar Grimstad <ivar.grimstad_at_gmail.com>
> wrote:
>
>> Method level @RolesAllowed would work fine for MVC as well.
>>
>
> Indeed, that would be a good match. Since @RolesAllowed is just a plain
> annotation and not Interceptor spec based it wouldn't work automatically,
> of course. Perhaps we can see if it's worthwhile to make a CDI bridge via
> an extension. E.g. scan classes for @RolesAllowed, then dynamically add an
> Interceptor binding annotation.
>
> This would possibly be a lot more doable if CDI made it possible to
> dynamically add interceptors to Beans. If I'm not mistaken it currently can
> only be done by adding an annotation to an annotated type, but for the
> annotated type we don't know yet if it's not an EJB. For EJBs we don't want
> to add an interceptor, as it already processes @RolesAllowed natively.
>
>
> Maybe even consider adding support for repeatable annotations.
>>
>> * @RoleAllowed("foo")*
>> * @RoleAllowed("bar")*
>> public void greet() {...}
>>
>
> Would that be AND semantics then? Multiple roles in a single annotation is
> OR.
>
> // Accessible for callers in role "foo" OR "bar"
> * @RoleAllowed("foo", "bar")*
> public void greet() {...}
>
> Kind regards,
> Arjan Tijms
>
>
>
>> Ivar
>>
>> On Wed, Jul 6, 2016 at 7:46 PM Guillermo González de Agüero <
>> z06.guillermo_at_gmail.com> wrote:
>>
>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>
>