Yes basically that is it.
Btw. one small thing about the code. You have many constants like:
private static final String NO_AUTHORIZATION_POLICY =
"NO_AUTHORIZATION_POLICY";
I would rather use the string in the code. I think a constant will not
improve the code here.
Christian
Am 16.06.2011 15:41, schrieb Angelo zerr:
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
