You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Angelo zerr <an...@gmail.com> on 2011/06/13 17:34:27 UTC
HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Hi CXF Team,
I would like to manage WebService with HTTP Basic CXF Interceptor and I have
not found this interceptor in the CXF. So I have used the great code from
http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
it works great.
I have noticed that some projects like
http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
used this code and I tell me why CXF doesn't include the
BasicAuthAuthorizationInterceptor class?
I have modified BasicAuthAuthorizationInterceptor to delegate user/password
to another interface implementation and if you wish I could send you my work
and tell to the author of the BasicAuthAuthorizationInterceptor if he is OK
to contribute to CXF.
Thank a lot for your answer.
Regards Angelo
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Angelo zerr <an...@gmail.com>.
Hi Sergey,
Sorry for the delay.
At first I would like to say you that my work about
BasicAuthAuthorizationInterceptor is just a POC and I have tried to manage
security with Basic AuthAuthorization + use roles of users by creating a
SecurityContext.
Here process of BasicAuthAuthorizationInterceptor (which looks like
JAASLoginInterceptor) :
1) Check if there is If there is a AuthorizationPolicy in the message. If
AuthorizationPolicy is null it throw"HTTP Status-Code 401: Unauthorized".
2) Check user+password. This feature is delegated by an implementation of
BasicAuthAuthorizationContext (like SimpleBasicAuthAuthorizationContext
which manage user+password with Map).
In my case I have implemented BasicAuthAuthorizationContext with my Security
Manager.
3) If user+password is bad it throw "HTTP Status-Code 401: Unauthorized."
4) Otherwise create a SecurityContext and store it in the message (like
JAASLoginInterceptor) ONLY if
BasicAuthAuthorizationContext#getUserRolesContext() is not null. In my case
I don't use this feature but I have tried to implement itot have the same
thing than JAASLoginInterceptor. I think that SecurityContext will be not
used well with Basic Authentification : having security for method of
services is not very lot used I think.
Hope you will understand my explanation.
Regards Angelo
2011/6/14 Sergey Beryozkin <sb...@gmail.com>
> I can actually see the source (thanks to Christian for pointing me to
> it :-)) but I'd like to understand what are you trying to do besides
> enforcing that BasicAuth is there. I thought you needed to get
> username & password and get the custom authentication done by
> interacting somehow with your custom SecurityManager, right ? I'm not
> sure we can generilize that process in CXF itself, the process of
> communicating with the custom SecurityManager - JAAS or/and Spring is
> there for that.
> > Can you explain please what BasicAuthAuthorizationInterceptor actually
> does ?
>
> That is why I asked this question :-)
>
> thanks, Sergey
>
> On Tue, Jun 14, 2011 at 4:50 PM, Sergey Beryozkin <sb...@gmail.com>
> wrote:
> > Hi
> > Can you explain please what BasicAuthAuthorizationInterceptor actually
> does ?
> >
> > We really need source of that interceptor, ideally attached as a patch to
> JIRA
> > thanks, Sergey
> >
> > On Tue, Jun 14, 2011 at 4:23 PM, Angelo zerr <an...@gmail.com>
> wrote:
> >> Hi Sergey,
> >>
> >> I have attached a zip with my work. It's a WTP Eclipse project where you
> can
> >> find BasicAuthAuthorizationInterceptor in the
> >> org.apache.cxf.interceptor.security.basic package.
> >> There is a sample with Basic authentification authorization with NO
> roles :
> >>
> >> ---------------------------------------------------------
> >> <!-- WebServices with Basic Authentification Authorization -->
> >> <jaxws:endpoint xmlns:tns="http://server.sample/" id="helloworld"
> >> implementor="sample.server.HelloWorld"
> >> wsdlLocation="wsdl/helloworld.wsdl"
> >> endpointName="tns:HelloWorldPort"
> >> serviceName="tns:HelloWorldService"
> >> address="/HelloWorldPort">
> >> <jaxws:features>
> >> <bean class="org.apache.cxf.feature.LoggingFeature" />
> >> </jaxws:features>
> >> <jaxws:inInterceptors>
> >> <ref bean="basicAuthAuthorization1" />
> >> </jaxws:inInterceptors>
> >> </jaxws:endpoint>
> >>
> >> <bean id="basicAuthAuthorization1"
> >>
> >>
> class="org.apache.cxf.interceptor.security.basic.BasicAuthAuthorizationInterceptor">
> >> <property name="realmName" value="MyRealm" />
> >> <property name="authorizationContext">
> >> <bean
> >>
> >>
> class="org.apache.cxf.interceptor.security.basic.SimpleBasicAuthAuthorizationContext">
> >> <property name="usersMap">
> >> <map>
> >> <entry key="ffang" value="pswd" />
> >> </map>
> >> </property>
> >> </bean>
> >> </property>
> >> </bean>
> >> ----------------------------------------------------------
> >>
> >> And sample with Basic authentification authorization with roles :
> >>
> >> ----------------------------------------------------------
> >>
> >> <!-- WebServices with Basic Authentification Authorization + Roles
> -->
> >> <jaxws:endpoint xmlns:tns="http://server.sample/" id="helloworld2"
> >> implementor="sample.server.HelloWorld"
> >> wsdlLocation="wsdl/helloworld.wsdl"
> >> endpointName="tns:HelloWorldPort"
> >> serviceName="tns:HelloWorldService"
> >> address="/HelloWorldPort2">
> >> <jaxws:features>
> >> <bean class="org.apache.cxf.feature.LoggingFeature" />
> >> </jaxws:features>
> >> <jaxws:inInterceptors>
> >> <ref bean="basicAuthAuthorization2" />
> >> <ref bean="authorizationInterceptor" />
> >> </jaxws:inInterceptors>
> >> </jaxws:endpoint>
> >>
> >> <bean id="basicAuthAuthorization2"
> >>
> >>
> class="org.apache.cxf.interceptor.security.basic.BasicAuthAuthorizationInterceptor">
> >> <property name="realmName" value="MyRealm" />
> >> <property name="authorizationContext">
> >> <bean
> >>
> >>
> class="org.apache.cxf.interceptor.security.basic.SimpleBasicAuthAuthorizationContext">
> >> <property name="usersMap">
> >> <map>
> >> <entry key="ffang" value="pswd" />
> >> </map>
> >> </property>
> >> <property name="userRolesContext">
> >> <bean
> >>
> >>
> class="org.apache.cxf.interceptor.security.basic.SimpleUserRolesContext">
> >> <property name="userRolesMap">
> >> <map>
> >> <entry key="ffang" value="ROLE1 ROLE2"
> />
> >> </map>
> >> </property>
> >> </bean>
> >> </property>
> >> </bean>
> >> </property>
> >> </bean>
> >>
> >> <bean id="authorizationInterceptor"
> >>
> >>
> class="org.apache.cxf.interceptor.security.SimpleAuthorizingInterceptor">
> >> <property name="methodRolesMap">
> >> <map>
> >> <entry key="hello" value="ROLE1" />
> >> </map>
> >> </property>
> >> </bean>
> >> ----------------------------------------------------------
> >>
> >> If you start your server at localhost 8080 you can launch teh client :
> >>
> >> * HelloWorld_PortTypeClient which call the first service (with no
> roles).
> >> * HelloWorld_PortTypeClient2 which call the second service (with roles).
> >>
> >> Everything works with interface and I have implemented with Simple*
> class
> >> which works with Map but you can implements with another mean if you
> wish.
> >>
> >> Hope you will like it.
> >>
> >> Regards Angelo
> >> 2011/6/14 Sergey Beryozkin <sb...@gmail.com>
> >>>
> >>> >
> >>> > No problem:) Ok I have implemented this feature. Now I tell me if
> >>> > SecurityContext should be implemented (if Principal is null) for
> Basic
> >>> > Interceptor like JAASLoginInterceptor which put a SecurityContext.
> The
> >>> > only
> >>> > question is how set roles? But if we do that we could use
> >>> > afterSimpleAuthorizingInterceptor
> >>>
> >>> You can use org.apache.cxf.common.security.SimplePrincipal just to
> >>> wrap up a principal name.
> >>> DefaultSecurityContext (roles represented as Groups,
> >>> org.apache.cxf.common.security.SimpleGroup helper is there) and
> >>> RolePrefixSecurityContextImls (role names start with some prefix like
> >>> ROLE_) can be used to provide a SecurityContext on a current message.
> >>> They all expect a Subject instance which you can easily create with
> >>> the help of SimplePrincipal (and SimpleGroup if needed)
> >>>
> >>> Cheers, Sergey
> >>>
> >>>
> >>> >
> >>> > Regards Angelo
> >>> >
> >>> >
> >>> >> On Tue, Jun 14, 2011 at 10:54 AM, Angelo zerr <
> angelo.zerr@gmail.com>
> >>> >> wrote:
> >>> >> > Ok I believe understand your idea about realm. I have added a
> setter
> >>> >> > in
> >>> >> my
> >>> >> > Interceptor :
> >>> >> >
> >>> >> > AbstractBasicAuthAuthorizationInterceptor#setRealName(String
> >>> >> > realName)
> >>> >> which
> >>> >> > compute WWW-Authenticate.
> >>> >> > Ex :
> AbstractBasicAuthAuthorizationInterceptor#setRealName("MyRealm")
> >>> >> will
> >>> >> > returns
> >>> >> >
> >>> >> > WWW-Authenticate: Basic realm="MyRealm"
> >>> >> >
> >>> >> > If no realm defined, WWW-Authenticate is not returned. Is that
> your
> >>> >> idea?
> >>> >> > WWW-Authenticate is not required? Do you think we should set a
> >>> >> > default
> >>> >> value
> >>> >> > for Realm?
> >>> >> >
> >>> >> > Regards Angelo
> >>> >> >
> >>> >> > 2011/6/14 Angelo zerr <an...@gmail.com>
> >>> >> >
> >>> >> >> Hi Sergey,
> >>> >> >>
> >>> >> >> 2011/6/14 Sergey Beryozkin <sb...@gmail.com>
> >>> >> >>
> >>> >> >>> Hi
> >>> >> >>>
> >>> >> >>> That interceptor should be more neutral, should' not extend a
> SOAP
> >>> >> >>> interceptor.
> >>> >> >>>
> >>> >> >>
> >>> >> >> Ok, I have done like JAASLoginInterceptor (extends
> >>> >> >> AbstractPhaseInterceptor<Message> + constructor initialized with
> >>> >> >> super(Phase.UNMARSHAL);) and it works.
> >>> >> >>
> >>> >> >>
> >>> >> >>> The other thing you may want to do is to configure it with a
> realm
> >>> >> >>> name and if it's not set then
> >>> >> >>> do not add a realm parameter to the response.
> >>> >> >>>
> >>> >> >>
> >>> >> >> Could you explain me more your idea please.
> >>> >> >>
> >>> >> >>
> >>> >> >>>
> >>> >> >>> FYI, CXF ships JAASLoginInterceptor - which will check if Basic
> (or
> >>> >> >>> other similar HTTP Authorization type was set)
> >>> >> >>> and then will delegate to JAAS to do the actual authentication:
> >>> >> >>>
> http://cxf.apache.org/docs/security.html#Security-Authentication
> >>> >> >>>
> >>> >> >>> I propose that you create a patch in rt/core,
> >>> >> >>> org.apache.cxf.interceptor.security package, that will make it
> >>> >> >>> easier
> >>> >> >>> for me to move the relevant code to a rt/security module
> >>> >> >>>
> >>> >> >>
> >>> >> >> My first idea is to create a WTP sample application with my code
> (I
> >>> >> >> have
> >>> >> >> created org.apache.cxf.interceptor.security.basic package) and
> send
> >>> >> >> you
> >>> >> with
> >>> >> >> sample which work.
> >>> >> >> After I could create a patch if you need.
> >>> >> >>
> >>> >> >> Regards Angelo
> >>> >> >>
> >>> >> >>>
> >>> >> >>> Thanks, Sergey
> >>> >> >>>
> >>> >> >>> On Tue, Jun 14, 2011 at 7:38 AM, Angelo zerr
> >>> >> >>> <an...@gmail.com>
> >>> >> >>> wrote:
> >>> >> >>> > Hi Freeman,
> >>> >> >>> >
> >>> >> >>> > Thank a lot for your answer. I will prepare you a contribution
> >>> >> >>> > and
> >>> >> send
> >>> >> >>> you.
> >>> >> >>> >
> >>> >> >>> > Regards Angelo
> >>> >> >>> >
> >>> >> >>> > 2011/6/14 Freeman Fang <fr...@gmail.com>
> >>> >> >>> >
> >>> >> >>> >> Hi,
> >>> >> >>> >>
> >>> >> >>> >> Sure, any contribution is welcome.
> >>> >> >>> >>
> >>> >> >>> >> And in CXF we also can use jetty security handler to enable
> >>> >> >>> >> basic
> >>> >> auth
> >>> >> >>> >> which can configure the realm easily, we have a system
> testcase
> >>> >> >>> >> for
> >>> >> >>> it[1],
> >>> >> >>> >> you may wanna take a look.
> >>> >> >>> >>
> >>> >> >>> >> [1]
> >>> >> >>> >>
> >>> >> >>>
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
> >>> >> >>> >> Freeman
> >>> >> >>> >>
> >>> >> >>> >> On 2011-6-13, at 下午11:34, Angelo zerr wrote:
> >>> >> >>> >>
> >>> >> >>> >> Hi CXF Team,
> >>> >> >>> >>>
> >>> >> >>> >>> I would like to manage WebService with HTTP Basic CXF
> >>> >> >>> >>> Interceptor
> >>> >> and
> >>> >> >>> I
> >>> >> >>> >>> have
> >>> >> >>> >>> not found this interceptor in the CXF. So I have used the
> great
> >>> >> code
> >>> >> >>> from
> >>> >> >>> >>>
> >>> >> >>> >>>
> >>> >> >>>
> >>> >>
> >>> >>
> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
> >>> >> >>> >>> it works great.
> >>> >> >>> >>> I have noticed that some projects like
> >>> >> >>> >>>
> >>> >> >>> >>>
> >>> >> >>>
> >>> >>
> >>> >>
> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
> >>> >> >>> >>> used this code and I tell me why CXF doesn't include the
> >>> >> >>> >>> BasicAuthAuthorizationInterceptor class?
> >>> >> >>> >>>
> >>> >> >>> >>> I have modified BasicAuthAuthorizationInterceptor to
> delegate
> >>> >> >>> >>> user/password
> >>> >> >>> >>> to another interface implementation and if you wish I could
> >>> >> >>> >>> send
> >>> >> you
> >>> >> >>> my
> >>> >> >>> >>> work
> >>> >> >>> >>> and tell to the author of the
> BasicAuthAuthorizationInterceptor
> >>> >> >>> >>> if
> >>> >> he
> >>> >> >>> is
> >>> >> >>> >>> OK
> >>> >> >>> >>> to contribute to CXF.
> >>> >> >>> >>>
> >>> >> >>> >>> Thank a lot for your answer.
> >>> >> >>> >>>
> >>> >> >>> >>> Regards Angelo
> >>> >> >>> >>>
> >>> >> >>> >>
> >>> >> >>> >> ---------------------------------------------
> >>> >> >>> >> Freeman Fang
> >>> >> >>> >>
> >>> >> >>> >> FuseSource
> >>> >> >>> >> Email:ffang@fusesource.com
> >>> >> >>> >> Web: fusesource.com
> >>> >> >>> >> Twitter: freemanfang
> >>> >> >>> >> Blog: http://freemanfang.blogspot.com
> >>> >> >>> >>
> >>> >> >>> >>
> >>> >> >>> >>
> >>> >> >>> >>
> >>> >> >>> >>
> >>> >> >>> >>
> >>> >> >>> >>
> >>> >> >>> >>
> >>> >> >>> >>
> >>> >> >>> >>
> >>> >> >>> >
> >>> >> >>>
> >>> >> >>
> >>> >> >>
> >>> >> >
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Sergey Beryozkin
> >>> >>
> >>> >> Application Integration Division of Talend
> >>> >> http://sberyozkin.blogspot.com
> >>> >>
> >>> >
> >>
> >>
> >
> >
> >
> > --
> > Sergey Beryozkin
> >
> > Application Integration Division of Talend
> > http://sberyozkin.blogspot.com
> >
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
>
> 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?
BasicAuthInterceptor should only handle authentication errors and
return 401 in case of exceptions.
As well as populate a SecurityContext along the way with the roles
info which can be used at the authorization stage.
Combining authentication and authorization actions in one single
'atomic' action won't allow us to reuse SimpleAuthorizingInterceptor
or SecureObjectInterceptor or delegate to EJB authorization, etc
Cheers, Sergey
>
> Regards Angelo
>
>
>> Cheers, Sergey
>>
>>
>> On Thu, Jun 16, 2011 at 1:16 PM, Angelo zerr <an...@gmail.com>
>> wrote:
>> > Hi Sergey and Christian,
>> >
>> > I would like to know if you need some another informations about my work
>> > because I need BasicAuthAuthorizationInterceptor for my project. My code
>> > works great with Tomcat (I must test with WebShpere soon).
>> > An other advantage to use BasicAuthAuthorizationInterceptor instead of
>> > managing with Filter like Christian has suggested me is that I publish my
>> > webservice with Endpoint#publish with an URL (ex :
>> > http:localhost:8081/services/hello) which is different from the Web
>> > Application (ex : http:localhost:8080/mywebapp) by using Embedded Jetty.
>> >
>> > I will be happy if BasicAuthAuthorizationInterceptor could be integrated
>> > into CXF.
>> >
>> > Regards Angelo
>> >
>> > 2011/6/15 Christian Schneider <ch...@die-schneider.net>
>> >
>> >> Am 14.06.2011 23:24, schrieb Sergey Beryozkin:
>> >>
>> >>
>> >>> If we were to go with an interface like this then I'd propose to
>> >>> combine the process of accumulating Principal and Roles info which is
>> >>> what always happening AFAIK with the real systems. Authentication and
>> >>> authorization are more often than not are done at different stages but
>> >>> SecurityContext is populated in one go.
>> >>>
>> >>> Thus I propose:
>> >>>
>> >>> interface UserPasswordAuthenticationProv**ider {
>> >>> SecurityContext authenticate(String userName, String password)
>> >>> throws AuthenticationException;
>> >>> }
>> >>>
>> >>> or simply
>> >>>
>> >>> SecurityContext authenticate(String userName, String password);
>> >>>
>> >>>
>> >> Sounds great. I think the variant without a special exception could be
>> >> enough. We can throw a RuntimeException
>> >> if the authentication fails. I would say SecurityContext should always
>> be
>> >> populated completely (no two phases).
>> >>
>> >> 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
>>
>
--
Sergey Beryozkin
Application Integration Division of Talend
http://sberyozkin.blogspot.com
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
And SecurityContext won't be throwing exceptions it only provides info
for other interceptors (authorization/etc) to react to mismatched
roles or claims, etc
On Thu, Jun 16, 2011 at 3:04 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> 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 <an...@gmail.com> 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 <ch...@die-schneider.net>
>>
>>> Am 16.06.2011 14:41, schrieb Angelo zerr:
>>>
>>>> 2011/6/16 Sergey Beryozkin<sberyozkin@gmail.com**>
>>>>
>>>> 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
>
--
Sergey Beryozkin
Application Integration Division of Talend
http://sberyozkin.blogspot.com
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
+1 indeed
thanks, Sergey
On Thu, Jun 16, 2011 at 4:33 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Am 16.06.2011 16:21, schrieb Sergey Beryozkin:
>>
>> 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...
>
> As Authorization is quite simple as you showed with the existing impls I
> think we should rather not have the Authentication impl do authorization. I
> am not sure if any more context info is needed for authentication too but I
> think we could first start with only username and password and see when
> someone really needs more.
>
> 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
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Christian Schneider <ch...@die-schneider.net>.
Am 16.06.2011 16:21, schrieb Sergey Beryozkin:
>
> 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...
As Authorization is quite simple as you showed with the existing impls I
think we should rather not have the Authentication impl do
authorization. I am not sure if any more context info is needed for
authentication too but I think we could first start with only username
and password and see when someone really needs more.
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
HI Christian
On Thu, Jun 16, 2011 at 3:10 PM, Christian Schneider
<ch...@die-schneider.net> 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<an...@gmail.com>
>> 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<ch...@die-schneider.net>
>>>
>>>> Am 16.06.2011 14:41, schrieb Angelo zerr:
>>>>
>>>>> 2011/6/16 Sergey Beryozkin<sberyozkin@gmail.com**>
>>>>>
>>>>> 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
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Christian Schneider <ch...@die-schneider.net>.
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<an...@gmail.com> 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<ch...@die-schneider.net>
>>
>>> Am 16.06.2011 14:41, schrieb Angelo zerr:
>>>
>>>> 2011/6/16 Sergey Beryozkin<sberyozkin@gmail.com**>
>>>>
>>>> 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
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <an...@gmail.com> 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 <ch...@die-schneider.net>
>
>> Am 16.06.2011 14:41, schrieb Angelo zerr:
>>
>>> 2011/6/16 Sergey Beryozkin<sberyozkin@gmail.com**>
>>>
>>> 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
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Christian Schneider <ch...@die-schneider.net>.
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<ch...@die-schneider.net>
>
>> Am 16.06.2011 14:41, schrieb Angelo zerr:
>>
>>> 2011/6/16 Sergey Beryozkin<sberyozkin@gmail.com**>
>>>
>>> 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
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Angelo zerr <an...@gmail.com>.
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 <ch...@die-schneider.net>
> Am 16.06.2011 14:41, schrieb Angelo zerr:
>
>> 2011/6/16 Sergey Beryozkin<sberyozkin@gmail.com**>
>>
>> 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
>
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Christian Schneider <ch...@die-schneider.net>.
Am 16.06.2011 14:41, schrieb Angelo zerr:
> 2011/6/16 Sergey Beryozkin<sb...@gmail.com>
>
>> Hi
>>
>> Do you agree with the idea of UserPasswordAuthenticationProvider ?
>> 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 UserPasswordAuthenticationProvider 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
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Angelo zerr <an...@gmail.com>.
2011/6/16 Sergey Beryozkin <sb...@gmail.com>
> Hi
>
> Do you agree with the idea of UserPasswordAuthenticationProvider ?
> 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 UserPasswordAuthenticationProvider 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
> Cheers, Sergey
>
>
> On Thu, Jun 16, 2011 at 1:16 PM, Angelo zerr <an...@gmail.com>
> wrote:
> > Hi Sergey and Christian,
> >
> > I would like to know if you need some another informations about my work
> > because I need BasicAuthAuthorizationInterceptor for my project. My code
> > works great with Tomcat (I must test with WebShpere soon).
> > An other advantage to use BasicAuthAuthorizationInterceptor instead of
> > managing with Filter like Christian has suggested me is that I publish my
> > webservice with Endpoint#publish with an URL (ex :
> > http:localhost:8081/services/hello) which is different from the Web
> > Application (ex : http:localhost:8080/mywebapp) by using Embedded Jetty.
> >
> > I will be happy if BasicAuthAuthorizationInterceptor could be integrated
> > into CXF.
> >
> > Regards Angelo
> >
> > 2011/6/15 Christian Schneider <ch...@die-schneider.net>
> >
> >> Am 14.06.2011 23:24, schrieb Sergey Beryozkin:
> >>
> >>
> >>> If we were to go with an interface like this then I'd propose to
> >>> combine the process of accumulating Principal and Roles info which is
> >>> what always happening AFAIK with the real systems. Authentication and
> >>> authorization are more often than not are done at different stages but
> >>> SecurityContext is populated in one go.
> >>>
> >>> Thus I propose:
> >>>
> >>> interface UserPasswordAuthenticationProv**ider {
> >>> SecurityContext authenticate(String userName, String password)
> >>> throws AuthenticationException;
> >>> }
> >>>
> >>> or simply
> >>>
> >>> SecurityContext authenticate(String userName, String password);
> >>>
> >>>
> >> Sounds great. I think the variant without a special exception could be
> >> enough. We can throw a RuntimeException
> >> if the authentication fails. I would say SecurityContext should always
> be
> >> populated completely (no two phases).
> >>
> >> 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
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
Do you agree with the idea of UserPasswordAuthenticationProvider ?
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 UserPasswordAuthenticationProvider and set a non-null
SecurityContext on the current Message.
Cheers, Sergey
On Thu, Jun 16, 2011 at 1:16 PM, Angelo zerr <an...@gmail.com> wrote:
> Hi Sergey and Christian,
>
> I would like to know if you need some another informations about my work
> because I need BasicAuthAuthorizationInterceptor for my project. My code
> works great with Tomcat (I must test with WebShpere soon).
> An other advantage to use BasicAuthAuthorizationInterceptor instead of
> managing with Filter like Christian has suggested me is that I publish my
> webservice with Endpoint#publish with an URL (ex :
> http:localhost:8081/services/hello) which is different from the Web
> Application (ex : http:localhost:8080/mywebapp) by using Embedded Jetty.
>
> I will be happy if BasicAuthAuthorizationInterceptor could be integrated
> into CXF.
>
> Regards Angelo
>
> 2011/6/15 Christian Schneider <ch...@die-schneider.net>
>
>> Am 14.06.2011 23:24, schrieb Sergey Beryozkin:
>>
>>
>>> If we were to go with an interface like this then I'd propose to
>>> combine the process of accumulating Principal and Roles info which is
>>> what always happening AFAIK with the real systems. Authentication and
>>> authorization are more often than not are done at different stages but
>>> SecurityContext is populated in one go.
>>>
>>> Thus I propose:
>>>
>>> interface UserPasswordAuthenticationProv**ider {
>>> SecurityContext authenticate(String userName, String password)
>>> throws AuthenticationException;
>>> }
>>>
>>> or simply
>>>
>>> SecurityContext authenticate(String userName, String password);
>>>
>>>
>> Sounds great. I think the variant without a special exception could be
>> enough. We can throw a RuntimeException
>> if the authentication fails. I would say SecurityContext should always be
>> populated completely (no two phases).
>>
>> 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
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Angelo zerr <an...@gmail.com>.
Hi Sergey and Christian,
I would like to know if you need some another informations about my work
because I need BasicAuthAuthorizationInterceptor for my project. My code
works great with Tomcat (I must test with WebShpere soon).
An other advantage to use BasicAuthAuthorizationInterceptor instead of
managing with Filter like Christian has suggested me is that I publish my
webservice with Endpoint#publish with an URL (ex :
http:localhost:8081/services/hello) which is different from the Web
Application (ex : http:localhost:8080/mywebapp) by using Embedded Jetty.
I will be happy if BasicAuthAuthorizationInterceptor could be integrated
into CXF.
Regards Angelo
2011/6/15 Christian Schneider <ch...@die-schneider.net>
> Am 14.06.2011 23:24, schrieb Sergey Beryozkin:
>
>
>> If we were to go with an interface like this then I'd propose to
>> combine the process of accumulating Principal and Roles info which is
>> what always happening AFAIK with the real systems. Authentication and
>> authorization are more often than not are done at different stages but
>> SecurityContext is populated in one go.
>>
>> Thus I propose:
>>
>> interface UserPasswordAuthenticationProv**ider {
>> SecurityContext authenticate(String userName, String password)
>> throws AuthenticationException;
>> }
>>
>> or simply
>>
>> SecurityContext authenticate(String userName, String password);
>>
>>
> Sounds great. I think the variant without a special exception could be
> enough. We can throw a RuntimeException
> if the authentication fails. I would say SecurityContext should always be
> populated completely (no two phases).
>
> Christian
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Christian Schneider <ch...@die-schneider.net>.
Am 14.06.2011 23:24, schrieb Sergey Beryozkin:
>
> If we were to go with an interface like this then I'd propose to
> combine the process of accumulating Principal and Roles info which is
> what always happening AFAIK with the real systems. Authentication and
> authorization are more often than not are done at different stages but
> SecurityContext is populated in one go.
>
> Thus I propose:
>
> interface UserPasswordAuthenticationProvider {
> SecurityContext authenticate(String userName, String password)
> throws AuthenticationException;
> }
>
> or simply
>
> SecurityContext authenticate(String userName, String password);
>
Sounds great. I think the variant without a special exception could be
enough. We can throw a RuntimeException
if the authentication fails. I would say SecurityContext should always
be populated completely (no two phases).
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Christian
On Tue, Jun 14, 2011 at 6:04 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> I think we can provide an authentication hook in form of an interface that
> people can implement. Like:
>
> interface UserPasswordAuthenticationProvider {
> boolean authenticate(String userName, String password);
> }
>
> This could be called by the interceptor to check the authentication.
>
> We would of course also need a way to gather the roles/groups. Either as a
> list of roles or as a isInGroup callback.
>
> To store the authentication result the DefaultSecurityContext or the
> RolePrefixSecurityContextImpl could be used.
> I don´t think we need to reimplement SecurityContext.
If we were to go with an interface like this then I'd propose to
combine the process of accumulating Principal and Roles info which is
what always happening AFAIK with the real systems. Authentication and
authorization are more often than not are done at different stages but
SecurityContext is populated in one go.
Thus I propose:
interface UserPasswordAuthenticationProvider {
SecurityContext authenticate(String userName, String password)
throws AuthenticationException;
}
or simply
SecurityContext authenticate(String userName, String password);
This is because only a 3rd part Secure manager knows how roles are
represented, and creating (CXF) SecurityContext
is trivial when no roles is available (just use anonymous
SecurityContext with SimplePrincipal helpers) or when roles are
available. Relevant CXF SecurityContext impls are expecting Subjects
which is a collection of SimplePrincipals and/or SimpleGroups. We can
make it a two-step process, such that the 2nd call returns a list of
String roles for ex, but I'm not sure that will make life easier for
implementers, given that at least some systems I know of will
internally return an accumulated result thus implementers will need to
repeat the query or introduce the state of its own
Cheers, Sergey
>
> Christian
>
>
>
> Am 14.06.2011 18:40, schrieb Sergey Beryozkin:
>>
>> I can actually see the source (thanks to Christian for pointing me to
>> it :-)) but I'd like to understand what are you trying to do besides
>> enforcing that BasicAuth is there. I thought you needed to get
>> username& password and get the custom authentication done by
>> interacting somehow with your custom SecurityManager, right ? I'm not
>> sure we can generilize that process in CXF itself, the process of
>> communicating with the custom SecurityManager - JAAS or/and Spring is
>> there for that.
>>
>
> --
> --
> 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
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Christian Schneider <ch...@die-schneider.net>.
I think we can provide an authentication hook in form of an interface
that people can implement. Like:
interface UserPasswordAuthenticationProvider {
boolean authenticate(String userName, String password);
}
This could be called by the interceptor to check the authentication.
We would of course also need a way to gather the roles/groups. Either as
a list of roles or as a isInGroup callback.
To store the authentication result the DefaultSecurityContext or the
RolePrefixSecurityContextImpl could be used.
I don´t think we need to reimplement SecurityContext.
Christian
Am 14.06.2011 18:40, schrieb Sergey Beryozkin:
> I can actually see the source (thanks to Christian for pointing me to
> it :-)) but I'd like to understand what are you trying to do besides
> enforcing that BasicAuth is there. I thought you needed to get
> username& password and get the custom authentication done by
> interacting somehow with your custom SecurityManager, right ? I'm not
> sure we can generilize that process in CXF itself, the process of
> communicating with the custom SecurityManager - JAAS or/and Spring is
> there for that.
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
I can actually see the source (thanks to Christian for pointing me to
it :-)) but I'd like to understand what are you trying to do besides
enforcing that BasicAuth is there. I thought you needed to get
username & password and get the custom authentication done by
interacting somehow with your custom SecurityManager, right ? I'm not
sure we can generilize that process in CXF itself, the process of
communicating with the custom SecurityManager - JAAS or/and Spring is
there for that.
> Can you explain please what BasicAuthAuthorizationInterceptor actually does ?
That is why I asked this question :-)
thanks, Sergey
On Tue, Jun 14, 2011 at 4:50 PM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi
> Can you explain please what BasicAuthAuthorizationInterceptor actually does ?
>
> We really need source of that interceptor, ideally attached as a patch to JIRA
> thanks, Sergey
>
> On Tue, Jun 14, 2011 at 4:23 PM, Angelo zerr <an...@gmail.com> wrote:
>> Hi Sergey,
>>
>> I have attached a zip with my work. It's a WTP Eclipse project where you can
>> find BasicAuthAuthorizationInterceptor in the
>> org.apache.cxf.interceptor.security.basic package.
>> There is a sample with Basic authentification authorization with NO roles :
>>
>> ---------------------------------------------------------
>> <!-- WebServices with Basic Authentification Authorization -->
>> <jaxws:endpoint xmlns:tns="http://server.sample/" id="helloworld"
>> implementor="sample.server.HelloWorld"
>> wsdlLocation="wsdl/helloworld.wsdl"
>> endpointName="tns:HelloWorldPort"
>> serviceName="tns:HelloWorldService"
>> address="/HelloWorldPort">
>> <jaxws:features>
>> <bean class="org.apache.cxf.feature.LoggingFeature" />
>> </jaxws:features>
>> <jaxws:inInterceptors>
>> <ref bean="basicAuthAuthorization1" />
>> </jaxws:inInterceptors>
>> </jaxws:endpoint>
>>
>> <bean id="basicAuthAuthorization1"
>>
>> class="org.apache.cxf.interceptor.security.basic.BasicAuthAuthorizationInterceptor">
>> <property name="realmName" value="MyRealm" />
>> <property name="authorizationContext">
>> <bean
>>
>> class="org.apache.cxf.interceptor.security.basic.SimpleBasicAuthAuthorizationContext">
>> <property name="usersMap">
>> <map>
>> <entry key="ffang" value="pswd" />
>> </map>
>> </property>
>> </bean>
>> </property>
>> </bean>
>> ----------------------------------------------------------
>>
>> And sample with Basic authentification authorization with roles :
>>
>> ----------------------------------------------------------
>>
>> <!-- WebServices with Basic Authentification Authorization + Roles -->
>> <jaxws:endpoint xmlns:tns="http://server.sample/" id="helloworld2"
>> implementor="sample.server.HelloWorld"
>> wsdlLocation="wsdl/helloworld.wsdl"
>> endpointName="tns:HelloWorldPort"
>> serviceName="tns:HelloWorldService"
>> address="/HelloWorldPort2">
>> <jaxws:features>
>> <bean class="org.apache.cxf.feature.LoggingFeature" />
>> </jaxws:features>
>> <jaxws:inInterceptors>
>> <ref bean="basicAuthAuthorization2" />
>> <ref bean="authorizationInterceptor" />
>> </jaxws:inInterceptors>
>> </jaxws:endpoint>
>>
>> <bean id="basicAuthAuthorization2"
>>
>> class="org.apache.cxf.interceptor.security.basic.BasicAuthAuthorizationInterceptor">
>> <property name="realmName" value="MyRealm" />
>> <property name="authorizationContext">
>> <bean
>>
>> class="org.apache.cxf.interceptor.security.basic.SimpleBasicAuthAuthorizationContext">
>> <property name="usersMap">
>> <map>
>> <entry key="ffang" value="pswd" />
>> </map>
>> </property>
>> <property name="userRolesContext">
>> <bean
>>
>> class="org.apache.cxf.interceptor.security.basic.SimpleUserRolesContext">
>> <property name="userRolesMap">
>> <map>
>> <entry key="ffang" value="ROLE1 ROLE2" />
>> </map>
>> </property>
>> </bean>
>> </property>
>> </bean>
>> </property>
>> </bean>
>>
>> <bean id="authorizationInterceptor"
>>
>> class="org.apache.cxf.interceptor.security.SimpleAuthorizingInterceptor">
>> <property name="methodRolesMap">
>> <map>
>> <entry key="hello" value="ROLE1" />
>> </map>
>> </property>
>> </bean>
>> ----------------------------------------------------------
>>
>> If you start your server at localhost 8080 you can launch teh client :
>>
>> * HelloWorld_PortTypeClient which call the first service (with no roles).
>> * HelloWorld_PortTypeClient2 which call the second service (with roles).
>>
>> Everything works with interface and I have implemented with Simple* class
>> which works with Map but you can implements with another mean if you wish.
>>
>> Hope you will like it.
>>
>> Regards Angelo
>> 2011/6/14 Sergey Beryozkin <sb...@gmail.com>
>>>
>>> >
>>> > No problem:) Ok I have implemented this feature. Now I tell me if
>>> > SecurityContext should be implemented (if Principal is null) for Basic
>>> > Interceptor like JAASLoginInterceptor which put a SecurityContext. The
>>> > only
>>> > question is how set roles? But if we do that we could use
>>> > afterSimpleAuthorizingInterceptor
>>>
>>> You can use org.apache.cxf.common.security.SimplePrincipal just to
>>> wrap up a principal name.
>>> DefaultSecurityContext (roles represented as Groups,
>>> org.apache.cxf.common.security.SimpleGroup helper is there) and
>>> RolePrefixSecurityContextImls (role names start with some prefix like
>>> ROLE_) can be used to provide a SecurityContext on a current message.
>>> They all expect a Subject instance which you can easily create with
>>> the help of SimplePrincipal (and SimpleGroup if needed)
>>>
>>> Cheers, Sergey
>>>
>>>
>>> >
>>> > Regards Angelo
>>> >
>>> >
>>> >> On Tue, Jun 14, 2011 at 10:54 AM, Angelo zerr <an...@gmail.com>
>>> >> wrote:
>>> >> > Ok I believe understand your idea about realm. I have added a setter
>>> >> > in
>>> >> my
>>> >> > Interceptor :
>>> >> >
>>> >> > AbstractBasicAuthAuthorizationInterceptor#setRealName(String
>>> >> > realName)
>>> >> which
>>> >> > compute WWW-Authenticate.
>>> >> > Ex : AbstractBasicAuthAuthorizationInterceptor#setRealName("MyRealm")
>>> >> will
>>> >> > returns
>>> >> >
>>> >> > WWW-Authenticate: Basic realm="MyRealm"
>>> >> >
>>> >> > If no realm defined, WWW-Authenticate is not returned. Is that your
>>> >> idea?
>>> >> > WWW-Authenticate is not required? Do you think we should set a
>>> >> > default
>>> >> value
>>> >> > for Realm?
>>> >> >
>>> >> > Regards Angelo
>>> >> >
>>> >> > 2011/6/14 Angelo zerr <an...@gmail.com>
>>> >> >
>>> >> >> Hi Sergey,
>>> >> >>
>>> >> >> 2011/6/14 Sergey Beryozkin <sb...@gmail.com>
>>> >> >>
>>> >> >>> Hi
>>> >> >>>
>>> >> >>> That interceptor should be more neutral, should' not extend a SOAP
>>> >> >>> interceptor.
>>> >> >>>
>>> >> >>
>>> >> >> Ok, I have done like JAASLoginInterceptor (extends
>>> >> >> AbstractPhaseInterceptor<Message> + constructor initialized with
>>> >> >> super(Phase.UNMARSHAL);) and it works.
>>> >> >>
>>> >> >>
>>> >> >>> The other thing you may want to do is to configure it with a realm
>>> >> >>> name and if it's not set then
>>> >> >>> do not add a realm parameter to the response.
>>> >> >>>
>>> >> >>
>>> >> >> Could you explain me more your idea please.
>>> >> >>
>>> >> >>
>>> >> >>>
>>> >> >>> FYI, CXF ships JAASLoginInterceptor - which will check if Basic (or
>>> >> >>> other similar HTTP Authorization type was set)
>>> >> >>> and then will delegate to JAAS to do the actual authentication:
>>> >> >>> http://cxf.apache.org/docs/security.html#Security-Authentication
>>> >> >>>
>>> >> >>> I propose that you create a patch in rt/core,
>>> >> >>> org.apache.cxf.interceptor.security package, that will make it
>>> >> >>> easier
>>> >> >>> for me to move the relevant code to a rt/security module
>>> >> >>>
>>> >> >>
>>> >> >> My first idea is to create a WTP sample application with my code (I
>>> >> >> have
>>> >> >> created org.apache.cxf.interceptor.security.basic package) and send
>>> >> >> you
>>> >> with
>>> >> >> sample which work.
>>> >> >> After I could create a patch if you need.
>>> >> >>
>>> >> >> Regards Angelo
>>> >> >>
>>> >> >>>
>>> >> >>> Thanks, Sergey
>>> >> >>>
>>> >> >>> On Tue, Jun 14, 2011 at 7:38 AM, Angelo zerr
>>> >> >>> <an...@gmail.com>
>>> >> >>> wrote:
>>> >> >>> > Hi Freeman,
>>> >> >>> >
>>> >> >>> > Thank a lot for your answer. I will prepare you a contribution
>>> >> >>> > and
>>> >> send
>>> >> >>> you.
>>> >> >>> >
>>> >> >>> > Regards Angelo
>>> >> >>> >
>>> >> >>> > 2011/6/14 Freeman Fang <fr...@gmail.com>
>>> >> >>> >
>>> >> >>> >> Hi,
>>> >> >>> >>
>>> >> >>> >> Sure, any contribution is welcome.
>>> >> >>> >>
>>> >> >>> >> And in CXF we also can use jetty security handler to enable
>>> >> >>> >> basic
>>> >> auth
>>> >> >>> >> which can configure the realm easily, we have a system testcase
>>> >> >>> >> for
>>> >> >>> it[1],
>>> >> >>> >> you may wanna take a look.
>>> >> >>> >>
>>> >> >>> >> [1]
>>> >> >>> >>
>>> >> >>>
>>> >>
>>> >> https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
>>> >> >>> >> Freeman
>>> >> >>> >>
>>> >> >>> >> On 2011-6-13, at 下午11:34, Angelo zerr wrote:
>>> >> >>> >>
>>> >> >>> >> Hi CXF Team,
>>> >> >>> >>>
>>> >> >>> >>> I would like to manage WebService with HTTP Basic CXF
>>> >> >>> >>> Interceptor
>>> >> and
>>> >> >>> I
>>> >> >>> >>> have
>>> >> >>> >>> not found this interceptor in the CXF. So I have used the great
>>> >> code
>>> >> >>> from
>>> >> >>> >>>
>>> >> >>> >>>
>>> >> >>>
>>> >>
>>> >> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
>>> >> >>> >>> it works great.
>>> >> >>> >>> I have noticed that some projects like
>>> >> >>> >>>
>>> >> >>> >>>
>>> >> >>>
>>> >>
>>> >> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
>>> >> >>> >>> used this code and I tell me why CXF doesn't include the
>>> >> >>> >>> BasicAuthAuthorizationInterceptor class?
>>> >> >>> >>>
>>> >> >>> >>> I have modified BasicAuthAuthorizationInterceptor to delegate
>>> >> >>> >>> user/password
>>> >> >>> >>> to another interface implementation and if you wish I could
>>> >> >>> >>> send
>>> >> you
>>> >> >>> my
>>> >> >>> >>> work
>>> >> >>> >>> and tell to the author of the BasicAuthAuthorizationInterceptor
>>> >> >>> >>> if
>>> >> he
>>> >> >>> is
>>> >> >>> >>> OK
>>> >> >>> >>> to contribute to CXF.
>>> >> >>> >>>
>>> >> >>> >>> Thank a lot for your answer.
>>> >> >>> >>>
>>> >> >>> >>> Regards Angelo
>>> >> >>> >>>
>>> >> >>> >>
>>> >> >>> >> ---------------------------------------------
>>> >> >>> >> Freeman Fang
>>> >> >>> >>
>>> >> >>> >> FuseSource
>>> >> >>> >> Email:ffang@fusesource.com
>>> >> >>> >> Web: fusesource.com
>>> >> >>> >> Twitter: freemanfang
>>> >> >>> >> Blog: http://freemanfang.blogspot.com
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>> >>
>>> >> >>> >
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Sergey Beryozkin
>>> >>
>>> >> Application Integration Division of Talend
>>> >> http://sberyozkin.blogspot.com
>>> >>
>>> >
>>
>>
>
>
>
> --
> Sergey Beryozkin
>
> Application Integration Division of Talend
> http://sberyozkin.blogspot.com
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
Can you explain please what BasicAuthAuthorizationInterceptor actually does ?
We really need source of that interceptor, ideally attached as a patch to JIRA
thanks, Sergey
On Tue, Jun 14, 2011 at 4:23 PM, Angelo zerr <an...@gmail.com> wrote:
> Hi Sergey,
>
> I have attached a zip with my work. It's a WTP Eclipse project where you can
> find BasicAuthAuthorizationInterceptor in the
> org.apache.cxf.interceptor.security.basic package.
> There is a sample with Basic authentification authorization with NO roles :
>
> ---------------------------------------------------------
> <!-- WebServices with Basic Authentification Authorization -->
> <jaxws:endpoint xmlns:tns="http://server.sample/" id="helloworld"
> implementor="sample.server.HelloWorld"
> wsdlLocation="wsdl/helloworld.wsdl"
> endpointName="tns:HelloWorldPort"
> serviceName="tns:HelloWorldService"
> address="/HelloWorldPort">
> <jaxws:features>
> <bean class="org.apache.cxf.feature.LoggingFeature" />
> </jaxws:features>
> <jaxws:inInterceptors>
> <ref bean="basicAuthAuthorization1" />
> </jaxws:inInterceptors>
> </jaxws:endpoint>
>
> <bean id="basicAuthAuthorization1"
>
> class="org.apache.cxf.interceptor.security.basic.BasicAuthAuthorizationInterceptor">
> <property name="realmName" value="MyRealm" />
> <property name="authorizationContext">
> <bean
>
> class="org.apache.cxf.interceptor.security.basic.SimpleBasicAuthAuthorizationContext">
> <property name="usersMap">
> <map>
> <entry key="ffang" value="pswd" />
> </map>
> </property>
> </bean>
> </property>
> </bean>
> ----------------------------------------------------------
>
> And sample with Basic authentification authorization with roles :
>
> ----------------------------------------------------------
>
> <!-- WebServices with Basic Authentification Authorization + Roles -->
> <jaxws:endpoint xmlns:tns="http://server.sample/" id="helloworld2"
> implementor="sample.server.HelloWorld"
> wsdlLocation="wsdl/helloworld.wsdl"
> endpointName="tns:HelloWorldPort"
> serviceName="tns:HelloWorldService"
> address="/HelloWorldPort2">
> <jaxws:features>
> <bean class="org.apache.cxf.feature.LoggingFeature" />
> </jaxws:features>
> <jaxws:inInterceptors>
> <ref bean="basicAuthAuthorization2" />
> <ref bean="authorizationInterceptor" />
> </jaxws:inInterceptors>
> </jaxws:endpoint>
>
> <bean id="basicAuthAuthorization2"
>
> class="org.apache.cxf.interceptor.security.basic.BasicAuthAuthorizationInterceptor">
> <property name="realmName" value="MyRealm" />
> <property name="authorizationContext">
> <bean
>
> class="org.apache.cxf.interceptor.security.basic.SimpleBasicAuthAuthorizationContext">
> <property name="usersMap">
> <map>
> <entry key="ffang" value="pswd" />
> </map>
> </property>
> <property name="userRolesContext">
> <bean
>
> class="org.apache.cxf.interceptor.security.basic.SimpleUserRolesContext">
> <property name="userRolesMap">
> <map>
> <entry key="ffang" value="ROLE1 ROLE2" />
> </map>
> </property>
> </bean>
> </property>
> </bean>
> </property>
> </bean>
>
> <bean id="authorizationInterceptor"
>
> class="org.apache.cxf.interceptor.security.SimpleAuthorizingInterceptor">
> <property name="methodRolesMap">
> <map>
> <entry key="hello" value="ROLE1" />
> </map>
> </property>
> </bean>
> ----------------------------------------------------------
>
> If you start your server at localhost 8080 you can launch teh client :
>
> * HelloWorld_PortTypeClient which call the first service (with no roles).
> * HelloWorld_PortTypeClient2 which call the second service (with roles).
>
> Everything works with interface and I have implemented with Simple* class
> which works with Map but you can implements with another mean if you wish.
>
> Hope you will like it.
>
> Regards Angelo
> 2011/6/14 Sergey Beryozkin <sb...@gmail.com>
>>
>> >
>> > No problem:) Ok I have implemented this feature. Now I tell me if
>> > SecurityContext should be implemented (if Principal is null) for Basic
>> > Interceptor like JAASLoginInterceptor which put a SecurityContext. The
>> > only
>> > question is how set roles? But if we do that we could use
>> > afterSimpleAuthorizingInterceptor
>>
>> You can use org.apache.cxf.common.security.SimplePrincipal just to
>> wrap up a principal name.
>> DefaultSecurityContext (roles represented as Groups,
>> org.apache.cxf.common.security.SimpleGroup helper is there) and
>> RolePrefixSecurityContextImls (role names start with some prefix like
>> ROLE_) can be used to provide a SecurityContext on a current message.
>> They all expect a Subject instance which you can easily create with
>> the help of SimplePrincipal (and SimpleGroup if needed)
>>
>> Cheers, Sergey
>>
>>
>> >
>> > Regards Angelo
>> >
>> >
>> >> On Tue, Jun 14, 2011 at 10:54 AM, Angelo zerr <an...@gmail.com>
>> >> wrote:
>> >> > Ok I believe understand your idea about realm. I have added a setter
>> >> > in
>> >> my
>> >> > Interceptor :
>> >> >
>> >> > AbstractBasicAuthAuthorizationInterceptor#setRealName(String
>> >> > realName)
>> >> which
>> >> > compute WWW-Authenticate.
>> >> > Ex : AbstractBasicAuthAuthorizationInterceptor#setRealName("MyRealm")
>> >> will
>> >> > returns
>> >> >
>> >> > WWW-Authenticate: Basic realm="MyRealm"
>> >> >
>> >> > If no realm defined, WWW-Authenticate is not returned. Is that your
>> >> idea?
>> >> > WWW-Authenticate is not required? Do you think we should set a
>> >> > default
>> >> value
>> >> > for Realm?
>> >> >
>> >> > Regards Angelo
>> >> >
>> >> > 2011/6/14 Angelo zerr <an...@gmail.com>
>> >> >
>> >> >> Hi Sergey,
>> >> >>
>> >> >> 2011/6/14 Sergey Beryozkin <sb...@gmail.com>
>> >> >>
>> >> >>> Hi
>> >> >>>
>> >> >>> That interceptor should be more neutral, should' not extend a SOAP
>> >> >>> interceptor.
>> >> >>>
>> >> >>
>> >> >> Ok, I have done like JAASLoginInterceptor (extends
>> >> >> AbstractPhaseInterceptor<Message> + constructor initialized with
>> >> >> super(Phase.UNMARSHAL);) and it works.
>> >> >>
>> >> >>
>> >> >>> The other thing you may want to do is to configure it with a realm
>> >> >>> name and if it's not set then
>> >> >>> do not add a realm parameter to the response.
>> >> >>>
>> >> >>
>> >> >> Could you explain me more your idea please.
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> FYI, CXF ships JAASLoginInterceptor - which will check if Basic (or
>> >> >>> other similar HTTP Authorization type was set)
>> >> >>> and then will delegate to JAAS to do the actual authentication:
>> >> >>> http://cxf.apache.org/docs/security.html#Security-Authentication
>> >> >>>
>> >> >>> I propose that you create a patch in rt/core,
>> >> >>> org.apache.cxf.interceptor.security package, that will make it
>> >> >>> easier
>> >> >>> for me to move the relevant code to a rt/security module
>> >> >>>
>> >> >>
>> >> >> My first idea is to create a WTP sample application with my code (I
>> >> >> have
>> >> >> created org.apache.cxf.interceptor.security.basic package) and send
>> >> >> you
>> >> with
>> >> >> sample which work.
>> >> >> After I could create a patch if you need.
>> >> >>
>> >> >> Regards Angelo
>> >> >>
>> >> >>>
>> >> >>> Thanks, Sergey
>> >> >>>
>> >> >>> On Tue, Jun 14, 2011 at 7:38 AM, Angelo zerr
>> >> >>> <an...@gmail.com>
>> >> >>> wrote:
>> >> >>> > Hi Freeman,
>> >> >>> >
>> >> >>> > Thank a lot for your answer. I will prepare you a contribution
>> >> >>> > and
>> >> send
>> >> >>> you.
>> >> >>> >
>> >> >>> > Regards Angelo
>> >> >>> >
>> >> >>> > 2011/6/14 Freeman Fang <fr...@gmail.com>
>> >> >>> >
>> >> >>> >> Hi,
>> >> >>> >>
>> >> >>> >> Sure, any contribution is welcome.
>> >> >>> >>
>> >> >>> >> And in CXF we also can use jetty security handler to enable
>> >> >>> >> basic
>> >> auth
>> >> >>> >> which can configure the realm easily, we have a system testcase
>> >> >>> >> for
>> >> >>> it[1],
>> >> >>> >> you may wanna take a look.
>> >> >>> >>
>> >> >>> >> [1]
>> >> >>> >>
>> >> >>>
>> >>
>> >> https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
>> >> >>> >> Freeman
>> >> >>> >>
>> >> >>> >> On 2011-6-13, at 下午11:34, Angelo zerr wrote:
>> >> >>> >>
>> >> >>> >> Hi CXF Team,
>> >> >>> >>>
>> >> >>> >>> I would like to manage WebService with HTTP Basic CXF
>> >> >>> >>> Interceptor
>> >> and
>> >> >>> I
>> >> >>> >>> have
>> >> >>> >>> not found this interceptor in the CXF. So I have used the great
>> >> code
>> >> >>> from
>> >> >>> >>>
>> >> >>> >>>
>> >> >>>
>> >>
>> >> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
>> >> >>> >>> it works great.
>> >> >>> >>> I have noticed that some projects like
>> >> >>> >>>
>> >> >>> >>>
>> >> >>>
>> >>
>> >> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
>> >> >>> >>> used this code and I tell me why CXF doesn't include the
>> >> >>> >>> BasicAuthAuthorizationInterceptor class?
>> >> >>> >>>
>> >> >>> >>> I have modified BasicAuthAuthorizationInterceptor to delegate
>> >> >>> >>> user/password
>> >> >>> >>> to another interface implementation and if you wish I could
>> >> >>> >>> send
>> >> you
>> >> >>> my
>> >> >>> >>> work
>> >> >>> >>> and tell to the author of the BasicAuthAuthorizationInterceptor
>> >> >>> >>> if
>> >> he
>> >> >>> is
>> >> >>> >>> OK
>> >> >>> >>> to contribute to CXF.
>> >> >>> >>>
>> >> >>> >>> Thank a lot for your answer.
>> >> >>> >>>
>> >> >>> >>> Regards Angelo
>> >> >>> >>>
>> >> >>> >>
>> >> >>> >> ---------------------------------------------
>> >> >>> >> Freeman Fang
>> >> >>> >>
>> >> >>> >> FuseSource
>> >> >>> >> Email:ffang@fusesource.com
>> >> >>> >> Web: fusesource.com
>> >> >>> >> Twitter: freemanfang
>> >> >>> >> Blog: http://freemanfang.blogspot.com
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Sergey Beryozkin
>> >>
>> >> Application Integration Division of Talend
>> >> http://sberyozkin.blogspot.com
>> >>
>> >
>
>
--
Sergey Beryozkin
Application Integration Division of Talend
http://sberyozkin.blogspot.com
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Angelo zerr <an...@gmail.com>.
Hi Sergey,
I have attached a zip with my work. It's a WTP Eclipse project where you can
find BasicAuthAuthorizationInterceptor in the
org.apache.cxf.interceptor.security.basic package.
There is a sample with Basic authentification authorization with NO roles :
---------------------------------------------------------
<!-- WebServices with Basic Authentification Authorization -->
<jaxws:endpoint xmlns:tns="http://server.sample/" id="helloworld"
implementor="sample.server.HelloWorld"
wsdlLocation="wsdl/helloworld.wsdl"
endpointName="tns:HelloWorldPort"
serviceName="tns:HelloWorldService"
address="/HelloWorldPort">
<jaxws:features>
<bean class="org.apache.cxf.feature.LoggingFeature" />
</jaxws:features>
<jaxws:inInterceptors>
<ref bean="basicAuthAuthorization1" />
</jaxws:inInterceptors>
</jaxws:endpoint>
<bean id="basicAuthAuthorization1"
class="org.apache.cxf.interceptor.security.basic.BasicAuthAuthorizationInterceptor">
<property name="realmName" value="MyRealm" />
<property name="authorizationContext">
<bean
class="org.apache.cxf.interceptor.security.basic.SimpleBasicAuthAuthorizationContext">
<property name="usersMap">
<map>
<entry key="ffang" value="pswd" />
</map>
</property>
</bean>
</property>
</bean>
----------------------------------------------------------
And sample with Basic authentification authorization with roles :
----------------------------------------------------------
<!-- WebServices with Basic Authentification Authorization + Roles -->
<jaxws:endpoint xmlns:tns="http://server.sample/" id="helloworld2"
implementor="sample.server.HelloWorld"
wsdlLocation="wsdl/helloworld.wsdl"
endpointName="tns:HelloWorldPort"
serviceName="tns:HelloWorldService"
address="/HelloWorldPort2">
<jaxws:features>
<bean class="org.apache.cxf.feature.LoggingFeature" />
</jaxws:features>
<jaxws:inInterceptors>
<ref bean="basicAuthAuthorization2" />
<ref bean="authorizationInterceptor" />
</jaxws:inInterceptors>
</jaxws:endpoint>
<bean id="basicAuthAuthorization2"
class="org.apache.cxf.interceptor.security.basic.BasicAuthAuthorizationInterceptor">
<property name="realmName" value="MyRealm" />
<property name="authorizationContext">
<bean
class="org.apache.cxf.interceptor.security.basic.SimpleBasicAuthAuthorizationContext">
<property name="usersMap">
<map>
<entry key="ffang" value="pswd" />
</map>
</property>
<property name="userRolesContext">
<bean
class="org.apache.cxf.interceptor.security.basic.SimpleUserRolesContext">
<property name="userRolesMap">
<map>
<entry key="ffang" value="ROLE1 ROLE2" />
</map>
</property>
</bean>
</property>
</bean>
</property>
</bean>
<bean id="authorizationInterceptor"
class="org.apache.cxf.interceptor.security.SimpleAuthorizingInterceptor">
<property name="methodRolesMap">
<map>
<entry key="hello" value="ROLE1" />
</map>
</property>
</bean>
----------------------------------------------------------
If you start your server at localhost 8080 you can launch teh client :
* HelloWorld_PortTypeClient which call the first service (with no roles).
* HelloWorld_PortTypeClient2 which call the second service (with roles).
Everything works with interface and I have implemented with Simple* class
which works with Map but you can implements with another mean if you wish.
Hope you will like it.
Regards Angelo
2011/6/14 Sergey Beryozkin <sb...@gmail.com>
> >
> > No problem:) Ok I have implemented this feature. Now I tell me if
> > SecurityContext should be implemented (if Principal is null) for Basic
> > Interceptor like JAASLoginInterceptor which put a SecurityContext. The
> only
> > question is how set roles? But if we do that we could use
> > afterSimpleAuthorizingInterceptor
>
> You can use org.apache.cxf.common.security.SimplePrincipal just to
> wrap up a principal name.
> DefaultSecurityContext (roles represented as Groups,
> org.apache.cxf.common.security.SimpleGroup helper is there) and
> RolePrefixSecurityContextImls (role names start with some prefix like
> ROLE_) can be used to provide a SecurityContext on a current message.
> They all expect a Subject instance which you can easily create with
> the help of SimplePrincipal (and SimpleGroup if needed)
>
> Cheers, Sergey
>
>
> >
> > Regards Angelo
> >
> >
> >> On Tue, Jun 14, 2011 at 10:54 AM, Angelo zerr <an...@gmail.com>
> >> wrote:
> >> > Ok I believe understand your idea about realm. I have added a setter
> in
> >> my
> >> > Interceptor :
> >> >
> >> > AbstractBasicAuthAuthorizationInterceptor#setRealName(String realName)
> >> which
> >> > compute WWW-Authenticate.
> >> > Ex : AbstractBasicAuthAuthorizationInterceptor#setRealName("MyRealm")
> >> will
> >> > returns
> >> >
> >> > WWW-Authenticate: Basic realm="MyRealm"
> >> >
> >> > If no realm defined, WWW-Authenticate is not returned. Is that your
> >> idea?
> >> > WWW-Authenticate is not required? Do you think we should set a default
> >> value
> >> > for Realm?
> >> >
> >> > Regards Angelo
> >> >
> >> > 2011/6/14 Angelo zerr <an...@gmail.com>
> >> >
> >> >> Hi Sergey,
> >> >>
> >> >> 2011/6/14 Sergey Beryozkin <sb...@gmail.com>
> >> >>
> >> >>> Hi
> >> >>>
> >> >>> That interceptor should be more neutral, should' not extend a SOAP
> >> >>> interceptor.
> >> >>>
> >> >>
> >> >> Ok, I have done like JAASLoginInterceptor (extends
> >> >> AbstractPhaseInterceptor<Message> + constructor initialized with
> >> >> super(Phase.UNMARSHAL);) and it works.
> >> >>
> >> >>
> >> >>> The other thing you may want to do is to configure it with a realm
> >> >>> name and if it's not set then
> >> >>> do not add a realm parameter to the response.
> >> >>>
> >> >>
> >> >> Could you explain me more your idea please.
> >> >>
> >> >>
> >> >>>
> >> >>> FYI, CXF ships JAASLoginInterceptor - which will check if Basic (or
> >> >>> other similar HTTP Authorization type was set)
> >> >>> and then will delegate to JAAS to do the actual authentication:
> >> >>> http://cxf.apache.org/docs/security.html#Security-Authentication
> >> >>>
> >> >>> I propose that you create a patch in rt/core,
> >> >>> org.apache.cxf.interceptor.security package, that will make it
> easier
> >> >>> for me to move the relevant code to a rt/security module
> >> >>>
> >> >>
> >> >> My first idea is to create a WTP sample application with my code (I
> have
> >> >> created org.apache.cxf.interceptor.security.basic package) and send
> you
> >> with
> >> >> sample which work.
> >> >> After I could create a patch if you need.
> >> >>
> >> >> Regards Angelo
> >> >>
> >> >>>
> >> >>> Thanks, Sergey
> >> >>>
> >> >>> On Tue, Jun 14, 2011 at 7:38 AM, Angelo zerr <angelo.zerr@gmail.com
> >
> >> >>> wrote:
> >> >>> > Hi Freeman,
> >> >>> >
> >> >>> > Thank a lot for your answer. I will prepare you a contribution and
> >> send
> >> >>> you.
> >> >>> >
> >> >>> > Regards Angelo
> >> >>> >
> >> >>> > 2011/6/14 Freeman Fang <fr...@gmail.com>
> >> >>> >
> >> >>> >> Hi,
> >> >>> >>
> >> >>> >> Sure, any contribution is welcome.
> >> >>> >>
> >> >>> >> And in CXF we also can use jetty security handler to enable basic
> >> auth
> >> >>> >> which can configure the realm easily, we have a system testcase
> for
> >> >>> it[1],
> >> >>> >> you may wanna take a look.
> >> >>> >>
> >> >>> >> [1]
> >> >>> >>
> >> >>>
> >>
> https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
> >> >>> >> Freeman
> >> >>> >>
> >> >>> >> On 2011-6-13, at 下午11:34, Angelo zerr wrote:
> >> >>> >>
> >> >>> >> Hi CXF Team,
> >> >>> >>>
> >> >>> >>> I would like to manage WebService with HTTP Basic CXF
> Interceptor
> >> and
> >> >>> I
> >> >>> >>> have
> >> >>> >>> not found this interceptor in the CXF. So I have used the great
> >> code
> >> >>> from
> >> >>> >>>
> >> >>> >>>
> >> >>>
> >>
> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
> >> >>> >>> it works great.
> >> >>> >>> I have noticed that some projects like
> >> >>> >>>
> >> >>> >>>
> >> >>>
> >>
> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
> >> >>> >>> used this code and I tell me why CXF doesn't include the
> >> >>> >>> BasicAuthAuthorizationInterceptor class?
> >> >>> >>>
> >> >>> >>> I have modified BasicAuthAuthorizationInterceptor to delegate
> >> >>> >>> user/password
> >> >>> >>> to another interface implementation and if you wish I could send
> >> you
> >> >>> my
> >> >>> >>> work
> >> >>> >>> and tell to the author of the BasicAuthAuthorizationInterceptor
> if
> >> he
> >> >>> is
> >> >>> >>> OK
> >> >>> >>> to contribute to CXF.
> >> >>> >>>
> >> >>> >>> Thank a lot for your answer.
> >> >>> >>>
> >> >>> >>> Regards Angelo
> >> >>> >>>
> >> >>> >>
> >> >>> >> ---------------------------------------------
> >> >>> >> Freeman Fang
> >> >>> >>
> >> >>> >> FuseSource
> >> >>> >> Email:ffang@fusesource.com
> >> >>> >> Web: fusesource.com
> >> >>> >> Twitter: freemanfang
> >> >>> >> Blog: http://freemanfang.blogspot.com
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >
> >> >>>
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> Sergey Beryozkin
> >>
> >> Application Integration Division of Talend
> >> http://sberyozkin.blogspot.com
> >>
> >
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
>
> No problem:) Ok I have implemented this feature. Now I tell me if
> SecurityContext should be implemented (if Principal is null) for Basic
> Interceptor like JAASLoginInterceptor which put a SecurityContext. The only
> question is how set roles? But if we do that we could use
> afterSimpleAuthorizingInterceptor
You can use org.apache.cxf.common.security.SimplePrincipal just to
wrap up a principal name.
DefaultSecurityContext (roles represented as Groups,
org.apache.cxf.common.security.SimpleGroup helper is there) and
RolePrefixSecurityContextImls (role names start with some prefix like
ROLE_) can be used to provide a SecurityContext on a current message.
They all expect a Subject instance which you can easily create with
the help of SimplePrincipal (and SimpleGroup if needed)
Cheers, Sergey
>
> Regards Angelo
>
>
>> On Tue, Jun 14, 2011 at 10:54 AM, Angelo zerr <an...@gmail.com>
>> wrote:
>> > Ok I believe understand your idea about realm. I have added a setter in
>> my
>> > Interceptor :
>> >
>> > AbstractBasicAuthAuthorizationInterceptor#setRealName(String realName)
>> which
>> > compute WWW-Authenticate.
>> > Ex : AbstractBasicAuthAuthorizationInterceptor#setRealName("MyRealm")
>> will
>> > returns
>> >
>> > WWW-Authenticate: Basic realm="MyRealm"
>> >
>> > If no realm defined, WWW-Authenticate is not returned. Is that your
>> idea?
>> > WWW-Authenticate is not required? Do you think we should set a default
>> value
>> > for Realm?
>> >
>> > Regards Angelo
>> >
>> > 2011/6/14 Angelo zerr <an...@gmail.com>
>> >
>> >> Hi Sergey,
>> >>
>> >> 2011/6/14 Sergey Beryozkin <sb...@gmail.com>
>> >>
>> >>> Hi
>> >>>
>> >>> That interceptor should be more neutral, should' not extend a SOAP
>> >>> interceptor.
>> >>>
>> >>
>> >> Ok, I have done like JAASLoginInterceptor (extends
>> >> AbstractPhaseInterceptor<Message> + constructor initialized with
>> >> super(Phase.UNMARSHAL);) and it works.
>> >>
>> >>
>> >>> The other thing you may want to do is to configure it with a realm
>> >>> name and if it's not set then
>> >>> do not add a realm parameter to the response.
>> >>>
>> >>
>> >> Could you explain me more your idea please.
>> >>
>> >>
>> >>>
>> >>> FYI, CXF ships JAASLoginInterceptor - which will check if Basic (or
>> >>> other similar HTTP Authorization type was set)
>> >>> and then will delegate to JAAS to do the actual authentication:
>> >>> http://cxf.apache.org/docs/security.html#Security-Authentication
>> >>>
>> >>> I propose that you create a patch in rt/core,
>> >>> org.apache.cxf.interceptor.security package, that will make it easier
>> >>> for me to move the relevant code to a rt/security module
>> >>>
>> >>
>> >> My first idea is to create a WTP sample application with my code (I have
>> >> created org.apache.cxf.interceptor.security.basic package) and send you
>> with
>> >> sample which work.
>> >> After I could create a patch if you need.
>> >>
>> >> Regards Angelo
>> >>
>> >>>
>> >>> Thanks, Sergey
>> >>>
>> >>> On Tue, Jun 14, 2011 at 7:38 AM, Angelo zerr <an...@gmail.com>
>> >>> wrote:
>> >>> > Hi Freeman,
>> >>> >
>> >>> > Thank a lot for your answer. I will prepare you a contribution and
>> send
>> >>> you.
>> >>> >
>> >>> > Regards Angelo
>> >>> >
>> >>> > 2011/6/14 Freeman Fang <fr...@gmail.com>
>> >>> >
>> >>> >> Hi,
>> >>> >>
>> >>> >> Sure, any contribution is welcome.
>> >>> >>
>> >>> >> And in CXF we also can use jetty security handler to enable basic
>> auth
>> >>> >> which can configure the realm easily, we have a system testcase for
>> >>> it[1],
>> >>> >> you may wanna take a look.
>> >>> >>
>> >>> >> [1]
>> >>> >>
>> >>>
>> https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
>> >>> >> Freeman
>> >>> >>
>> >>> >> On 2011-6-13, at 下午11:34, Angelo zerr wrote:
>> >>> >>
>> >>> >> Hi CXF Team,
>> >>> >>>
>> >>> >>> I would like to manage WebService with HTTP Basic CXF Interceptor
>> and
>> >>> I
>> >>> >>> have
>> >>> >>> not found this interceptor in the CXF. So I have used the great
>> code
>> >>> from
>> >>> >>>
>> >>> >>>
>> >>>
>> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
>> >>> >>> it works great.
>> >>> >>> I have noticed that some projects like
>> >>> >>>
>> >>> >>>
>> >>>
>> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
>> >>> >>> used this code and I tell me why CXF doesn't include the
>> >>> >>> BasicAuthAuthorizationInterceptor class?
>> >>> >>>
>> >>> >>> I have modified BasicAuthAuthorizationInterceptor to delegate
>> >>> >>> user/password
>> >>> >>> to another interface implementation and if you wish I could send
>> you
>> >>> my
>> >>> >>> work
>> >>> >>> and tell to the author of the BasicAuthAuthorizationInterceptor if
>> he
>> >>> is
>> >>> >>> OK
>> >>> >>> to contribute to CXF.
>> >>> >>>
>> >>> >>> Thank a lot for your answer.
>> >>> >>>
>> >>> >>> Regards Angelo
>> >>> >>>
>> >>> >>
>> >>> >> ---------------------------------------------
>> >>> >> Freeman Fang
>> >>> >>
>> >>> >> FuseSource
>> >>> >> Email:ffang@fusesource.com
>> >>> >> Web: fusesource.com
>> >>> >> Twitter: freemanfang
>> >>> >> Blog: http://freemanfang.blogspot.com
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Application Integration Division of Talend
>> http://sberyozkin.blogspot.com
>>
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Angelo zerr <an...@gmail.com>.
2011/6/14 Sergey Beryozkin <sb...@gmail.com>
> Hi Angelo, sorry for a delay, yes, that what I meant
>
No problem:) Ok I have implemented this feature. Now I tell me if
SecurityContext should be implemented (if Principal is null) for Basic
Interceptor like JAASLoginInterceptor which put a SecurityContext. The only
question is how set roles? But if we do that we could use
afterSimpleAuthorizingInterceptor
Regards Angelo
> On Tue, Jun 14, 2011 at 10:54 AM, Angelo zerr <an...@gmail.com>
> wrote:
> > Ok I believe understand your idea about realm. I have added a setter in
> my
> > Interceptor :
> >
> > AbstractBasicAuthAuthorizationInterceptor#setRealName(String realName)
> which
> > compute WWW-Authenticate.
> > Ex : AbstractBasicAuthAuthorizationInterceptor#setRealName("MyRealm")
> will
> > returns
> >
> > WWW-Authenticate: Basic realm="MyRealm"
> >
> > If no realm defined, WWW-Authenticate is not returned. Is that your
> idea?
> > WWW-Authenticate is not required? Do you think we should set a default
> value
> > for Realm?
> >
> > Regards Angelo
> >
> > 2011/6/14 Angelo zerr <an...@gmail.com>
> >
> >> Hi Sergey,
> >>
> >> 2011/6/14 Sergey Beryozkin <sb...@gmail.com>
> >>
> >>> Hi
> >>>
> >>> That interceptor should be more neutral, should' not extend a SOAP
> >>> interceptor.
> >>>
> >>
> >> Ok, I have done like JAASLoginInterceptor (extends
> >> AbstractPhaseInterceptor<Message> + constructor initialized with
> >> super(Phase.UNMARSHAL);) and it works.
> >>
> >>
> >>> The other thing you may want to do is to configure it with a realm
> >>> name and if it's not set then
> >>> do not add a realm parameter to the response.
> >>>
> >>
> >> Could you explain me more your idea please.
> >>
> >>
> >>>
> >>> FYI, CXF ships JAASLoginInterceptor - which will check if Basic (or
> >>> other similar HTTP Authorization type was set)
> >>> and then will delegate to JAAS to do the actual authentication:
> >>> http://cxf.apache.org/docs/security.html#Security-Authentication
> >>>
> >>> I propose that you create a patch in rt/core,
> >>> org.apache.cxf.interceptor.security package, that will make it easier
> >>> for me to move the relevant code to a rt/security module
> >>>
> >>
> >> My first idea is to create a WTP sample application with my code (I have
> >> created org.apache.cxf.interceptor.security.basic package) and send you
> with
> >> sample which work.
> >> After I could create a patch if you need.
> >>
> >> Regards Angelo
> >>
> >>>
> >>> Thanks, Sergey
> >>>
> >>> On Tue, Jun 14, 2011 at 7:38 AM, Angelo zerr <an...@gmail.com>
> >>> wrote:
> >>> > Hi Freeman,
> >>> >
> >>> > Thank a lot for your answer. I will prepare you a contribution and
> send
> >>> you.
> >>> >
> >>> > Regards Angelo
> >>> >
> >>> > 2011/6/14 Freeman Fang <fr...@gmail.com>
> >>> >
> >>> >> Hi,
> >>> >>
> >>> >> Sure, any contribution is welcome.
> >>> >>
> >>> >> And in CXF we also can use jetty security handler to enable basic
> auth
> >>> >> which can configure the realm easily, we have a system testcase for
> >>> it[1],
> >>> >> you may wanna take a look.
> >>> >>
> >>> >> [1]
> >>> >>
> >>>
> https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
> >>> >> Freeman
> >>> >>
> >>> >> On 2011-6-13, at 下午11:34, Angelo zerr wrote:
> >>> >>
> >>> >> Hi CXF Team,
> >>> >>>
> >>> >>> I would like to manage WebService with HTTP Basic CXF Interceptor
> and
> >>> I
> >>> >>> have
> >>> >>> not found this interceptor in the CXF. So I have used the great
> code
> >>> from
> >>> >>>
> >>> >>>
> >>>
> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
> >>> >>> it works great.
> >>> >>> I have noticed that some projects like
> >>> >>>
> >>> >>>
> >>>
> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
> >>> >>> used this code and I tell me why CXF doesn't include the
> >>> >>> BasicAuthAuthorizationInterceptor class?
> >>> >>>
> >>> >>> I have modified BasicAuthAuthorizationInterceptor to delegate
> >>> >>> user/password
> >>> >>> to another interface implementation and if you wish I could send
> you
> >>> my
> >>> >>> work
> >>> >>> and tell to the author of the BasicAuthAuthorizationInterceptor if
> he
> >>> is
> >>> >>> OK
> >>> >>> to contribute to CXF.
> >>> >>>
> >>> >>> Thank a lot for your answer.
> >>> >>>
> >>> >>> Regards Angelo
> >>> >>>
> >>> >>
> >>> >> ---------------------------------------------
> >>> >> Freeman Fang
> >>> >>
> >>> >> FuseSource
> >>> >> Email:ffang@fusesource.com
> >>> >> Web: fusesource.com
> >>> >> Twitter: freemanfang
> >>> >> Blog: http://freemanfang.blogspot.com
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >
> >>>
> >>
> >>
> >
>
>
>
> --
> Sergey Beryozkin
>
> Application Integration Division of Talend
> http://sberyozkin.blogspot.com
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Angelo, sorry for a delay, yes, that what I meant
Cheers, Sergey
On Tue, Jun 14, 2011 at 10:54 AM, Angelo zerr <an...@gmail.com> wrote:
> Ok I believe understand your idea about realm. I have added a setter in my
> Interceptor :
>
> AbstractBasicAuthAuthorizationInterceptor#setRealName(String realName) which
> compute WWW-Authenticate.
> Ex : AbstractBasicAuthAuthorizationInterceptor#setRealName("MyRealm") will
> returns
>
> WWW-Authenticate: Basic realm="MyRealm"
>
> If no realm defined, WWW-Authenticate is not returned. Is that your idea?
> WWW-Authenticate is not required? Do you think we should set a default value
> for Realm?
>
> Regards Angelo
>
> 2011/6/14 Angelo zerr <an...@gmail.com>
>
>> Hi Sergey,
>>
>> 2011/6/14 Sergey Beryozkin <sb...@gmail.com>
>>
>>> Hi
>>>
>>> That interceptor should be more neutral, should' not extend a SOAP
>>> interceptor.
>>>
>>
>> Ok, I have done like JAASLoginInterceptor (extends
>> AbstractPhaseInterceptor<Message> + constructor initialized with
>> super(Phase.UNMARSHAL);) and it works.
>>
>>
>>> The other thing you may want to do is to configure it with a realm
>>> name and if it's not set then
>>> do not add a realm parameter to the response.
>>>
>>
>> Could you explain me more your idea please.
>>
>>
>>>
>>> FYI, CXF ships JAASLoginInterceptor - which will check if Basic (or
>>> other similar HTTP Authorization type was set)
>>> and then will delegate to JAAS to do the actual authentication:
>>> http://cxf.apache.org/docs/security.html#Security-Authentication
>>>
>>> I propose that you create a patch in rt/core,
>>> org.apache.cxf.interceptor.security package, that will make it easier
>>> for me to move the relevant code to a rt/security module
>>>
>>
>> My first idea is to create a WTP sample application with my code (I have
>> created org.apache.cxf.interceptor.security.basic package) and send you with
>> sample which work.
>> After I could create a patch if you need.
>>
>> Regards Angelo
>>
>>>
>>> Thanks, Sergey
>>>
>>> On Tue, Jun 14, 2011 at 7:38 AM, Angelo zerr <an...@gmail.com>
>>> wrote:
>>> > Hi Freeman,
>>> >
>>> > Thank a lot for your answer. I will prepare you a contribution and send
>>> you.
>>> >
>>> > Regards Angelo
>>> >
>>> > 2011/6/14 Freeman Fang <fr...@gmail.com>
>>> >
>>> >> Hi,
>>> >>
>>> >> Sure, any contribution is welcome.
>>> >>
>>> >> And in CXF we also can use jetty security handler to enable basic auth
>>> >> which can configure the realm easily, we have a system testcase for
>>> it[1],
>>> >> you may wanna take a look.
>>> >>
>>> >> [1]
>>> >>
>>> https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
>>> >> Freeman
>>> >>
>>> >> On 2011-6-13, at 下午11:34, Angelo zerr wrote:
>>> >>
>>> >> Hi CXF Team,
>>> >>>
>>> >>> I would like to manage WebService with HTTP Basic CXF Interceptor and
>>> I
>>> >>> have
>>> >>> not found this interceptor in the CXF. So I have used the great code
>>> from
>>> >>>
>>> >>>
>>> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
>>> >>> it works great.
>>> >>> I have noticed that some projects like
>>> >>>
>>> >>>
>>> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
>>> >>> used this code and I tell me why CXF doesn't include the
>>> >>> BasicAuthAuthorizationInterceptor class?
>>> >>>
>>> >>> I have modified BasicAuthAuthorizationInterceptor to delegate
>>> >>> user/password
>>> >>> to another interface implementation and if you wish I could send you
>>> my
>>> >>> work
>>> >>> and tell to the author of the BasicAuthAuthorizationInterceptor if he
>>> is
>>> >>> OK
>>> >>> to contribute to CXF.
>>> >>>
>>> >>> Thank a lot for your answer.
>>> >>>
>>> >>> Regards Angelo
>>> >>>
>>> >>
>>> >> ---------------------------------------------
>>> >> Freeman Fang
>>> >>
>>> >> FuseSource
>>> >> Email:ffang@fusesource.com
>>> >> Web: fusesource.com
>>> >> Twitter: freemanfang
>>> >> Blog: http://freemanfang.blogspot.com
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>
>>
>
--
Sergey Beryozkin
Application Integration Division of Talend
http://sberyozkin.blogspot.com
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Angelo zerr <an...@gmail.com>.
Ok I believe understand your idea about realm. I have added a setter in my
Interceptor :
AbstractBasicAuthAuthorizationInterceptor#setRealName(String realName) which
compute WWW-Authenticate.
Ex : AbstractBasicAuthAuthorizationInterceptor#setRealName("MyRealm") will
returns
WWW-Authenticate: Basic realm="MyRealm"
If no realm defined, WWW-Authenticate is not returned. Is that your idea?
WWW-Authenticate is not required? Do you think we should set a default value
for Realm?
Regards Angelo
2011/6/14 Angelo zerr <an...@gmail.com>
> Hi Sergey,
>
> 2011/6/14 Sergey Beryozkin <sb...@gmail.com>
>
>> Hi
>>
>> That interceptor should be more neutral, should' not extend a SOAP
>> interceptor.
>>
>
> Ok, I have done like JAASLoginInterceptor (extends
> AbstractPhaseInterceptor<Message> + constructor initialized with
> super(Phase.UNMARSHAL);) and it works.
>
>
>> The other thing you may want to do is to configure it with a realm
>> name and if it's not set then
>> do not add a realm parameter to the response.
>>
>
> Could you explain me more your idea please.
>
>
>>
>> FYI, CXF ships JAASLoginInterceptor - which will check if Basic (or
>> other similar HTTP Authorization type was set)
>> and then will delegate to JAAS to do the actual authentication:
>> http://cxf.apache.org/docs/security.html#Security-Authentication
>>
>> I propose that you create a patch in rt/core,
>> org.apache.cxf.interceptor.security package, that will make it easier
>> for me to move the relevant code to a rt/security module
>>
>
> My first idea is to create a WTP sample application with my code (I have
> created org.apache.cxf.interceptor.security.basic package) and send you with
> sample which work.
> After I could create a patch if you need.
>
> Regards Angelo
>
>>
>> Thanks, Sergey
>>
>> On Tue, Jun 14, 2011 at 7:38 AM, Angelo zerr <an...@gmail.com>
>> wrote:
>> > Hi Freeman,
>> >
>> > Thank a lot for your answer. I will prepare you a contribution and send
>> you.
>> >
>> > Regards Angelo
>> >
>> > 2011/6/14 Freeman Fang <fr...@gmail.com>
>> >
>> >> Hi,
>> >>
>> >> Sure, any contribution is welcome.
>> >>
>> >> And in CXF we also can use jetty security handler to enable basic auth
>> >> which can configure the realm easily, we have a system testcase for
>> it[1],
>> >> you may wanna take a look.
>> >>
>> >> [1]
>> >>
>> https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
>> >> Freeman
>> >>
>> >> On 2011-6-13, at 下午11:34, Angelo zerr wrote:
>> >>
>> >> Hi CXF Team,
>> >>>
>> >>> I would like to manage WebService with HTTP Basic CXF Interceptor and
>> I
>> >>> have
>> >>> not found this interceptor in the CXF. So I have used the great code
>> from
>> >>>
>> >>>
>> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
>> >>> it works great.
>> >>> I have noticed that some projects like
>> >>>
>> >>>
>> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
>> >>> used this code and I tell me why CXF doesn't include the
>> >>> BasicAuthAuthorizationInterceptor class?
>> >>>
>> >>> I have modified BasicAuthAuthorizationInterceptor to delegate
>> >>> user/password
>> >>> to another interface implementation and if you wish I could send you
>> my
>> >>> work
>> >>> and tell to the author of the BasicAuthAuthorizationInterceptor if he
>> is
>> >>> OK
>> >>> to contribute to CXF.
>> >>>
>> >>> Thank a lot for your answer.
>> >>>
>> >>> Regards Angelo
>> >>>
>> >>
>> >> ---------------------------------------------
>> >> Freeman Fang
>> >>
>> >> FuseSource
>> >> Email:ffang@fusesource.com
>> >> Web: fusesource.com
>> >> Twitter: freemanfang
>> >> Blog: http://freemanfang.blogspot.com
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>>
>
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Angelo zerr <an...@gmail.com>.
Hi Sergey,
2011/6/14 Sergey Beryozkin <sb...@gmail.com>
> Hi
>
> That interceptor should be more neutral, should' not extend a SOAP
> interceptor.
>
Ok, I have done like JAASLoginInterceptor (extends
AbstractPhaseInterceptor<Message> + constructor initialized with
super(Phase.UNMARSHAL);) and it works.
> The other thing you may want to do is to configure it with a realm
> name and if it's not set then
> do not add a realm parameter to the response.
>
Could you explain me more your idea please.
>
> FYI, CXF ships JAASLoginInterceptor - which will check if Basic (or
> other similar HTTP Authorization type was set)
> and then will delegate to JAAS to do the actual authentication:
> http://cxf.apache.org/docs/security.html#Security-Authentication
>
> I propose that you create a patch in rt/core,
> org.apache.cxf.interceptor.security package, that will make it easier
> for me to move the relevant code to a rt/security module
>
My first idea is to create a WTP sample application with my code (I have
created org.apache.cxf.interceptor.security.basic package) and send you with
sample which work.
After I could create a patch if you need.
Regards Angelo
>
> Thanks, Sergey
>
> On Tue, Jun 14, 2011 at 7:38 AM, Angelo zerr <an...@gmail.com>
> wrote:
> > Hi Freeman,
> >
> > Thank a lot for your answer. I will prepare you a contribution and send
> you.
> >
> > Regards Angelo
> >
> > 2011/6/14 Freeman Fang <fr...@gmail.com>
> >
> >> Hi,
> >>
> >> Sure, any contribution is welcome.
> >>
> >> And in CXF we also can use jetty security handler to enable basic auth
> >> which can configure the realm easily, we have a system testcase for
> it[1],
> >> you may wanna take a look.
> >>
> >> [1]
> >>
> https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
> >> Freeman
> >>
> >> On 2011-6-13, at 下午11:34, Angelo zerr wrote:
> >>
> >> Hi CXF Team,
> >>>
> >>> I would like to manage WebService with HTTP Basic CXF Interceptor and I
> >>> have
> >>> not found this interceptor in the CXF. So I have used the great code
> from
> >>>
> >>>
> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
> >>> it works great.
> >>> I have noticed that some projects like
> >>>
> >>>
> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
> >>> used this code and I tell me why CXF doesn't include the
> >>> BasicAuthAuthorizationInterceptor class?
> >>>
> >>> I have modified BasicAuthAuthorizationInterceptor to delegate
> >>> user/password
> >>> to another interface implementation and if you wish I could send you my
> >>> work
> >>> and tell to the author of the BasicAuthAuthorizationInterceptor if he
> is
> >>> OK
> >>> to contribute to CXF.
> >>>
> >>> Thank a lot for your answer.
> >>>
> >>> Regards Angelo
> >>>
> >>
> >> ---------------------------------------------
> >> Freeman Fang
> >>
> >> FuseSource
> >> Email:ffang@fusesource.com
> >> Web: fusesource.com
> >> Twitter: freemanfang
> >> Blog: http://freemanfang.blogspot.com
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
That interceptor should be more neutral, should' not extend a SOAP interceptor.
The other thing you may want to do is to configure it with a realm
name and if it's not set then
do not add a realm parameter to the response.
FYI, CXF ships JAASLoginInterceptor - which will check if Basic (or
other similar HTTP Authorization type was set)
and then will delegate to JAAS to do the actual authentication:
http://cxf.apache.org/docs/security.html#Security-Authentication
I propose that you create a patch in rt/core,
org.apache.cxf.interceptor.security package, that will make it easier
for me to move the relevant code to a rt/security module
Thanks, Sergey
On Tue, Jun 14, 2011 at 7:38 AM, Angelo zerr <an...@gmail.com> wrote:
> Hi Freeman,
>
> Thank a lot for your answer. I will prepare you a contribution and send you.
>
> Regards Angelo
>
> 2011/6/14 Freeman Fang <fr...@gmail.com>
>
>> Hi,
>>
>> Sure, any contribution is welcome.
>>
>> And in CXF we also can use jetty security handler to enable basic auth
>> which can configure the realm easily, we have a system testcase for it[1],
>> you may wanna take a look.
>>
>> [1]
>> https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
>> Freeman
>>
>> On 2011-6-13, at 下午11:34, Angelo zerr wrote:
>>
>> Hi CXF Team,
>>>
>>> I would like to manage WebService with HTTP Basic CXF Interceptor and I
>>> have
>>> not found this interceptor in the CXF. So I have used the great code from
>>>
>>> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
>>> it works great.
>>> I have noticed that some projects like
>>>
>>> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
>>> used this code and I tell me why CXF doesn't include the
>>> BasicAuthAuthorizationInterceptor class?
>>>
>>> I have modified BasicAuthAuthorizationInterceptor to delegate
>>> user/password
>>> to another interface implementation and if you wish I could send you my
>>> work
>>> and tell to the author of the BasicAuthAuthorizationInterceptor if he is
>>> OK
>>> to contribute to CXF.
>>>
>>> Thank a lot for your answer.
>>>
>>> Regards Angelo
>>>
>>
>> ---------------------------------------------
>> Freeman Fang
>>
>> FuseSource
>> Email:ffang@fusesource.com
>> Web: fusesource.com
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Angelo zerr <an...@gmail.com>.
Hi Freeman,
Thank a lot for your answer. I will prepare you a contribution and send you.
Regards Angelo
2011/6/14 Freeman Fang <fr...@gmail.com>
> Hi,
>
> Sure, any contribution is welcome.
>
> And in CXF we also can use jetty security handler to enable basic auth
> which can configure the realm easily, we have a system testcase for it[1],
> you may wanna take a look.
>
> [1]
> https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
> Freeman
>
> On 2011-6-13, at 下午11:34, Angelo zerr wrote:
>
> Hi CXF Team,
>>
>> I would like to manage WebService with HTTP Basic CXF Interceptor and I
>> have
>> not found this interceptor in the CXF. So I have used the great code from
>>
>> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
>> it works great.
>> I have noticed that some projects like
>>
>> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
>> used this code and I tell me why CXF doesn't include the
>> BasicAuthAuthorizationInterceptor class?
>>
>> I have modified BasicAuthAuthorizationInterceptor to delegate
>> user/password
>> to another interface implementation and if you wish I could send you my
>> work
>> and tell to the author of the BasicAuthAuthorizationInterceptor if he is
>> OK
>> to contribute to CXF.
>>
>> Thank a lot for your answer.
>>
>> Regards Angelo
>>
>
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
Sure, any contribution is welcome.
And in CXF we also can use jetty security handler to enable basic auth
which can configure the realm easily, we have a system testcase for
it[1], you may wanna take a look.
[1]https://svn.apache.org/repos/asf/cxf/trunk/systests/transports/src/test/java/org/apache/cxf/systest/http_jetty/JettyBasicAuthTest.java
Freeman
On 2011-6-13, at 下午11:34, Angelo zerr wrote:
> Hi CXF Team,
>
> I would like to manage WebService with HTTP Basic CXF Interceptor
> and I have
> not found this interceptor in the CXF. So I have used the great code
> from
> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
> it works great.
> I have noticed that some projects like
> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
> used this code and I tell me why CXF doesn't include the
> BasicAuthAuthorizationInterceptor class?
>
> I have modified BasicAuthAuthorizationInterceptor to delegate user/
> password
> to another interface implementation and if you wish I could send you
> my work
> and tell to the author of the BasicAuthAuthorizationInterceptor if
> he is OK
> to contribute to CXF.
>
> Thank a lot for your answer.
>
> Regards Angelo
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Angelo zerr <an...@gmail.com>.
Hi Christian,
I understand your idea but in our case there is user/password per
webservices. Manage authentication with a CXF Interceptor is easy because
each there is an instance of Basic Interceptor per webservice instance. The
idea is to customize user/password for a webservice with an HTML form which
update a DB. We could too ignore the security if we wish.
With Filter I must retrieve the Webservice instance, with CXF interceptor I
delegate user/password to my webservice wrapper.
Regards Angelo
2011/6/14 Christian Schneider <ch...@die-schneider.net>
> Hi Angelo,
>
> In this case you probably really need to code it. What you might try is to
> implement authentication and authorization as servlet filters. So they would
> not only be available to cxf but to also to all your other software and even
> static files.
>
> I also thought about writing a server side authentication / authorization
> module for cxf some time ago and wondered if it was possible to do based on
> filters. The authorization would simply have to block the request if it is
> forbidden. In case of basic auth you would not even have to set the
> authenticated principal for cxf as it could take it from the basic auth info
> like it already does.
>
> Christian
>
>
> Am 14.06.2011 12:29, schrieb Angelo zerr:
>
> Hi Christian ,
>>
>> Thank a lot for your information. In my case I'm using Tomcat and
>> WebSphere
>> but Authentification must be delegate to our own security manager. That's
>> why I need to manage basic autnetification. I don't use Spring to publish
>> my
>> webservice (just with Java code with Endpoint#publish).
>>
>> Regards Angelo
>>
>> 2011/6/14 Christian Schneider<ch...@die-schneider.net>
>>
>>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Angelo,
In this case you probably really need to code it. What you might try is
to implement authentication and authorization as servlet filters. So
they would not only be available to cxf but to also to all your other
software and even static files.
I also thought about writing a server side authentication /
authorization module for cxf some time ago and wondered if it was
possible to do based on filters. The authorization would simply have to
block the request if it is forbidden. In case of basic auth you would
not even have to set the authenticated principal for cxf as it could
take it from the basic auth info like it already does.
Christian
Am 14.06.2011 12:29, schrieb Angelo zerr:
> Hi Christian ,
>
> Thank a lot for your information. In my case I'm using Tomcat and WebSphere
> but Authentification must be delegate to our own security manager. That's
> why I need to manage basic autnetification. I don't use Spring to publish my
> webservice (just with Java code with Endpoint#publish).
>
> Regards Angelo
>
> 2011/6/14 Christian Schneider<ch...@die-schneider.net>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Angelo zerr <an...@gmail.com>.
Hi Christian ,
Thank a lot for your information. In my case I'm using Tomcat and WebSphere
but Authentification must be delegate to our own security manager. That's
why I need to manage basic autnetification. I don't use Spring to publish my
webservice (just with Java code with Endpoint#publish).
Regards Angelo
2011/6/14 Christian Schneider <ch...@die-schneider.net>
> Hi Angelo,
>
> do you run your service in Tomcat or standalone? If you run in tomcat or
> any similar servlet container you can setup authnentication and
> authorization using the container. Then CXF
> will fetch the authenticated principal which you can use in CXF. For
> example you can combine this with spring security to do role based
> authentication on method level. If you only need authentication based on the
> url of the endpoint then the features of the container are often even
> enough.
>
> So for many use cases you don´t need a special interceptor.
>
> We have an example how to secure a cxf service using camel and spring
> security in the Talend Integration Factory examples:
> https://github.com/Talend/tif/tree/master/examples/spring-security
>
> Like said this example also includes camel so it is not exactly what you
> want but I think it can be adapted to use cxf only. The main thing is simply
> to make sure the spring security authentication is done and to wire in the
> processing of jsr 250 annotations.
>
> This does the spring authentication:
>
> <filter>
> <filter-name>springSecurityFilterChain</filter-name>
>
> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
> </filter>
> <filter-mapping>
> <filter-name>springSecurityFilterChain</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
>
>
> This enables annotation processing by spring:
>
> <global-method-security jsr250-annotations="enabled" xmlns="
> http://www.springframework.org/schema/security"/>
>
>
>
> Best regards
>
> Christian
>
>
> Am 13.06.2011 17:34, schrieb Angelo zerr:
>
> Hi CXF Team,
>>
>> I would like to manage WebService with HTTP Basic CXF Interceptor and I
>> have
>> not found this interceptor in the CXF. So I have used the great code from
>>
>> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
>> it works great.
>> I have noticed that some projects like
>>
>> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
>> used this code and I tell me why CXF doesn't include the
>> BasicAuthAuthorizationInterceptor class?
>>
>> I have modified BasicAuthAuthorizationInterceptor to delegate
>> user/password
>> to another interface implementation and if you wish I could send you my
>> work
>> and tell to the author of the BasicAuthAuthorizationInterceptor if he is
>> OK
>> to contribute to CXF.
>>
>> Thank a lot for your answer.
>>
>> Regards Angelo
>>
>>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
Re: HTTP Basic CXF Interceptor with BasicAuthAuthorizationInterceptor
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Angelo,
do you run your service in Tomcat or standalone? If you run in tomcat or
any similar servlet container you can setup authnentication and
authorization using the container. Then CXF
will fetch the authenticated principal which you can use in CXF. For
example you can combine this with spring security to do role based
authentication on method level. If you only need authentication based on
the url of the endpoint then the features of the container are often
even enough.
So for many use cases you don´t need a special interceptor.
We have an example how to secure a cxf service using camel and spring
security in the Talend Integration Factory examples:
https://github.com/Talend/tif/tree/master/examples/spring-security
Like said this example also includes camel so it is not exactly what you
want but I think it can be adapted to use cxf only. The main thing is
simply to make sure the spring security authentication is done and to
wire in the processing of jsr 250 annotations.
This does the spring authentication:
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
This enables annotation processing by spring:
<global-method-security jsr250-annotations="enabled" xmlns="http://www.springframework.org/schema/security"/>
Best regards
Christian
Am 13.06.2011 17:34, schrieb Angelo zerr:
> Hi CXF Team,
>
> I would like to manage WebService with HTTP Basic CXF Interceptor and I have
> not found this interceptor in the CXF. So I have used the great code from
> http://chrisdail.com/2008/03/31/apache-cxf-with-http-basic-authentication/and
> it works great.
> I have noticed that some projects like
> http://code.google.com/p/fenius/source/browse/trunk/fenius-util/src/main/java/is/glif/fenius/util/BasicAuthAuthorizationInterceptor.java?r=111have
> used this code and I tell me why CXF doesn't include the
> BasicAuthAuthorizationInterceptor class?
>
> I have modified BasicAuthAuthorizationInterceptor to delegate user/password
> to another interface implementation and if you wish I could send you my work
> and tell to the author of the BasicAuthAuthorizationInterceptor if he is OK
> to contribute to CXF.
>
> Thank a lot for your answer.
>
> Regards Angelo
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com