Re: [Resteasy-developers] Proposed Role Based Security enhancement

[Paul K M. <pau...@gm...>]

On 12 Feb 2014, at 15:41, Bill Burke <bb...@re...> wrote:

> 
> 
> On 2/12/2014 10:11 AM, Paul K Moore wrote:
>> Bill, many thanks for the prompt reply.
>> 
>> Thoughts inline.
>> 
>> Paul
>> 
>> On 12 Feb 2014, at 14:28, Bill Burke <bb...@re...
>> <mailto:bb...@re...>> wrote:
>> 
>>> Resteasy's vanilla @RoleAllowed implementation is just a simple JAX-RS
>>> filter that just delegates to SecurityContext.isUserInRole() which
>>> delegates to the HttpServletRequest.
>> 
>> Understood.
>> 
>>> 
>>> Is there a reason why you need @RolesAllowed metadata to be exposed
>>> through Undertow ServletSecurityInfo?  Can't you just apply a more
>>> generic constraint at the web.xml level?
>> 
>> Because the
>> org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism
>> <https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org/wildfly/extension/undertow/security/jaspi/JASPIAuthenticationMechanism.java?source=cc> uses
>> the Undertow ServletSecurityInfo to determine whether or not to set the
>> isMandatory flag (see esp the isMandatory() method).  My JASPI
>> ServerAuthModule uses the isMandatory flag to determine whether to
>> attempt an authentication, or not.
>> 
> 
> You can specify a security constraint in web.xml that forces authentication but allows all roles.  Then do fine grain RBAC using @RoleAllowed and the simple Resteasy rbac filter, can't you?  Never used JASPI, so maybe I'm just not understanding the full scope of the problem.  What does ServerAuthModule need to know? That auth needs to happen?  Or does it have to know roles allowed too?
> 
>>> 
>>> BTW, I don't think this improvement you want is feasible.  You *could*
>>> do it, but it would be incomplete and error prone.  This is because
>>> Servlet constraints have a very limited URL matching mechanism.  You are
>>> allowed only one simple wildcard.  This is not the case in JAX-RS.
>> 
>> Understood, but I’m thinking less from the perspective of the deployment
>> descriptor servlet constraints and more along the lines of the
>> @ServletSecurity annotations, which seems quite aligned to the @Path etc
>> JAX-RS annotations, and certainly more powerful than the wildcard
>> servlet constraints.
>> 
> 
> web.xml == @ServletSecurity.  They are the same metadata excpet that XML takes precendence over annotations.  Same thing in EJB land with ejb-jar.xml.
> 
> Servlet URL mappings do not support regular expressions AFAIK
> 
> i.e.
> 
> @Path("{path : (foo|bar)/\\d+")
> 
> or even something as simple as:
> 
> @Path("foo/{stuff}/do-it")
> 
> 
> 
>> e.g.
>> 
>> @ServletSecurity(@HttpConstraint(rolesAllowed = { "quickstarts" }))
>> 
>> from
>> https://github.com/jboss-developer/jboss-eap-quickstarts/blob/master/servlet-security/src/main/java/org/jboss/as/quickstarts/servlet_security/SecuredServlet.java
>> 
>>> 
>>> JAX-RS service locators compound the problem even more as endpoints are
>>> dynamically resolved per request!
>>> 
>>> @Path("locator")
>>> java.lang.Object getLocator() {...}
>>> 
>>> So, a locator could return an Object in which it may or may not have a
>>> JAX-RS method that is annotated with @RoleAllowed.  There's just no way
>>> to determine any of this at deploy time.
>>> 
>>> Am I making sense?
>> 
>> Yes, but the ServletSecurityInfo gets populated as part of the request
>> handling, and I was thinking that propagating the @RolesAllowed
>> annotations into this configuration might be a sensible (container
>> aligned) thing to do.
>> 
>> I freely admit however that I’ve (currently) no idea at which point in
>> the lifecycle the SSI is populated and therefore whether the approach is
>> plausible?
> 
> I'm not sure you are right.  I think this stuff is expected to be deploy-time generated metadata and not dynamic, per request.  to be able to make it dynamic you'd probably have to write a Undertow Handler and add this through the JAX-RS subsystem.
> 
> You need to know that Resteasy does not even see the HTTP request until after it has passed through the servlet layer.

Hmmm, I hadn’t appreciated that Resteasy was as independent from the servlet layer (am tracing through ServletContainerDispatcher now).  I suspect there is some tension here as JASPI is particularly aligned with the web container.  It might be that I need to setup security constraints for those resources that I want to further protect with the role based filter (to your earlier point), and allow other resources straight through.

I suspect also I’m just about to run into the limitations of the the URL mapping limitations.

Will continue with the trace, and report back.

Thanks

> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com