2011/6/16 Sergey Beryozkin <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > > > >> 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 >
