HI Christian On Thu, Jun 16, 2011 at 3:10 PM, Christian Schneider <[email protected]> wrote: > Hi Sergey, > > you could be right. When trying from a browser 401 means the browser will > ask for username / password again. So probably the interceptor should rather > throw 401 instead of 403 in case of an exception. Of course this means that > Authorization can not be done at this stage. (Which does not hurt much). > Doe we have any authorization impls present already so Angelo can implement > what he needs? > SimpleAuthorizationInterceptor and SecureAnnotationsInterceptor.
> Well anyway in case we have nothing suitable he can simply write another > interceptor that looks for the SecurityContext and throws 403 in case the > user may not use the service. +1 Also, CXF ships runtime AuthenticationException and AuthorizationException. So BasicAuthInterceptor can possibly check for both, provided a given UserNamePasswordProvider decides it needs to do the authorization as well, so may be UserNamePasswordProvider should also be provided with a current Message ? So that some impls can get whatever context info they need in order to proceed with the early authorization step...Method name can be enough, but paramers, client ip, etc, may be needed for a final decision... Thanks, Sergey > Christian > > > Am 16.06.2011 16:04, schrieb Sergey Beryozkin: >> >> 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 >>>> >>>> >> >> > > > -- > -- > 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
