You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Konrad Windszus <ko...@netcentric.biz> on 2016/10/17 07:45:35 UTC
JAX-RS Client implementing a challenge/response authentication
I want to call a ReST web service with a JAX-RS client based on CXF. That web service has a custom authentication based on cookies and challenge/response authentication. To get authenticated (i.e. whenever a regular call returns a 401) a dedicated GET request must be issued to get the challenge, and then an additional POST request to authenticate the user (and get back an authentication token as cookie). Instead of doing the authentication explicitly I would rather call that whenever necessary (to also deal with cases where previous authentication became invalid), i.e. as Interceptor or as Filter. The question is, how do I retrigger the original request once the user has been successfully authenticated in a ClientResponseFilter or Interceptor in case a 401?
Has someone ever implemented something like this?
Thanks,
Konrad
Re: JAX-RS Client implementing a challenge/response authentication
Posted by Sergey Beryozkin <sb...@gmail.com>.
May be I can add a property to support authorization retransmits without
WWW-Authenticate
Sergey
On 25/10/16 12:42, Sergey Beryozkin wrote:
> Well, WWW-Authenticate is there to indicate to the client that the
> Authorization needs to be completed, this is standard HTTP. 401 alone
> can mean anything, for example, the client password or user name may be
> wrong, or the server can use 401 for some other reasons related to the
> access of some of its resources (may be instead of 403).
> At least with WWW-Authenticate CXF can try to generalize
> and support various involved schemes.
>
> HttpConduit.handleRetransmits() will trigger processRetransmit, you may
> need to return 'true' from you you custom supplier's
> requiresRequestCaching().
>
> Cheers, Sergey
>
> On 25/10/16 12:23, Konrad Windszus wrote:
>> I do have the issue that WrappedOutputStream.processRetransmit is not
>> even triggered, so it does not even reach the authorizationRetransmit
>> method. What might be the issue here?
>>
>>> On 25 Oct 2016, at 13:12, Konrad Windszus <ko...@gmx.de> wrote:
>>>
>>> This is a 3rd party server I unfortunately cannot influence.
>>> Any way to to modify the WWW-Authorize handling in CXF?
>>> Where is the piece of code being responsible for triggering the
>>> retransmit evaluating the WWW-Authorize header?
>>>
>>> Thanks,
>>> Konrad
>>>> On 25 Oct 2016, at 12:23, Sergey Beryozkin <sb...@gmail.com>
>>>> wrote:
>>>>
>>>> Hi
>>>>
>>>> Why can't the server return WWW-Authenticate ?
>>>>
>>>> Cheers, Sergey
>>>> On 25/10/16 11:04, Konrad Windszus wrote:
>>>>> Thanks for that tip. Unfortunately my custom HttpAuthSupplier is
>>>>> only called once (before the request is triggered). No matter
>>>>> whether I return null or the empty string in my getAuthorization
>>>>> method my HttpAuthSupplier is not called a second time. The reason
>>>>> is that the underlying close method on the HTTPConduit is never
>>>>> called, therefore handleRetransmits on the WrappedOutputStream is
>>>>> never called.
>>>>> What am I doing wrong?
>>>>> In my case there is no WWW-Authorize response header being used but
>>>>> just a plain 401 status to indicate that authentication should be
>>>>> triggered.
>>>>> Internally I am using a JAX-RS Client proxy which always fails with
>>>>> javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
>>>>> at
>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>>>> at
>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>>>>
>>>>> at
>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>>>
>>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>>>> at
>>>>> org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException(AbstractClient.java:504)
>>>>>
>>>>> at
>>>>> org.apache.cxf.jaxrs.client.ClientProxyImpl.checkResponse(ClientProxyImpl.java:314)
>>>>>
>>>>> at
>>>>> org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:793)
>>>>>
>>>>> at
>>>>> org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:755)
>>>>>
>>>>> at
>>>>> org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228)
>>>>>
>>>>> ...
>>>>>
>>>>> Thanks for any help,
>>>>> Konrad
>>>>>
>>>>>
>>>>>> On 19 Oct 2016, at 12:32, Sergey Beryozkin <sb...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> AFAIK, CXF HttpConduit will attempt a re-transmit if 401 is
>>>>>> returned and a custom CXF HttpAuthSupplier is registered.
>>>>>>
>>>>>> For example, see
>>>>>>
>>>>>> https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/client/BearerAuthSupplier.java
>>>>>>
>>>>>>
>>>>>> In your custom supplier you'd override:
>>>>>> public String getAuthorization(AuthorizationPolicy authPolicy,
>>>>>> URI currentURI,
>>>>>> Message message,
>>>>>> String fullHeader) {}
>>>>>>
>>>>>> perhaps you'd do the extra calls inside this method before
>>>>>> returning the final Authorization value for the original request
>>>>>> to continue
>>>>>>
>>>>>> Sergey
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 17/10/16 08:45, Konrad Windszus wrote:
>>>>>>> I want to call a ReST web service with a JAX-RS client based on
>>>>>>> CXF. That web service has a custom authentication based on
>>>>>>> cookies and challenge/response authentication. To get
>>>>>>> authenticated (i.e. whenever a regular call returns a 401) a
>>>>>>> dedicated GET request must be issued to get the challenge, and
>>>>>>> then an additional POST request to authenticate the user (and get
>>>>>>> back an authentication token as cookie). Instead of doing the
>>>>>>> authentication explicitly I would rather call that whenever
>>>>>>> necessary (to also deal with cases where previous authentication
>>>>>>> became invalid), i.e. as Interceptor or as Filter. The question
>>>>>>> is, how do I retrigger the original request once the user has
>>>>>>> been successfully authenticated in a ClientResponseFilter or
>>>>>>> Interceptor in case a 401?
>>>>>>> Has someone ever implemented something like this?
>>>>>>> Thanks,
>>>>>>> Konrad
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sergey Beryozkin
>>>>>>
>>>>>> Talend Community Coders
>>>>>> http://coders.talend.com/
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: JAX-RS Client implementing a challenge/response authentication
Posted by Sergey Beryozkin <sb...@gmail.com>.
Well, WWW-Authenticate is there to indicate to the client that the
Authorization needs to be completed, this is standard HTTP. 401 alone
can mean anything, for example, the client password or user name may be
wrong, or the server can use 401 for some other reasons related to the
access of some of its resources (may be instead of 403).
At least with WWW-Authenticate CXF can try to generalize
and support various involved schemes.
HttpConduit.handleRetransmits() will trigger processRetransmit, you may
need to return 'true' from you you custom supplier's
requiresRequestCaching().
Cheers, Sergey
On 25/10/16 12:23, Konrad Windszus wrote:
> I do have the issue that WrappedOutputStream.processRetransmit is not even triggered, so it does not even reach the authorizationRetransmit method. What might be the issue here?
>
>> On 25 Oct 2016, at 13:12, Konrad Windszus <ko...@gmx.de> wrote:
>>
>> This is a 3rd party server I unfortunately cannot influence.
>> Any way to to modify the WWW-Authorize handling in CXF?
>> Where is the piece of code being responsible for triggering the retransmit evaluating the WWW-Authorize header?
>>
>> Thanks,
>> Konrad
>>> On 25 Oct 2016, at 12:23, Sergey Beryozkin <sb...@gmail.com> wrote:
>>>
>>> Hi
>>>
>>> Why can't the server return WWW-Authenticate ?
>>>
>>> Cheers, Sergey
>>> On 25/10/16 11:04, Konrad Windszus wrote:
>>>> Thanks for that tip. Unfortunately my custom HttpAuthSupplier is only called once (before the request is triggered). No matter whether I return null or the empty string in my getAuthorization method my HttpAuthSupplier is not called a second time. The reason is that the underlying close method on the HTTPConduit is never called, therefore handleRetransmits on the WrappedOutputStream is never called.
>>>> What am I doing wrong?
>>>> In my case there is no WWW-Authorize response header being used but just a plain 401 status to indicate that authentication should be triggered.
>>>> Internally I am using a JAX-RS Client proxy which always fails with
>>>> javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>>> at org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException(AbstractClient.java:504)
>>>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.checkResponse(ClientProxyImpl.java:314)
>>>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:793)
>>>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:755)
>>>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228)
>>>> ...
>>>>
>>>> Thanks for any help,
>>>> Konrad
>>>>
>>>>
>>>>> On 19 Oct 2016, at 12:32, Sergey Beryozkin <sb...@gmail.com> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> AFAIK, CXF HttpConduit will attempt a re-transmit if 401 is returned and a custom CXF HttpAuthSupplier is registered.
>>>>>
>>>>> For example, see
>>>>>
>>>>> https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/client/BearerAuthSupplier.java
>>>>>
>>>>> In your custom supplier you'd override:
>>>>> public String getAuthorization(AuthorizationPolicy authPolicy,
>>>>> URI currentURI,
>>>>> Message message,
>>>>> String fullHeader) {}
>>>>>
>>>>> perhaps you'd do the extra calls inside this method before returning the final Authorization value for the original request to continue
>>>>>
>>>>> Sergey
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 17/10/16 08:45, Konrad Windszus wrote:
>>>>>> I want to call a ReST web service with a JAX-RS client based on CXF. That web service has a custom authentication based on cookies and challenge/response authentication. To get authenticated (i.e. whenever a regular call returns a 401) a dedicated GET request must be issued to get the challenge, and then an additional POST request to authenticate the user (and get back an authentication token as cookie). Instead of doing the authentication explicitly I would rather call that whenever necessary (to also deal with cases where previous authentication became invalid), i.e. as Interceptor or as Filter. The question is, how do I retrigger the original request once the user has been successfully authenticated in a ClientResponseFilter or Interceptor in case a 401?
>>>>>> Has someone ever implemented something like this?
>>>>>> Thanks,
>>>>>> Konrad
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sergey Beryozkin
>>>>>
>>>>> Talend Community Coders
>>>>> http://coders.talend.com/
>>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> Talend Community Coders
>>> http://coders.talend.com/
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: JAX-RS Client implementing a challenge/response authentication
Posted by Konrad Windszus <ko...@gmx.de>.
I do have the issue that WrappedOutputStream.processRetransmit is not even triggered, so it does not even reach the authorizationRetransmit method. What might be the issue here?
> On 25 Oct 2016, at 13:12, Konrad Windszus <ko...@gmx.de> wrote:
>
> This is a 3rd party server I unfortunately cannot influence.
> Any way to to modify the WWW-Authorize handling in CXF?
> Where is the piece of code being responsible for triggering the retransmit evaluating the WWW-Authorize header?
>
> Thanks,
> Konrad
>> On 25 Oct 2016, at 12:23, Sergey Beryozkin <sb...@gmail.com> wrote:
>>
>> Hi
>>
>> Why can't the server return WWW-Authenticate ?
>>
>> Cheers, Sergey
>> On 25/10/16 11:04, Konrad Windszus wrote:
>>> Thanks for that tip. Unfortunately my custom HttpAuthSupplier is only called once (before the request is triggered). No matter whether I return null or the empty string in my getAuthorization method my HttpAuthSupplier is not called a second time. The reason is that the underlying close method on the HTTPConduit is never called, therefore handleRetransmits on the WrappedOutputStream is never called.
>>> What am I doing wrong?
>>> In my case there is no WWW-Authorize response header being used but just a plain 401 status to indicate that authentication should be triggered.
>>> Internally I am using a JAX-RS Client proxy which always fails with
>>> javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>>> at org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException(AbstractClient.java:504)
>>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.checkResponse(ClientProxyImpl.java:314)
>>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:793)
>>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:755)
>>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228)
>>> ...
>>>
>>> Thanks for any help,
>>> Konrad
>>>
>>>
>>>> On 19 Oct 2016, at 12:32, Sergey Beryozkin <sb...@gmail.com> wrote:
>>>>
>>>> Hi
>>>>
>>>> AFAIK, CXF HttpConduit will attempt a re-transmit if 401 is returned and a custom CXF HttpAuthSupplier is registered.
>>>>
>>>> For example, see
>>>>
>>>> https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/client/BearerAuthSupplier.java
>>>>
>>>> In your custom supplier you'd override:
>>>> public String getAuthorization(AuthorizationPolicy authPolicy,
>>>> URI currentURI,
>>>> Message message,
>>>> String fullHeader) {}
>>>>
>>>> perhaps you'd do the extra calls inside this method before returning the final Authorization value for the original request to continue
>>>>
>>>> Sergey
>>>>
>>>>
>>>>
>>>>
>>>> On 17/10/16 08:45, Konrad Windszus wrote:
>>>>> I want to call a ReST web service with a JAX-RS client based on CXF. That web service has a custom authentication based on cookies and challenge/response authentication. To get authenticated (i.e. whenever a regular call returns a 401) a dedicated GET request must be issued to get the challenge, and then an additional POST request to authenticate the user (and get back an authentication token as cookie). Instead of doing the authentication explicitly I would rather call that whenever necessary (to also deal with cases where previous authentication became invalid), i.e. as Interceptor or as Filter. The question is, how do I retrigger the original request once the user has been successfully authenticated in a ClientResponseFilter or Interceptor in case a 401?
>>>>> Has someone ever implemented something like this?
>>>>> Thanks,
>>>>> Konrad
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>
Re: JAX-RS Client implementing a challenge/response authentication
Posted by Konrad Windszus <ko...@gmx.de>.
This is a 3rd party server I unfortunately cannot influence.
Any way to to modify the WWW-Authorize handling in CXF?
Where is the piece of code being responsible for triggering the retransmit evaluating the WWW-Authorize header?
Thanks,
Konrad
> On 25 Oct 2016, at 12:23, Sergey Beryozkin <sb...@gmail.com> wrote:
>
> Hi
>
> Why can't the server return WWW-Authenticate ?
>
> Cheers, Sergey
> On 25/10/16 11:04, Konrad Windszus wrote:
>> Thanks for that tip. Unfortunately my custom HttpAuthSupplier is only called once (before the request is triggered). No matter whether I return null or the empty string in my getAuthorization method my HttpAuthSupplier is not called a second time. The reason is that the underlying close method on the HTTPConduit is never called, therefore handleRetransmits on the WrappedOutputStream is never called.
>> What am I doing wrong?
>> In my case there is no WWW-Authorize response header being used but just a plain 401 status to indicate that authentication should be triggered.
>> Internally I am using a JAX-RS Client proxy which always fails with
>> javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> at org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException(AbstractClient.java:504)
>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.checkResponse(ClientProxyImpl.java:314)
>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:793)
>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:755)
>> at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228)
>> ...
>>
>> Thanks for any help,
>> Konrad
>>
>>
>>> On 19 Oct 2016, at 12:32, Sergey Beryozkin <sb...@gmail.com> wrote:
>>>
>>> Hi
>>>
>>> AFAIK, CXF HttpConduit will attempt a re-transmit if 401 is returned and a custom CXF HttpAuthSupplier is registered.
>>>
>>> For example, see
>>>
>>> https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/client/BearerAuthSupplier.java
>>>
>>> In your custom supplier you'd override:
>>> public String getAuthorization(AuthorizationPolicy authPolicy,
>>> URI currentURI,
>>> Message message,
>>> String fullHeader) {}
>>>
>>> perhaps you'd do the extra calls inside this method before returning the final Authorization value for the original request to continue
>>>
>>> Sergey
>>>
>>>
>>>
>>>
>>> On 17/10/16 08:45, Konrad Windszus wrote:
>>>> I want to call a ReST web service with a JAX-RS client based on CXF. That web service has a custom authentication based on cookies and challenge/response authentication. To get authenticated (i.e. whenever a regular call returns a 401) a dedicated GET request must be issued to get the challenge, and then an additional POST request to authenticate the user (and get back an authentication token as cookie). Instead of doing the authentication explicitly I would rather call that whenever necessary (to also deal with cases where previous authentication became invalid), i.e. as Interceptor or as Filter. The question is, how do I retrigger the original request once the user has been successfully authenticated in a ClientResponseFilter or Interceptor in case a 401?
>>>> Has someone ever implemented something like this?
>>>> Thanks,
>>>> Konrad
>>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> Talend Community Coders
>>> http://coders.talend.com/
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
Re: JAX-RS Client implementing a challenge/response authentication
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
Why can't the server return WWW-Authenticate ?
Cheers, Sergey
On 25/10/16 11:04, Konrad Windszus wrote:
> Thanks for that tip. Unfortunately my custom HttpAuthSupplier is only called once (before the request is triggered). No matter whether I return null or the empty string in my getAuthorization method my HttpAuthSupplier is not called a second time. The reason is that the underlying close method on the HTTPConduit is never called, therefore handleRetransmits on the WrappedOutputStream is never called.
> What am I doing wrong?
> In my case there is no WWW-Authorize response header being used but just a plain 401 status to indicate that authentication should be triggered.
> Internally I am using a JAX-RS Client proxy which always fails with
> javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException(AbstractClient.java:504)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.checkResponse(ClientProxyImpl.java:314)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:793)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:755)
> at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228)
> ...
>
> Thanks for any help,
> Konrad
>
>
>> On 19 Oct 2016, at 12:32, Sergey Beryozkin <sb...@gmail.com> wrote:
>>
>> Hi
>>
>> AFAIK, CXF HttpConduit will attempt a re-transmit if 401 is returned and a custom CXF HttpAuthSupplier is registered.
>>
>> For example, see
>>
>> https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/client/BearerAuthSupplier.java
>>
>> In your custom supplier you'd override:
>> public String getAuthorization(AuthorizationPolicy authPolicy,
>> URI currentURI,
>> Message message,
>> String fullHeader) {}
>>
>> perhaps you'd do the extra calls inside this method before returning the final Authorization value for the original request to continue
>>
>> Sergey
>>
>>
>>
>>
>> On 17/10/16 08:45, Konrad Windszus wrote:
>>> I want to call a ReST web service with a JAX-RS client based on CXF. That web service has a custom authentication based on cookies and challenge/response authentication. To get authenticated (i.e. whenever a regular call returns a 401) a dedicated GET request must be issued to get the challenge, and then an additional POST request to authenticate the user (and get back an authentication token as cookie). Instead of doing the authentication explicitly I would rather call that whenever necessary (to also deal with cases where previous authentication became invalid), i.e. as Interceptor or as Filter. The question is, how do I retrigger the original request once the user has been successfully authenticated in a ClientResponseFilter or Interceptor in case a 401?
>>> Has someone ever implemented something like this?
>>> Thanks,
>>> Konrad
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: JAX-RS Client implementing a challenge/response authentication
Posted by Konrad Windszus <ko...@gmx.de>.
Thanks for that tip. Unfortunately my custom HttpAuthSupplier is only called once (before the request is triggered). No matter whether I return null or the empty string in my getAuthorization method my HttpAuthSupplier is not called a second time. The reason is that the underlying close method on the HTTPConduit is never called, therefore handleRetransmits on the WrappedOutputStream is never called.
What am I doing wrong?
In my case there is no WWW-Authorize response header being used but just a plain 401 status to indicate that authentication should be triggered.
Internally I am using a JAX-RS Client proxy which always fails with
javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException(AbstractClient.java:504)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.checkResponse(ClientProxyImpl.java:314)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:793)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:755)
at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228)
...
Thanks for any help,
Konrad
> On 19 Oct 2016, at 12:32, Sergey Beryozkin <sb...@gmail.com> wrote:
>
> Hi
>
> AFAIK, CXF HttpConduit will attempt a re-transmit if 401 is returned and a custom CXF HttpAuthSupplier is registered.
>
> For example, see
>
> https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/client/BearerAuthSupplier.java
>
> In your custom supplier you'd override:
> public String getAuthorization(AuthorizationPolicy authPolicy,
> URI currentURI,
> Message message,
> String fullHeader) {}
>
> perhaps you'd do the extra calls inside this method before returning the final Authorization value for the original request to continue
>
> Sergey
>
>
>
>
> On 17/10/16 08:45, Konrad Windszus wrote:
>> I want to call a ReST web service with a JAX-RS client based on CXF. That web service has a custom authentication based on cookies and challenge/response authentication. To get authenticated (i.e. whenever a regular call returns a 401) a dedicated GET request must be issued to get the challenge, and then an additional POST request to authenticate the user (and get back an authentication token as cookie). Instead of doing the authentication explicitly I would rather call that whenever necessary (to also deal with cases where previous authentication became invalid), i.e. as Interceptor or as Filter. The question is, how do I retrigger the original request once the user has been successfully authenticated in a ClientResponseFilter or Interceptor in case a 401?
>> Has someone ever implemented something like this?
>> Thanks,
>> Konrad
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
Re: JAX-RS Client implementing a challenge/response authentication
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
AFAIK, CXF HttpConduit will attempt a re-transmit if 401 is returned and
a custom CXF HttpAuthSupplier is registered.
For example, see
https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/client/BearerAuthSupplier.java
In your custom supplier you'd override:
public String getAuthorization(AuthorizationPolicy authPolicy,
URI currentURI,
Message message,
String fullHeader) {}
perhaps you'd do the extra calls inside this method before returning the
final Authorization value for the original request to continue
Sergey
On 17/10/16 08:45, Konrad Windszus wrote:
> I want to call a ReST web service with a JAX-RS client based on CXF. That web service has a custom authentication based on cookies and challenge/response authentication. To get authenticated (i.e. whenever a regular call returns a 401) a dedicated GET request must be issued to get the challenge, and then an additional POST request to authenticate the user (and get back an authentication token as cookie). Instead of doing the authentication explicitly I would rather call that whenever necessary (to also deal with cases where previous authentication became invalid), i.e. as Interceptor or as Filter. The question is, how do I retrigger the original request once the user has been successfully authenticated in a ClientResponseFilter or Interceptor in case a 401?
> Has someone ever implemented something like this?
> Thanks,
> Konrad
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/