cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: JAX-RS Client implementing a challenge/response authentication
Date Tue, 25 Oct 2016 12:39:32 GMT
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 <konrad_w@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 <sberyozkin@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 <sberyozkin@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/

Mime
View raw message