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?
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.
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
