You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Gabo Manuel <km...@solegysystems.com> on 2008/10/27 09:35:00 UTC
Re: [JAX-RS][AuthorizationPolicy]Http Digest Authentication support?
Hi All,
After reading up more re: Http Basic, finally found why it is so. Final
revision of questions:
I modified Chris Dail's sample interceptor such that the challenge would be
WWW-Authenticate: Digest realm=feefactor, nonce=1225096289125
When the client re-submits request with the Digest details, e.g.:
Authorization: Digest username="myUserName", realm="feefactor",
nonce="1225096289125", uri="/cxf/services/rest/Accounts/Account/1",
response="0808b59f915736b53da883b32c39c306"
the following code still renders policy as null:
AuthorizationPolicy policy = message.get(AuthorizationPolicy.class)
I checked the received headers using the following code:
logger.info("Protocol headers: " + message.get(Message.PROTOCOL_HEADERS));
and Authorization is there:
[InHandler] | Protocol headers: {host=[localhost:8081],
Authorization=[Digest username="myUserName", realm="feefactor",
nonce="1225096289125", uri="/cxf/services/rest/Accounts/Account/1",
response="0808b59f915736b53da883b32c39c306"], user-agent=[Jakarta
Commons-HttpClient/3.1]}
Am I missing something?
Gabo
Re: [JAX-RS][AuthorizationPolicy]Http Digest Authentication support?
Posted by Sergey Beryozkin <se...@progress.com>.
By the way, this is how you access it directly from a message :
org.apache.cxf.security.SecurityContext sc = msg.get(SecurityContext.class);
sc.getUserPrincipal();
There's also a JAXRS SecurityContext, but it can only be injected either into the application resource class or JAXRS message body
providers.
Cheers, Sergey
> Hi Gabo
>
> CXF has interceptors, and JAXRS input processing is implemented in a CXF input interceptor (JAXRSInInterceptor, currently sitting
> at stage PRE_STREAM). JAXRSInInterceptor itself invokes on a chain of RequestHandlers which are interceptors too, but they're only
> recognized by JAXRSInInterceptor and they have an interface different to CXF Interceptor interface (which is what
> JAXRSInInterceptor implements) and RequestHandlers has currently no notion of phases, they're executed in scope of the
> JAXRSInInterceptor invocation.
>
> You were asking Dan about phases, so I'm assuming you're trying to get a Proncipal object from a CXF interceptor (that is, not
> from a JAXRS RequestFilter) ?
>
> Is it correct ?
>
> Cheers, Sergey
>
>> Hi Sergey,
>>
>> PRE_INVOKE does not help.
>>
>> I'm a bit lost with regards to the filter. I checked the user's guide, it just talks about Request and ResponseHandlers, which I
>> am already implementing.. am I missing something?
>>
>> Gabo
>>
>> Sergey Beryozkin wrote:
>>> Hi
>>>
>>> Perhaps PRE_INVOKE can do ?
>>> You can also try to get to this Principal object from a JAX-RS RequestHandler filter...
>>>
>>> Cheers, Sergey
>>>
>
Re: [JAX-RS][AuthorizationPolicy]Http Digest Authentication support?
Posted by Sergey Beryozkin <se...@progress.com>.
Hi Gabo
CXF has interceptors, and JAXRS input processing is implemented in a CXF input interceptor (JAXRSInInterceptor, currently sitting at
stage PRE_STREAM). JAXRSInInterceptor itself invokes on a chain of RequestHandlers which are interceptors too, but they're only
recognized by JAXRSInInterceptor and they have an interface different to CXF Interceptor interface (which is what JAXRSInInterceptor
implements) and RequestHandlers has currently no notion of phases, they're executed in scope of the JAXRSInInterceptor invocation.
You were asking Dan about phases, so I'm assuming you're trying to get a Proncipal object from a CXF interceptor (that is, not from
a JAXRS RequestFilter) ?
Is it correct ?
Cheers, Sergey
> Hi Sergey,
>
> PRE_INVOKE does not help.
>
> I'm a bit lost with regards to the filter. I checked the user's guide, it just talks about Request and ResponseHandlers, which I
> am already implementing.. am I missing something?
>
> Gabo
>
> Sergey Beryozkin wrote:
>> Hi
>>
>> Perhaps PRE_INVOKE can do ?
>> You can also try to get to this Principal object from a JAX-RS RequestHandler filter...
>>
>> Cheers, Sergey
>>
Re: [JAX-RS][AuthorizationPolicy]Http Digest Authentication support?
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
PRE_INVOKE does not help.
I'm a bit lost with regards to the filter. I checked the user's guide,
it just talks about Request and ResponseHandlers, which I am already
implementing.. am I missing something?
Gabo
Sergey Beryozkin wrote:
> Hi
>
> Perhaps PRE_INVOKE can do ?
> You can also try to get to this Principal object from a JAX-RS
> RequestHandler filter...
>
> Cheers, Sergey
>
Re: [JAX-RS][AuthorizationPolicy]Http Digest Authentication support?
Posted by Sergey Beryozkin <se...@progress.com>.
Hi
Perhaps PRE_INVOKE can do ?
You can also try to get to this Principal object from a JAX-RS RequestHandler filter...
Cheers, Sergey
Cheers, Sergey
> Hi Dan,
>
> Sorry for the delay of update.
>
> As of the moment, I am just checking on the Authorization entry in the
> protocol headers. As i have read in the
> (http://www.ietf.org/rfc/rfc2617) there is the possibility that I would
> be processing an Authorization entry that is meant for a proxy or whatnot.
>
> Just would like to confirm if this is ok since as of the moment, the
> Principal object is always null.
>
> Again, my thanks.
>
> Gabo
>
> Gabo Manuel wrote:
>> Hi Dan,
>>
>> Sorry for the delay.
>>
>> Is there a specific phase that the said class would be available? I
>> have tried RECEIVE and MARSHAL but the
>> message.get(SecurityContext.class).getUserPrincipal() remains null. It
>> is org.apache.cxf.security.SecurityContext, ryt?
>>
>> The re-send has the following Authorization header:
>> Authorization: Digest username="myUserName", realm="feefactor",
>> nonce="1225267457187", uri="/cxf/services/rest/Accounts/Account/1",
>> response="83f8bff523b43ff49f647b184938ee5a"
>>
>> Again, my thanks.
>>
>> Gabo
>>
>> Daniel Kulp wrote:
>>> We currently only map Basic auth into the AuthorizationPolicy
>>> stuff. For anything else, you would need to grab the Principal object:
>>> message.get(SecurityContext.class).getUserPrincipal()
>>> and inspect that in more detail. That object is provided to us from
>>> the servlet engine after it handles any authentication things it
>>> knows about.
>>>
>>> Dan
>>>
>>
Re: [JAX-RS][AuthorizationPolicy]Http Digest Authentication support?
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Dan,
Sorry for the delay of update.
As of the moment, I am just checking on the Authorization entry in the
protocol headers. As i have read in the
(http://www.ietf.org/rfc/rfc2617) there is the possibility that I would
be processing an Authorization entry that is meant for a proxy or whatnot.
Just would like to confirm if this is ok since as of the moment, the
Principal object is always null.
Again, my thanks.
Gabo
Gabo Manuel wrote:
> Hi Dan,
>
> Sorry for the delay.
>
> Is there a specific phase that the said class would be available? I
> have tried RECEIVE and MARSHAL but the
> message.get(SecurityContext.class).getUserPrincipal() remains null. It
> is org.apache.cxf.security.SecurityContext, ryt?
>
> The re-send has the following Authorization header:
> Authorization: Digest username="myUserName", realm="feefactor",
> nonce="1225267457187", uri="/cxf/services/rest/Accounts/Account/1",
> response="83f8bff523b43ff49f647b184938ee5a"
>
> Again, my thanks.
>
> Gabo
>
> Daniel Kulp wrote:
>> We currently only map Basic auth into the AuthorizationPolicy
>> stuff. For anything else, you would need to grab the Principal object:
>> message.get(SecurityContext.class).getUserPrincipal()
>> and inspect that in more detail. That object is provided to us from
>> the servlet engine after it handles any authentication things it
>> knows about.
>>
>> Dan
>>
>
Re: [JAX-RS][AuthorizationPolicy]Http Digest Authentication support?
Posted by Daniel Kulp <dk...@apache.org>.
We currently only map Basic auth into the AuthorizationPolicy stuff. For
anything else, you would need to grab the Principal object:
message.get(SecurityContext.class).getUserPrincipal()
and inspect that in more detail. That object is provided to us from the
servlet engine after it handles any authentication things it knows about.
Dan
On Monday 27 October 2008 4:35:00 am Gabo Manuel wrote:
> Hi All,
>
> After reading up more re: Http Basic, finally found why it is so. Final
> revision of questions:
>
> I modified Chris Dail's sample interceptor such that the challenge would be
>
> WWW-Authenticate: Digest realm=feefactor, nonce=1225096289125
>
> When the client re-submits request with the Digest details, e.g.:
>
> Authorization: Digest username="myUserName", realm="feefactor",
> nonce="1225096289125", uri="/cxf/services/rest/Accounts/Account/1",
> response="0808b59f915736b53da883b32c39c306"
>
> the following code still renders policy as null:
> AuthorizationPolicy policy = message.get(AuthorizationPolicy.class)
>
> I checked the received headers using the following code:
> logger.info("Protocol headers: " + message.get(Message.PROTOCOL_HEADERS));
>
> and Authorization is there:
>
> [InHandler] | Protocol headers: {host=[localhost:8081],
> Authorization=[Digest username="myUserName", realm="feefactor",
> nonce="1225096289125", uri="/cxf/services/rest/Accounts/Account/1",
> response="0808b59f915736b53da883b32c39c306"], user-agent=[Jakarta
> Commons-HttpClient/3.1]}
>
> Am I missing something?
>
> Gabo
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog