You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2010/10/22 01:00:30 UTC
Spnego / Kerberos Authentication
I just found that HTTPClient supports spnego authentication now (as of
4.1 alpha 2). In fact I added an issue to support spnego/kerberos and
oleg reminded me that it is already implemented. Could this help us to
also support this authentication scheme?
As far as I know we do not use httpclient at the moment.
I can image two ways to support Spnego/Kerberos. Either we use
httpclient and let it do the whole thing or we look how they do the
scheme and add it to the http transport ourselves.
Any opinions about this?
Thanks
Christian
--
----
http://www.liquid-reality.de
Re: AW: Spnego / Kerberos Authentication
Posted by Daniel Kulp <dk...@apache.org>.
Oli,
This is at a different level. This is transport level auth, similar to
BasicAuth/DigestAuth/NTLM. It's payload independent stuff. Slightly
different use case, but does have an impact when working with MS secured
things. The WebServer itself can be configured to only accept proper
Spnego/Kerberos connections and thus nothing even reaches the soap endpoint.
Kind of equivilent to using the security things in the web.xml of a war.
Dan
On Friday 22 October 2010 2:57:38 am Oliver Wulff wrote:
> Hi Christian
>
> I don't understand why the kerberos authentication itself is really
> relevant to CXF for two reasons:
>
> 1) the kerberos security token profile described a mapping for the GSS API
> to let issue a kerberos ticket when it has been submitted to oasis:
> http://xml.coverpages.org/WS-Security-Kerberos200312.pdf
> Later this chapter has been removed and because it's out of scope how you
> obtain a ticket. You can use the JAAS Login Module for Kerberos to let
> issue the ticket and the kerberos token profile describes how to attach
> the ticket to a soap message.
>
> 2) The issuance of kerberos tickets happens between the client and the kdc
> only (which is not related to CXF). Only the spec PKDA (I think it's not
> final) enables kerberos to work without a KDC (but based on PKI).
>
> What is your use case for the kerberos usage?
>
> Thanks
> Oli
> ________________________________________
> Von: Daniel Kulp [dkulp@apache.org]
> Gesendet: Freitag, 22. Oktober 2010 03:51
> An: dev@cxf.apache.org
> Cc: Christian Schneider
> Betreff: Re: Spnego / Kerberos Authentication
>
> On Thursday 21 October 2010 7:00:30 pm Christian Schneider wrote:
> > I just found that HTTPClient supports spnego authentication now (as of
> >
> > 4.1 alpha 2). In fact I added an issue to support spnego/kerberos and
> > oleg reminded me that it is already implemented. Could this help us to
> > also support this authentication scheme?
> > As far as I know we do not use httpclient at the moment.
>
> I started a branch:
> http://svn.apache.org/repos/asf/cxf/branches/async-client/
> where I started working on using the http-commons stuff for a complete
> async client side for http (haven't touched https yet). The goal for me
> so far was to get a more scalable async capability (less threads), but it
> may be usable for this usecase as well. That said, for the pure async
> capabilities, you have to drop down into the http-core stuff and not the
> higher layer http- client stuff. Thus, it might not be usable at all.
> I don't really know. Didn't get into the auth parts and such. I'd love
> help if you want to look at it. :-)
>
> > I can image two ways to support Spnego/Kerberos. Either we use
> > httpclient and let it do the whole thing or we look how they do the
> > scheme and add it to the http transport ourselves.
> > Any opinions about this?
>
> We could also add some better hooks to allow a user (LGPL, we cannot ship
> it) to plug in http://spnego.sourceforge.net/api/index.html to create the
> HttpUrlConnection.
>
> > Thanks
> >
> > Christian
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
AW: Spnego / Kerberos Authentication
Posted by Oliver Wulff <ol...@sopera.com>.
Hi Christian
I don't understand why the kerberos authentication itself is really relevant to CXF for two reasons:
1) the kerberos security token profile described a mapping for the GSS API to let issue a kerberos ticket when it has been submitted to oasis:
http://xml.coverpages.org/WS-Security-Kerberos200312.pdf
Later this chapter has been removed and because it's out of scope how you obtain a ticket. You can use the JAAS Login Module for Kerberos to let issue the ticket and the kerberos token profile describes how to attach the ticket to a soap message.
2) The issuance of kerberos tickets happens between the client and the kdc only (which is not related to CXF). Only the spec PKDA (I think it's not final) enables kerberos to work without a KDC (but based on PKI).
What is your use case for the kerberos usage?
Thanks
Oli
________________________________________
Von: Daniel Kulp [dkulp@apache.org]
Gesendet: Freitag, 22. Oktober 2010 03:51
An: dev@cxf.apache.org
Cc: Christian Schneider
Betreff: Re: Spnego / Kerberos Authentication
On Thursday 21 October 2010 7:00:30 pm Christian Schneider wrote:
> I just found that HTTPClient supports spnego authentication now (as of
> 4.1 alpha 2). In fact I added an issue to support spnego/kerberos and
> oleg reminded me that it is already implemented. Could this help us to
> also support this authentication scheme?
> As far as I know we do not use httpclient at the moment.
I started a branch:
http://svn.apache.org/repos/asf/cxf/branches/async-client/
where I started working on using the http-commons stuff for a complete async
client side for http (haven't touched https yet). The goal for me so far was
to get a more scalable async capability (less threads), but it may be usable
for this usecase as well. That said, for the pure async capabilities, you
have to drop down into the http-core stuff and not the higher layer http-
client stuff. Thus, it might not be usable at all. I don't really know.
Didn't get into the auth parts and such. I'd love help if you want to look
at it. :-)
>
> I can image two ways to support Spnego/Kerberos. Either we use
> httpclient and let it do the whole thing or we look how they do the
> scheme and add it to the http transport ourselves.
> Any opinions about this?
We could also add some better hooks to allow a user (LGPL, we cannot ship it)
to plug in http://spnego.sourceforge.net/api/index.html to create the
HttpUrlConnection.
>
> Thanks
>
> Christian
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Spnego / Kerberos Authentication
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 21 October 2010 7:00:30 pm Christian Schneider wrote:
> I just found that HTTPClient supports spnego authentication now (as of
> 4.1 alpha 2). In fact I added an issue to support spnego/kerberos and
> oleg reminded me that it is already implemented. Could this help us to
> also support this authentication scheme?
> As far as I know we do not use httpclient at the moment.
I started a branch:
http://svn.apache.org/repos/asf/cxf/branches/async-client/
where I started working on using the http-commons stuff for a complete async
client side for http (haven't touched https yet). The goal for me so far was
to get a more scalable async capability (less threads), but it may be usable
for this usecase as well. That said, for the pure async capabilities, you
have to drop down into the http-core stuff and not the higher layer http-
client stuff. Thus, it might not be usable at all. I don't really know.
Didn't get into the auth parts and such. I'd love help if you want to look
at it. :-)
>
> I can image two ways to support Spnego/Kerberos. Either we use
> httpclient and let it do the whole thing or we look how they do the
> scheme and add it to the http transport ourselves.
> Any opinions about this?
We could also add some better hooks to allow a user (LGPL, we cannot ship it)
to plug in http://spnego.sourceforge.net/api/index.html to create the
HttpUrlConnection.
>
> Thanks
>
> Christian
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog