Hi, Ok if I understand your idea, my code works among that you wish :
Today my code do that : 1) throws 401 if no user/password. 2) throws 403 if user/password is not match 3) create a SecurityContext if you wish. Create a SecurityContext give you the capability to use CXF features with roles. If I understand your idea, you wish do that : 1) throws 401 if no user/password. 2) create a SecurityContext every time. 3) throws 403 if SecurityContext throws an error. Is that? If it's your idea I could try to implement your idea with UserPasswordAuthenticationProvider Regards Angelo 2011/6/16 Christian Schneider <[email protected]> > Am 16.06.2011 14:41, schrieb Angelo zerr: > >> 2011/6/16 Sergey Beryozkin<[email protected]**> >> >> Hi >>> >>> Do you agree with the idea of UserPasswordAuthenticationProv**ider ? >>> 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 UserPasswordAuthenticationProv**ider 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 >> >> > I think the interceptor should handle the case of no username / password by > returning 401. This could be made optional if anonymous is also ok. > I think we could respond with 403 if the authentication throws an > exception. Typically this is for username / password mismatch. A real > authorization should not be done at this point. > > Of course you can build your authentication class in a way that it throws > an exception if the user may not access the service. So you don´t need to > configure additional authorization. But I would generally not recommend > this. > > > Christian > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > >
