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:
--
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).
> 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.
--
Yours sincerely
Lars Tackmann