cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angelo zerr <angelo.z...@gmail.com>
Subject Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Date Thu, 16 Jun 2011 12:41:15 GMT
2011/6/16 Sergey Beryozkin <sberyozkin@gmail.com>

> Hi
>
> Do you agree with the idea of UserPasswordAuthenticationProvider ?
> I think Christian and myself are in agreement that BasicAuthInterceptor
>
> should only enforce that the policy is set and if yes then invoke
> optionally on the injected
> custom UserPasswordAuthenticationProvider and set a non-null
> SecurityContext on the current Message.
>

You mean that  BasicAuthInterceptor should never call
sendErrorResponsewhich returns HTTP 401 (if no user/password found)
and HTTP 403 (if no
user/password match) and just create SecurityContext?
I like the idea that BasicAuthInterceptor returns HTTP response state. If we
have just SecurityContext it will throw just an exception and not modify
state of the HTTP response if I understand.
Is that?

Regards Angelo


> Cheers, Sergey
>
>
> On Thu, Jun 16, 2011 at 1:16 PM, Angelo zerr <angelo.zerr@gmail.com>
> wrote:
> > Hi Sergey and Christian,
> >
> > I would like to know if you need some another informations about my work
> > because I need BasicAuthAuthorizationInterceptor for my project. My code
> > works great with Tomcat (I must test with WebShpere soon).
> > An other advantage to use BasicAuthAuthorizationInterceptor instead of
> > managing with Filter like Christian has suggested me is that I publish my
> > webservice with Endpoint#publish with an URL (ex :
> > http:localhost:8081/services/hello) which is different from the Web
> > Application (ex : http:localhost:8080/mywebapp) by using Embedded Jetty.
> >
> > I will be happy if BasicAuthAuthorizationInterceptor could be integrated
> > into CXF.
> >
> > Regards Angelo
> >
> > 2011/6/15 Christian Schneider <chris@die-schneider.net>
> >
> >> Am 14.06.2011 23:24, schrieb Sergey Beryozkin:
> >>
> >>
> >>> 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 UserPasswordAuthenticationProv**ider {
> >>>   SecurityContext authenticate(String userName, String password)
> >>> throws AuthenticationException;
> >>> }
> >>>
> >>> or simply
> >>>
> >>> SecurityContext authenticate(String userName, String password);
> >>>
> >>>
> >> Sounds great. I think the variant without a special exception could be
> >> enough. We can throw a RuntimeException
> >> if the authentication fails. I would say SecurityContext should always
> be
> >> populated completely (no two phases).
> >>
> >> Christian
> >>
> >> --
> >> --
> >> Christian Schneider
> >> http://www.liquid-reality.de
> >>
> >> Open Source Architect
> >> Talend Application Integration Division http://www.talend.com
> >>
> >>
> >
>
>
>
> --
> Sergey Beryozkin
>
> Application Integration Division of Talend
> http://sberyozkin.blogspot.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message