> > 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?
BasicAuthInterceptor should only handle authentication errors and return 401 in case of exceptions. As well as populate a SecurityContext along the way with the roles info which can be used at the authorization stage. Combining authentication and authorization actions in one single 'atomic' action won't allow us to reuse SimpleAuthorizingInterceptor or SecureObjectInterceptor or delegate to EJB authorization, etc Cheers, Sergey > > 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 >> > -- Sergey Beryozkin Application Integration Division of Talend http://sberyozkin.blogspot.com
