cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Date Tue, 14 Jun 2011 21:24:26 GMT
Hi Christian

On Tue, Jun 14, 2011 at 6:04 PM, Christian Schneider
<> wrote:
> I think we can provide an authentication hook in form of an interface that
> people can implement. Like:
> interface UserPasswordAuthenticationProvider {
>  boolean authenticate(String userName, String password);
> }
> This could be called by the interceptor to check the authentication.
> We would of course also need a way to gather the roles/groups. Either as a
> list of roles or as a isInGroup callback.
> To store the authentication result the DefaultSecurityContext or the
> RolePrefixSecurityContextImpl could be used.
> I don´t think we need to reimplement SecurityContext.

If we were to go with an interface like this then I'd propose to
combine the process of accumulating Principal and Roles info which is
what always happening AFAIK with the real systems. Authentication and
authorization are more often than not are done at different stages but
SecurityContext is populated in one go.

Thus I propose:

interface UserPasswordAuthenticationProvider {
  SecurityContext authenticate(String userName, String password)
throws AuthenticationException;

or simply

SecurityContext authenticate(String userName, String password);

This is because only a 3rd part Secure manager knows how roles are
represented, and creating (CXF) SecurityContext
is trivial when no roles is available (just use anonymous
SecurityContext with SimplePrincipal helpers) or when roles are
available. Relevant CXF SecurityContext impls are expecting Subjects
which is a collection of SimplePrincipals and/or SimpleGroups. We can
make it a two-step process, such that the 2nd call returns a list of
String roles for ex, but I'm not sure that will make life easier for
implementers, given that at least some systems I know of will
internally return an accumulated result thus implementers will need to
repeat the query or introduce the state of its own

Cheers, Sergey

> Christian
> Am 14.06.2011 18:40, schrieb Sergey Beryozkin:
>> I can actually see the source (thanks to Christian for pointing me to
>> it :-)) but I'd like to understand what are you trying to do besides
>> enforcing that BasicAuth is there. I thought you needed to get
>> username&  password and get the custom authentication done by
>> interacting somehow with your custom SecurityManager, right ?  I'm not
>> sure we can generilize that process in CXF itself, the process of
>> communicating with the custom SecurityManager - JAAS or/and Spring is
>> there for that.
> --
> --
> Christian Schneider
> Open Source Architect
> Talend Application Integration Division

Sergey Beryozkin

Application Integration Division of Talend

View raw message