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

[Bill B. <bb...@re...>]

BTW, another reason this won't work (and I'm stupid for not saying it 
earlier) is that there is one servlet deployed for each @ApplicationPath.

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.
>
> The use of the isMandatory flag in this manner is how (I understand) the
> JASPI[C] spec specifies that the requirement for authentication should
> be communicated to the ServerAuthModule.
>
>>
>> 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.
>
> 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?
>
>>
>>
>>
>>
>> On 2/12/2014 8:11 AM, Paul K Moore wrote:
>>> Hi all,
>>>
>>> First post here, so feel free to redirect if necessary.
>>>
>>> I am working on a REST API based on RestEasy 3.0.6 in a Wildfly
>>> 8.0.0.Final-SNAPSHOT environment.
>>>
>>> I’ve implemented @RolesAllowed based security as recommended in the
>>> documentation
>>> <http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/Securing_JAX-RS_and_RESTeasy.html>,
>>> using the resteasy.role.based.security feature, and the relevant
>>> ServletDispatcher and SecurityConstraints.
>>>
>>> From a security perspective, I’m using a custom JASPI ServerAuthModule
>>> and LoginModule. As part of the Wildfly JASPI implementation, the
>>> JASPIAuthenticationMechanism
>>> <https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org/wildfly/extension/undertow/security/jaspi/JASPIAuthenticationMechanism.java?source=cc>.isMandatory()
>>> determines whether the servlet is protected by querying the
>>> ServletSecurity constraints. Currently, this fails as the
>>> ServletSecurityInfo does not contain the @RolesAllowed annotation(s).
>>>
>>> I was wondering if the RestEasy role based security implementation could
>>> be improved to update the ServletSecurityInfo, so that:
>>> i) RestEasy aligned with the more recent Servlet standards, and
>>> ii) any dependencies (such as JASPIAuthenticationMechanism) would
>>> naturally work, and
>>> iii) much of the container plumbing could be removed from most modern
>>> (Servlet 3.0+) RestEasy deployments
>>>
>>
>> You would have to do this work at the
>>
>>> I am happy to have a look at implementing such an enhancement, but would
>>> appreciate some guidance on:
>>> a) whether this approach is reasonable,
>>> b) appropriate points of the RestEasy internals which would make sense
>>> to start the integration (presumably partly in the scan processing, and
>>> partly in the dispatch)
>>>
>>> Thanks
>>>
>>> Paul
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Android apps run on BlackBerry 10
>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>> Get your Android app in front of a whole new audience.  Start now.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>>
>>>
>>>
>>> _______________________________________________
>>> Resteasy-developers mailing list
>>> Res...@li...
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

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