Hi,
On Wed, Jul 6, 2016 at 6:54 PM, Guillermo González de Agüero <
z06.guillermo_at_gmail.com> wrote:
> 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.
>
That problem is pretty clear. The solution also seems clear; migrate
everything to being CDI beans. MVC and Java EE Security as new specs
started out being CDI based right away. JSF is moving to CDI (albeit,
unfortunately, slowly).
JAX-RS if I'm not mistaken was planning to rebase more on CDI as well, but
given that the JAX-RS EG is so silent lately I'm not sure if any further
steps toward that goal have been taken.
EJB functionality was being moved (see @Transactional), but this too,
unfortunately, seems to have stalled for the moment.
> @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.
>
The security spec plans to come up with an Interceptor spec based
interceptor. This will then work at least on everything that's a CDI bean,
which, as you mentioned, wouldn't automatically work for JAX-RS resources
and Servlets. The Servlet EG wasn't quite eager to support Interceptors
(and from their viewpoint, with reason). See
https://java.net/projects/servlet-spec/lists/jsr340-experts/archive/2012-02/message/0
I still think a CDI-based Servlet would be a good idea, but then on top of
the existing Servlets. Being a CDI bean that would automatically support
the mentioned interceptor.
JAX-RS btw had plans to support @RolesAllowed natively. Some
implementations already support it in a proprietary way. But again, since
the JAX-RS is so silent these days, I'm not sure what the status of these
plans are.
Kind regards,
Arjan Tijms
> 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
>>>>>>
>>>>>>
>>>>>>
>>>
>>
>