I see some kind of @RequiredRoles annotation specially useful to use roles
in a more permission like fashion. For example:
@RequiredRoles({"articles_view_vip", "comments_publish"}).
More complex and dynamic use cases should be covered by the new
Authorization API.
Regards,
Guillermo González de Agüero.
On Thu, Jul 7, 2016 at 5:16 PM, Ivar Grimstad <ivar.grimstad_at_gmail.com>
wrote:
>
>
> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>