This should not become a big project :-). UserPasswordAuthenticationProvider can throw an exception and that means an authentication failure. I don't think we should ship UserPasswordAuthenticationProvider implementations at all. IMHO returning 403 is not the job of basic authenticator. 401 or let the chain proceed. Sergey
On Thu, Jun 16, 2011 at 2:41 PM, Angelo zerr <[email protected]> wrote: > 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 >> >> > -- Sergey Beryozkin Application Integration Division of Talend http://sberyozkin.blogspot.com
