Lars Tackmann wrote:
> On Tue, Apr 1, 2008 at 12:41 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>> > I think that SecurityContext is intended for container managed seurity
>> > (i.e. JDBC realm).
>>
>> That is correct. Our approach is to try and rely as much as possible on
>> the container for security support. But as I understand at the moment
>> there are way too many steps to configure (or plugin) for GF.
>>
>> So i am wondering if we should consider a general req/res filter
>> mechanism that could do request verification and response modification.
>> A serlet filter would be ideal if the request processing filter part can
>> provide the SecurityContext implementation.
>
> This would be a great addition, something similar to servlet 3 style filtering:
>
I have not been following servlet as much as i should...
> --
> public class SomeResource {
> @GET
> @RequestFilter(filters = {SecurityFilter.class, LoggingFilter.class})
> public Stuff getStuff() {
> //
> }
> }
> --
>
> The security filter could then be like:
>
> --
> public class SecurityFilter {
> @Context
> private SecurityContext sctx;
>
> public void doFilter(...) {
> // new feature in security context
> List<String> res = sctx.runAuth(AuthType.BASIC)
> String username = res.get(0);
> String password = res.get(1);
> // custom made security lookup instead of JDBC realm
> Query q = entityManager.createNativQuery("select * from
> customers where cust_username = ?", Customer.class)
> q.setParameter(1, username);
> Customer cust = (Customer) q.getSingleResult();
> if(!cust.getPassword().equals(password)) {
> throw new
> WebApplicationException(HttpServletResponse.SC_UNAUTHORIZED);
> }
> }
> }
> --
>
> this can be viewed as a IoC style interceptor which I can fully
> understand that you might not like to provide. However the ability to
> apply my own filters on individual methods (and chain filters
> together) would be really nice. Writing small clean security modules
> like the one above, could also be facilitated by letting the
> SecurityContext publish header parsing results (i.e. decoding and
> splitting the auth parts based on the security scheme).
>
Yes, i can see the advantage. Need to think about this a bit more... I
think that this should be possible as an IoC pre-invocation method if
one can inject Jersey/JAX-RS specific functionality on the component
with the pre invocation method (although the IoC method may not be as
pretty).
Not sure it is necessary to have methods on SecurityContext for auth and
instead we could have:
public class SecurityFilter {
public void doFilter(@HttpHeaders h, @Context SecurityManager sm) {
AuthData ad = basicDigest(h);
// DB lookup
// all OK?
sm.set(new BasicAuthSC(AuthData));
}
}
>> I would really like to provide pluggable auth mechanisms as part of the
>> client API. e.g. to configure the Client to auth for all WebResource
>> instances or configure the WebResource to use auth that overrides that
>> of the Client.
>>
>> A general client filter mechanism is already in there that can support
>> such auth mechanisms. I can send more details if you like.
>
> Fantastic. I often unit test in the following way:
>
> 1) Test that 401 is returned without auth
> 2) Create a user....
> 3) Test that access is granted with the new users auth
>
> so if the programming model could allow me to easily switch between
> auth headers, like:
>
> --
> // create auth header
> AuthHeader authHeader = AuthHeader.getInstance(AuthType.BASIC);
> authHeader.setUsername("me");
> authHeader.setPassword("secret");
>
> // fail without auth
> builder.setAuth(null);
> ClientResponse cr = builder.get(ClientResponse.class);
> assertThat(cr.getStatus(), equalTo(HttpServletResponse.SC_UNAUTHORIZED));
>
> // succede with auth
> builder.setAuth(authHeader);
> cr = builder.get(ClientResponse.class);
> assertThat(cr.getStatus(), equalTo(HttpServletResponse.SC_OK));
> --
>
> then it would be great.
>
OK. I was thinking more along of the lines of:
WebResource r = ...
r.setAuth(...);
or:
Client c = ...
c.setAuth(...);
because often it is the case that you don't want to set the auth for
each and every request for a resource, or resources created from a
client. But i can see the way you have expressed it makes sense on the
request builder.
BTW for the 0.7 API Response.Status has enum constants for status codes.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109