Hi,
Method level @RolesAllowed would work fine for MVC as well. Consider the
following simple example:
@Path("hello")
@Controller
public class HelloController {
@Inject private Models models;
@Context private SecurityContext securityContext;
@GET
@View("hello.jsp")
* @RolesAllowed({"foo"})*
public void greet() {
if (securityContext.getUserPrincipal() != null) {
models.put("user",
securityContext.getUserPrincipal().getName());
}
models.put("hasFoo", securityContext.isUserInRole("foo"));
}
}
Then we could get rid of the pretty verbose web.xml segment below:
<security-constraint>
<display-name>A Foo</display-name>
<web-resource-collection>
<web-resource-name>Demo</web-resource-name>
<description/>
<url-pattern>/ui/hello</url-pattern>
</web-resource-collection>
<auth-constraint>
<description>Constraints for a FOO</description>
<role-name>foo</role-name>
</auth-constraint>
</security-constraint>
Maybe even consider adding support for repeatable annotations.
* @RoleAllowed("foo")*
* @RoleAllowed("bar")*
public void greet() {...}
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
>>>>>>
>>>>>>
>>>>>>
>>>
>>
>