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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>