On Apr 1, 2008, at 10:26 AM, Bill Burke wrote:
> I've been reluctant to add security features to our JAX-RS
> implementation mainly because I believe that the combination of the
> Servlet and EJB (or Spring) specifications should be enough.
> Servlet spec can be used to authenticate/authorize URL patterns.
> EJB can be used for very fine grain security like authorization on
> exchanging different content type formats.
>
> The major problem I've found with this approach lies solely with the
> fault of the Servlet spec and its poor definition of <url-pattern>.
> If you want a site that has a mix of secured and unsecured URLs, the
> servlet spec just can't handle all JAX-RS use cases it as a "foo/*/
> bar" pattern is not supported. For example, I can't do fine grain
> security on:
>
> /customers/{id}/address
> /customers/{id}/creditcard
>
> Have address unsecure
> Credit card secured.
>
> Maybe this usecase is contrived, but my intuition tells me not.
>
To give fine-grained control we anticipate allowing use of
@RolesAllowed on resource classes, sub-resource methods and sub-
resource locators. In a servlet-based container you can support this
by calling HttpServletRequest.isUserInRole for each of the roles in
the annotation.
The servelt spec lead and our EE security architect are working on an
addition to servlet that will allow a servlet application to trigger
an authentication outside of url-patterns. This will be used in
conjunction with @RolesAllowed so a 311 impl can trigger auth when
required.
Marc.
>
>
> Now, finally, my quesiton: I wondering if we should get a minor
> tweak to the Servlet 3.0 spec?
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.