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 06:07:08 UTC
[JAX-RS]Http Digest Authentication support?
Hi All,
I am currently trying to implement a ReST service and was hoping to put
some security to it. Afaik, WS-security is already not an option since I
am not exposing a SOAP service (am I wrong here?).
I tried searching the forums for some hint on where to go. I was able to
find entries re: Http Basic and SSL. I was hoping to take advantage of
the username/pwd of Http Digest and use that later in the request
processing, e.g. check privilege on the object accessed.
I am already inclined to create a handler/interceptor to retrieve an
"Authorization" header param and perform the hash calculation and
comparison there. I am unsure of two things:
1. Is the custom interceptor/handler really necessary? As there might
already some built in function in CXF I missed.
2. Should I be expecting the Authorization as header param, i.e.
((Map<String,
String>)message.get(Message.PROTOCOL_HEADERS)).get("Authorization"); or
something else? I tried using Chris Dail's sample interceptor, but this
code always gets a null: AuthorizationPolicy policy =
message.get(AuthorizationPolicy.class). I am unable to test it properly
as I have no idea how to create the client-side. I tried following the
sample in httpClient sample code
(http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/examples/BasicAuthenticationExample.java?view=markup)
to no avail. The policy remains null.
Again, my thanks for your assistance.
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
Re: [JAX-RS][AuthorizationPolicy]Http Digest Authentication support?
Posted by Gabo Manuel <km...@solegysystems.com>.
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]Http Digest Authentication support?
Posted by Fred Dushin <fr...@dushin.net>.
Well, the username and password are base64 encoded, only. So, they
really are being sent in clear text. (the header decodes to
myUserName:myPassword)
-Fred
On Oct 27, 2008, at 3:00 AM, Gabo Manuel wrote:
> One thing I noticed though was that even though the sample shows it
> as Basic, the username and pwd are not in clear text:
>
> GET /cxf/services/rest/Accounts/Account/1 HTTP/1.1
> User-Agent: Jakarta Commons-HttpClient/3.1
> Authorization: Basic bXlVc2VyTmFtZTpteVBhc3N3b3Jk
> Host: localhost:8081
Re: [JAX-RS]Http Digest Authentication support?
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi All,
Ignore #2. Got it to work. Error was on my side.
One thing I noticed though was that even though the sample shows it as
Basic, the username and pwd are not in clear text:
GET /cxf/services/rest/Accounts/Account/1 HTTP/1.1
User-Agent: Jakarta Commons-HttpClient/3.1
Authorization: Basic bXlVc2VyTmFtZTpteVBhc3N3b3Jk
Host: localhost:8081
Gabo
Re: [JAX-RS]Http Digest Authentication support?
Posted by Daniel Kulp <dk...@apache.org>.
On Fri February 13 2009 3:09:31 am Gabo Manuel wrote:
> Hi Dan,
>
> Just a few questions:
>
> 1. What class do I use to test the digest support you created? This one
> is added as an In interceptor, right?
Not really, it's kind of built into the HTTPConduit. The Conduit already had
plugable auth suppliers, but the API on it was really limitted to just being
usable for basic auth. I updated the API a bit to support more complex stuff
for Digest.
Basically, if you turn on the auto redirect support and turn off chunking, it
should be completely automatic. The first request will get the digest
challenge and we'll compute the stuff and resend.
If you want it to work "up front" so streaming still works, there is an
setAuthSupplier(...) method on the HTTPConduit. Just call it with a new
DigestAuthSupplier() and it should work fine.
> 2. Does it support "auth-int" as qop
No. I pretty much ported the http-client code from:
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-
client/src/main/java/org/apache/http/impl/auth/DigestScheme.java
and that specifically says:
auth-int is unsupported
> 3. Does it support nextnonce
I would say no. Again, that isn't mentioned in the http-client code so I'm
going to assume the answer is no.
> and just a generic question..
>
> what is the purpose of the "opaque" token? as an additional variable to
> the nonce?
Absolutely no idea. It isn't used in any of the calculations at all. It
just seems to be echoed back to the server exactly as is.
For the most part, I just ported the http-client code into our AuthSupplier
API's. Thus, what they don't support we wouldn't either. I've only really
tested it with the digest support in tomcat as well.
Dan
>
> Again, my thanks.
>
> Gabo
>
> Daniel Kulp wrote:
> > On Friday, I committed code to trunk to make it do digest auth. I'll
> > get that merged to 2.1.x today and get new snapshots up. I've only
> > tested against a simple service running in tomcat right now so it would
> > be GREAT if someone else gave it a quick try to make sure it works.
> >
> > One note:
> > digest auth requires more of a "hand shake" and thus you will probably
> > need to turn on request buffering. Turning on the auto-redirect
> > property of the conduit will do that. MAY also need to turn off
> > chunking. Not sure on that.
> >
> >
> > Dan
> >
> > On Thursday 22 January 2009 8:14:05 pm krause wrote:
> >> Any updates on this?
> >> I think I have the same requirement and haven't been able to find any
> >> info on how to do digest authentication at the transport layer, (i.e.
> >> HTTP) with CXF. I have done it using Axis, which in turn uses
> >> HttpClient and it is just a matter of adding the username and password
> >> and HttpClient does the rest. The only info I have found regarding
> >> digest authentication for CXF is related to WS-Security, wich is at a
> >> higher level but is not what I need (which is arguably better, since it
> >> is independent from the transport: http, jms, mail, etc.) .
> >>
> >> I have skimming through CXF documentation (and posts like this one) and
> >> it seems that this might be accomplished using CXF interceptors, but I
> >> don't have a clue on how to tap into the underlying http connection
> >> management to handle digest authentication.
> >>
> >> I also found this
> >> http://www.nabble.com/Using-HTTPClient-as-a-transport-td14715325.html
> >> thread in which it is suggested that in order to use HttpClient as a
> >> transport for CXF it has to be implemented as a conduit.
> >>
> >> The fact that there seems to be no easy way of doing it with CXF, and
> >> that no one seems to have contributed an interceptor or conduit for
> >> doing this makes me wonder if what I'm trying to do can be accomplished
> >> some other way which I'm not aware of.
> >>
> >> There is a http://issues.apache.org/jira/browse/CXF-291 Jira issue
> >> open for this, but there doesn't seem to be much activity.
> >>
> >> Any feedback would be very welcome.
> >> Regards
> >>
> >> Gabo Manuel wrote:
> >>> Hi All,
> >>>
> >>> I am currently trying to implement a ReST service and was hoping to put
> >>> some security to it. Afaik, WS-security is already not an option since
> >>> I am not exposing a SOAP service (am I wrong here?).
> >>>
> >>> I tried searching the forums for some hint on where to go. I was able
> >>> to find entries re: Http Basic and SSL. I was hoping to take advantage
> >>> of the username/pwd of Http Digest and use that later in the request
> >>> processing, e.g. check privilege on the object accessed.
> >>>
> >>> I am already inclined to create a handler/interceptor to retrieve an
> >>> "Authorization" header param and perform the hash calculation and
> >>> comparison there. I am unsure of two things:
> >>>
> >>> ...
> >
> > ------------------------------------------------------------------------
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG - http://www.avg.com
> > Version: 8.0.176 / Virus Database: 270.10.14/1917 - Release Date:
> > 1/26/2009 6:37 PM
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: [JAX-RS]Http Digest Authentication support?
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Dan,
Just a few questions:
1. What class do I use to test the digest support you created? This one
is added as an In interceptor, right?
2. Does it support "auth-int" as qop
3. Does it support nextnonce
and just a generic question..
what is the purpose of the "opaque" token? as an additional variable to
the nonce?
Again, my thanks.
Gabo
Daniel Kulp wrote:
> On Friday, I committed code to trunk to make it do digest auth. I'll get
> that merged to 2.1.x today and get new snapshots up. I've only tested
> against a simple service running in tomcat right now so it would be GREAT if
> someone else gave it a quick try to make sure it works.
>
> One note:
> digest auth requires more of a "hand shake" and thus you will probably need to
> turn on request buffering. Turning on the auto-redirect property of the
> conduit will do that. MAY also need to turn off chunking. Not sure on
> that.
>
>
> Dan
>
>
> On Thursday 22 January 2009 8:14:05 pm krause wrote:
>
>> Any updates on this?
>> I think I have the same requirement and haven't been able to find any info
>> on how to do digest authentication at the transport layer, (i.e. HTTP) with
>> CXF. I have done it using Axis, which in turn uses HttpClient and it is
>> just a matter of adding the username and password and HttpClient does the
>> rest. The only info I have found regarding digest authentication for CXF
>> is related to WS-Security, wich is at a higher level but is not what I need
>> (which is arguably better, since it is independent from the transport:
>> http, jms, mail, etc.) .
>>
>> I have skimming through CXF documentation (and posts like this one) and it
>> seems that this might be accomplished using CXF interceptors, but I don't
>> have a clue on how to tap into the underlying http connection management to
>> handle digest authentication.
>>
>> I also found this
>> http://www.nabble.com/Using-HTTPClient-as-a-transport-td14715325.html
>> thread in which it is suggested that in order to use HttpClient as a
>> transport for CXF it has to be implemented as a conduit.
>>
>> The fact that there seems to be no easy way of doing it with CXF, and that
>> no one seems to have contributed an interceptor or conduit for doing this
>> makes me wonder if what I'm trying to do can be accomplished some other way
>> which I'm not aware of.
>>
>> There is a http://issues.apache.org/jira/browse/CXF-291 Jira issue open
>> for this, but there doesn't seem to be much activity.
>>
>> Any feedback would be very welcome.
>> Regards
>>
>> Gabo Manuel wrote:
>>
>>> Hi All,
>>>
>>> I am currently trying to implement a ReST service and was hoping to put
>>> some security to it. Afaik, WS-security is already not an option since I
>>> am not exposing a SOAP service (am I wrong here?).
>>>
>>> I tried searching the forums for some hint on where to go. I was able to
>>> find entries re: Http Basic and SSL. I was hoping to take advantage of
>>> the username/pwd of Http Digest and use that later in the request
>>> processing, e.g. check privilege on the object accessed.
>>>
>>> I am already inclined to create a handler/interceptor to retrieve an
>>> "Authorization" header param and perform the hash calculation and
>>> comparison there. I am unsure of two things:
>>>
>>> ...
>>>
>
>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.10.14/1917 - Release Date: 1/26/2009 6:37 PM
>
>
Re: [JAX-RS]Http Digest Authentication support?
Posted by Daniel Kulp <dk...@apache.org>.
On Friday, I committed code to trunk to make it do digest auth. I'll get
that merged to 2.1.x today and get new snapshots up. I've only tested
against a simple service running in tomcat right now so it would be GREAT if
someone else gave it a quick try to make sure it works.
One note:
digest auth requires more of a "hand shake" and thus you will probably need to
turn on request buffering. Turning on the auto-redirect property of the
conduit will do that. MAY also need to turn off chunking. Not sure on
that.
Dan
On Thursday 22 January 2009 8:14:05 pm krause wrote:
> Any updates on this?
> I think I have the same requirement and haven't been able to find any info
> on how to do digest authentication at the transport layer, (i.e. HTTP) with
> CXF. I have done it using Axis, which in turn uses HttpClient and it is
> just a matter of adding the username and password and HttpClient does the
> rest. The only info I have found regarding digest authentication for CXF
> is related to WS-Security, wich is at a higher level but is not what I need
> (which is arguably better, since it is independent from the transport:
> http, jms, mail, etc.) .
>
> I have skimming through CXF documentation (and posts like this one) and it
> seems that this might be accomplished using CXF interceptors, but I don't
> have a clue on how to tap into the underlying http connection management to
> handle digest authentication.
>
> I also found this
> http://www.nabble.com/Using-HTTPClient-as-a-transport-td14715325.html
> thread in which it is suggested that in order to use HttpClient as a
> transport for CXF it has to be implemented as a conduit.
>
> The fact that there seems to be no easy way of doing it with CXF, and that
> no one seems to have contributed an interceptor or conduit for doing this
> makes me wonder if what I'm trying to do can be accomplished some other way
> which I'm not aware of.
>
> There is a http://issues.apache.org/jira/browse/CXF-291 Jira issue open
> for this, but there doesn't seem to be much activity.
>
> Any feedback would be very welcome.
> Regards
>
> Gabo Manuel wrote:
> > Hi All,
> >
> > I am currently trying to implement a ReST service and was hoping to put
> > some security to it. Afaik, WS-security is already not an option since I
> > am not exposing a SOAP service (am I wrong here?).
> >
> > I tried searching the forums for some hint on where to go. I was able to
> > find entries re: Http Basic and SSL. I was hoping to take advantage of
> > the username/pwd of Http Digest and use that later in the request
> > processing, e.g. check privilege on the object accessed.
> >
> > I am already inclined to create a handler/interceptor to retrieve an
> > "Authorization" header param and perform the hash calculation and
> > comparison there. I am unsure of two things:
> >
> > ...
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: [JAX-RS]Http Digest Authentication support?
Posted by krause <pa...@yahoo.com>.
Any updates on this?
I think I have the same requirement and haven't been able to find any info
on how to do digest authentication at the transport layer, (i.e. HTTP) with
CXF. I have done it using Axis, which in turn uses HttpClient and it is
just a matter of adding the username and password and HttpClient does the
rest. The only info I have found regarding digest authentication for CXF is
related to WS-Security, wich is at a higher level but is not what I need
(which is arguably better, since it is independent from the transport: http,
jms, mail, etc.) .
I have skimming through CXF documentation (and posts like this one) and it
seems that this might be accomplished using CXF interceptors, but I don't
have a clue on how to tap into the underlying http connection management to
handle digest authentication.
I also found this
http://www.nabble.com/Using-HTTPClient-as-a-transport-td14715325.html thread
in which it is suggested that in order to use HttpClient as a transport for
CXF it has to be implemented as a conduit.
The fact that there seems to be no easy way of doing it with CXF, and that
no one seems to have contributed an interceptor or conduit for doing this
makes me wonder if what I'm trying to do can be accomplished some other way
which I'm not aware of.
There is a http://issues.apache.org/jira/browse/CXF-291 Jira issue open
for this, but there doesn't seem to be much activity.
Any feedback would be very welcome.
Regards
Gabo Manuel wrote:
>
> Hi All,
>
> I am currently trying to implement a ReST service and was hoping to put
> some security to it. Afaik, WS-security is already not an option since I
> am not exposing a SOAP service (am I wrong here?).
>
> I tried searching the forums for some hint on where to go. I was able to
> find entries re: Http Basic and SSL. I was hoping to take advantage of
> the username/pwd of Http Digest and use that later in the request
> processing, e.g. check privilege on the object accessed.
>
> I am already inclined to create a handler/interceptor to retrieve an
> "Authorization" header param and perform the hash calculation and
> comparison there. I am unsure of two things:
>
> ...
>
>
--
View this message in context: http://www.nabble.com/-JAX-RS-Http-Digest-Authentication-support--tp20181931p21617071.html
Sent from the cxf-user mailing list archive at Nabble.com.