On Thu, Jul 7, 2016 at 4:19 PM Guillermo González de Agüero <
z06.guillermo_at_gmail.com> wrote:
> 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.
>
+1
>
>
> 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.
>
+1
>
>
> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>