You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by mattmadhavan <ma...@yahoo.com> on 2007/11/22 20:59:40 UTC
Re: WS-Security Single Sign On
Hi Davide,
(I have replied to one of your earlier reply to mine). I found bunch of
postings here and few blogs.
Please look at ACEGI+ CAS (SSO) fro SSO.
Please refer to this great post,
http://domagojtechtips.blogspot.com/2007/08/cxf-spring-and-ws-security-putting-it.html
explains security prpogation. The idea is to tie in Acegi to this one and
use Acegi+CAS for SSO.
This post explains the ACEGI+CXF.
http://www.nabble.com/Acegi-Security-with-CXF-tf4337860.html#a12391936
The answer is out there in bits and pieces, but they all need to be tied
down! I have n't had a chance to tie'em together yet. If you are interested
we can work together.
After thanksgiving I will get to it!
Any help will be appreciated!
Thanks
Matt
Thkx again, the smoke is clearing out!
The infrastructure I am working in is http transport based, but probably in
the future will be moved to a JMS transport. So in the future I could not
rely on HTTPS anymore... anyway now I have it!
I haven't understood yout sentence "WS-SecureConversation is the route to
take here, but a lot of
infrastructure needs to be put into place, in order to make effective
use of the Kerberos authentication protocol."
In which sense? WS_Secure Conversation is implemented using Kerberos?
Fred Dushin-3 wrote:
>
> David,
>
> WSS4J may have some recently added support for propagating kerberos
> "tokens" (and by "token", I take it you mean a kerberos AP_REQ
> message), but getting a token from point A to point B is a small
> fraction of the story, when it comes to kerberos integration with Web
> Services.
>
> Yes, WS-SecureConversation is the route to take here, but a lot of
> infrastructure needs to be put into place, in order to make effective
> use of the Kerberos authentication protocol. In particular, security
> sessions need to be established and maintained (along the lines of
> abstractions provided by the GSS-API), and used to provide
> cryptographic services for messages delivered in the secure channel
> established.
>
> Of course, this may be overkill. An alternative is to use SSL to
> protect the channel, and just pass kerberos tickets as cookies. You
> at least get some assurance of client identity that way, but that's a
> pretty weak security story, IMO. It also requires that you use SSL,
> which sort of defeats the purpose of using Kerberos, in the first
> place -- or at a minimum overlooks the full power of the kerberos
> infrastructure. SSL may not be a viable options for all deployments,
> as well (e.g., JMS), but that doesn't seem to be an obstacle in your
> specific case.
>
> -Fred
>
> On Sep 13, 2007, at 4:07 AM, Davide Gesino wrote:
>
>>
>> Hi Fred,
>>
>> With "Single Sign On" I meant a mechanism to have a series of messages
>> authenticated only once (with the first of the series) and treated
>> as a
>> conversation, instead of autenthicate each message.
>> I some way I would want to emulate something similar to initial login
>> followed by and exchange of messages.
>> Maybe this pertains the WS-SecureConversation specification, that
>> I've seen
>> will be covered in CXF 2.1.
>> There is a way to use Kerberos authentication token in wss4j ?!
>>
>> David
>>
>>
>>
>>
>> Fred Dushin-3 wrote:
>>>
>>> No question is silly or bad.
>>>
>>> CXF itself provides no single sign-on capabilities, though one could
>>> certainly try to implement one over CXF.
>>>
>>> The challenge is to do it in a way that provides reasonable assurance
>>> and protection from replay and man-in-the-middle attacks. The naive
>>> approach is to grant the client a "cookie" in virtue of a login
>>> event, and then for the client to present that cookie as "evidence"
>>> of its identity. This way, the client is just using an opaque token
>>> in lieu of otherwise sensitive security information. (I presume this
>>> is what you mean by "single sign-on"). To do this, you need to lock
>>> down your communications channels, presumably in your case, using
>>> SSL. And you need to ensure that the dispensed cookies can't be
>>> stolen or hijacked. That's a lot of trust you need to place in how
>>> you deploy your infrastructure, and it only gets you so far.
>>>
>>> The more compelling solution (IMO) is to use SSO technologies that
>>> are already out there, such as Kerberos (which is arguably the most
>>> deployed SSO solution going). But I'm guessing that's not what
>>> you're after.
>>>
>>> -Fred
>>>
>>> On Sep 12, 2007, at 9:04 AM, Davide Gesino wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> may be a silly or bad question but....
>>>> there is a way to have a single sign on mechanism in CXF (in WS in
>>>> general)
>>>> or I have to check the user credentials each time for each message?
>>>> There is a way to estabilish something similar to the Http Session
>>>> between
>>>> WS client and server?!?
>>>> In my app I have CXF deployed on Tomcat and the transport is Http.
>>>>
>>>> David
>>>> --
>>>> View this message in context: http://www.nabble.com/WS-Security-
>>>> Single-Sign-On-tf4429137.html#a12634942
>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/WS-Security-
>> Single-Sign-On-tf4429137.html#a12650564
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/WS-Security-Single-Sign-On-tf4429137.html#a13902529
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-Security Single Sign On
Posted by mattmadhavan <ma...@yahoo.com>.
Davide,
There are lot of sample code out there for Acegi+CAS. I had my Acegi+CAS
working more than a year ago.
The idea is to make them all together. As for as Authentcation using
CXF+Acegi there are multiple posts withing this forms. Look for the one Anne
Racel.
I have not seen any imlementation on how to propogate the security token
(Except may be one post for XFire and I have not understood it at all),
between ws requests.
Thanks
Matt
Davide Gesino wrote:
>
> Hi Matt,
>
> thanks for the links.
> At the moment I'm trying to figure out how Sun project Metro manages WS-*
> extensions.
> Metro already supports this specs...
> Anyway everything is hidden away from the developer from Netbeans IDE
> (that still have some bugs).
> It is not clear what 's going on behind the scenes in glassfish, metro and
> netbeans.
> expecially the transport is not pluggable, from thw wizard, so I have
> chose the eclipse + CXF way to have more control on what I am doing.
> My prj is based on CXF.
>
> going back to CXF...
> Using an overall trusted Security Token Service (STS) that generates
> security session tokens seems to be the right way to have a single signed
> on (and then have a secure conversation).
> Pls refer to: https://wsit.dev.java.net/docs/trust-whitepaper.pdf
> CAS seems to be the way to provide a STS both client and server trust
> I'm trying to understand how it works, how it could be integrated in
> TOMCAT with CXF and ACEGI.
> I have not still understood if CAS is protocol agnostic, I would not have
> to rely upon HTTP transport security.
> I'll try make something out all these technoligies, when I have some code
> that does work (I hope) I'll make you know!
>
>
>
>
> mattmadhavan wrote:
>>
>> Hi Davide,
>> (I have replied to one of your earlier reply to mine). I found bunch of
>> postings here and few blogs.
>> Please look at ACEGI+ CAS (SSO) fro SSO.
>>
>> Please refer to this great post,
>> http://domagojtechtips.blogspot.com/2007/08/cxf-spring-and-ws-security-putting-it.html
>>
>> explains security prpogation. The idea is to tie in Acegi to this one and
>> use Acegi+CAS for SSO.
>>
>> This post explains the ACEGI+CXF.
>> http://www.nabble.com/Acegi-Security-with-CXF-tf4337860.html#a12391936
>>
>> The answer is out there in bits and pieces, but they all need to be tied
>> down! I have n't had a chance to tie'em together yet. If you are
>> interested we can work together.
>>
>> After thanksgiving I will get to it!
>>
>> Any help will be appreciated!
>>
>> Thanks
>> Matt
>>
>>
>>
>> Thkx again, the smoke is clearing out!
>> The infrastructure I am working in is http transport based, but probably
>> in the future will be moved to a JMS transport. So in the future I could
>> not rely on HTTPS anymore... anyway now I have it!
>>
>> I haven't understood yout sentence "WS-SecureConversation is the route to
>> take here, but a lot of
>> infrastructure needs to be put into place, in order to make effective
>> use of the Kerberos authentication protocol."
>> In which sense? WS_Secure Conversation is implemented using Kerberos?
>>
>>
>>
>>
>> Fred Dushin-3 wrote:
>>>
>>> David,
>>>
>>> WSS4J may have some recently added support for propagating kerberos
>>> "tokens" (and by "token", I take it you mean a kerberos AP_REQ
>>> message), but getting a token from point A to point B is a small
>>> fraction of the story, when it comes to kerberos integration with Web
>>> Services.
>>>
>>> Yes, WS-SecureConversation is the route to take here, but a lot of
>>> infrastructure needs to be put into place, in order to make effective
>>> use of the Kerberos authentication protocol. In particular, security
>>> sessions need to be established and maintained (along the lines of
>>> abstractions provided by the GSS-API), and used to provide
>>> cryptographic services for messages delivered in the secure channel
>>> established.
>>>
>>> Of course, this may be overkill. An alternative is to use SSL to
>>> protect the channel, and just pass kerberos tickets as cookies. You
>>> at least get some assurance of client identity that way, but that's a
>>> pretty weak security story, IMO. It also requires that you use SSL,
>>> which sort of defeats the purpose of using Kerberos, in the first
>>> place -- or at a minimum overlooks the full power of the kerberos
>>> infrastructure. SSL may not be a viable options for all deployments,
>>> as well (e.g., JMS), but that doesn't seem to be an obstacle in your
>>> specific case.
>>>
>>> -Fred
>>>
>>> On Sep 13, 2007, at 4:07 AM, Davide Gesino wrote:
>>>
>>>>
>>>> Hi Fred,
>>>>
>>>> With "Single Sign On" I meant a mechanism to have a series of messages
>>>> authenticated only once (with the first of the series) and treated
>>>> as a
>>>> conversation, instead of autenthicate each message.
>>>> I some way I would want to emulate something similar to initial login
>>>> followed by and exchange of messages.
>>>> Maybe this pertains the WS-SecureConversation specification, that
>>>> I've seen
>>>> will be covered in CXF 2.1.
>>>> There is a way to use Kerberos authentication token in wss4j ?!
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>>
>>>> Fred Dushin-3 wrote:
>>>>>
>>>>> No question is silly or bad.
>>>>>
>>>>> CXF itself provides no single sign-on capabilities, though one could
>>>>> certainly try to implement one over CXF.
>>>>>
>>>>> The challenge is to do it in a way that provides reasonable assurance
>>>>> and protection from replay and man-in-the-middle attacks. The naive
>>>>> approach is to grant the client a "cookie" in virtue of a login
>>>>> event, and then for the client to present that cookie as "evidence"
>>>>> of its identity. This way, the client is just using an opaque token
>>>>> in lieu of otherwise sensitive security information. (I presume this
>>>>> is what you mean by "single sign-on"). To do this, you need to lock
>>>>> down your communications channels, presumably in your case, using
>>>>> SSL. And you need to ensure that the dispensed cookies can't be
>>>>> stolen or hijacked. That's a lot of trust you need to place in how
>>>>> you deploy your infrastructure, and it only gets you so far.
>>>>>
>>>>> The more compelling solution (IMO) is to use SSO technologies that
>>>>> are already out there, such as Kerberos (which is arguably the most
>>>>> deployed SSO solution going). But I'm guessing that's not what
>>>>> you're after.
>>>>>
>>>>> -Fred
>>>>>
>>>>> On Sep 12, 2007, at 9:04 AM, Davide Gesino wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> may be a silly or bad question but....
>>>>>> there is a way to have a single sign on mechanism in CXF (in WS in
>>>>>> general)
>>>>>> or I have to check the user credentials each time for each message?
>>>>>> There is a way to estabilish something similar to the Http Session
>>>>>> between
>>>>>> WS client and server?!?
>>>>>> In my app I have CXF deployed on Tomcat and the transport is Http.
>>>>>>
>>>>>> David
>>>>>> --
>>>>>> View this message in context: http://www.nabble.com/WS-Security-
>>>>>> Single-Sign-On-tf4429137.html#a12634942
>>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context: http://www.nabble.com/WS-Security-
>>>> Single-Sign-On-tf4429137.html#a12650564
>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/WS-Security-Single-Sign-On-tf4429137.html#a13913861
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-Security Single Sign On
Posted by Davide Gesino <wi...@libero.it>.
Hi Matt,
thanks for the links.
At the moment I'm trying to figure out how Sun project Metro manages WS-*
extensions.
Metro already supports this specs...
Anyway everything is hidden away from the developer from Netbeans IDE (that
still have some bugs).
It is not clear what 's going on behind the scenes in glassfish, metro and
netbeans.
expecially the transport is not pluggable, from thw wizard, so I have chose
the eclipse + CXF way to have more control on what I am doing.
My prj is based on CXF.
going back to CXF...
Using an overall trusted Security Token Service (STS) that generates
security session tokens seems to be the right way to have a single signed on
(and then have a secure conversation).
Pls refer to: https://wsit.dev.java.net/docs/trust-whitepaper.pdf
CAS seems to be the way to provide a STS both client and server trust
I'm trying to understand how it works, how it could be integrated in TOMCAT
with CXF and ACEGI.
I have not still understood if CAS is protocol agnostic, I would not have to
rely upon HTTP transport security.
I'll try make something out all these technoligies, when I have some code
that does work (I hope) I'll make you know!
mattmadhavan wrote:
>
> Hi Davide,
> (I have replied to one of your earlier reply to mine). I found bunch of
> postings here and few blogs.
> Please look at ACEGI+ CAS (SSO) fro SSO.
>
> Please refer to this great post,
> http://domagojtechtips.blogspot.com/2007/08/cxf-spring-and-ws-security-putting-it.html
>
> explains security prpogation. The idea is to tie in Acegi to this one and
> use Acegi+CAS for SSO.
>
> This post explains the ACEGI+CXF.
> http://www.nabble.com/Acegi-Security-with-CXF-tf4337860.html#a12391936
>
> The answer is out there in bits and pieces, but they all need to be tied
> down! I have n't had a chance to tie'em together yet. If you are
> interested we can work together.
>
> After thanksgiving I will get to it!
>
> Any help will be appreciated!
>
> Thanks
> Matt
>
>
>
> Thkx again, the smoke is clearing out!
> The infrastructure I am working in is http transport based, but probably
> in the future will be moved to a JMS transport. So in the future I could
> not rely on HTTPS anymore... anyway now I have it!
>
> I haven't understood yout sentence "WS-SecureConversation is the route to
> take here, but a lot of
> infrastructure needs to be put into place, in order to make effective
> use of the Kerberos authentication protocol."
> In which sense? WS_Secure Conversation is implemented using Kerberos?
>
>
>
>
> Fred Dushin-3 wrote:
>>
>> David,
>>
>> WSS4J may have some recently added support for propagating kerberos
>> "tokens" (and by "token", I take it you mean a kerberos AP_REQ
>> message), but getting a token from point A to point B is a small
>> fraction of the story, when it comes to kerberos integration with Web
>> Services.
>>
>> Yes, WS-SecureConversation is the route to take here, but a lot of
>> infrastructure needs to be put into place, in order to make effective
>> use of the Kerberos authentication protocol. In particular, security
>> sessions need to be established and maintained (along the lines of
>> abstractions provided by the GSS-API), and used to provide
>> cryptographic services for messages delivered in the secure channel
>> established.
>>
>> Of course, this may be overkill. An alternative is to use SSL to
>> protect the channel, and just pass kerberos tickets as cookies. You
>> at least get some assurance of client identity that way, but that's a
>> pretty weak security story, IMO. It also requires that you use SSL,
>> which sort of defeats the purpose of using Kerberos, in the first
>> place -- or at a minimum overlooks the full power of the kerberos
>> infrastructure. SSL may not be a viable options for all deployments,
>> as well (e.g., JMS), but that doesn't seem to be an obstacle in your
>> specific case.
>>
>> -Fred
>>
>> On Sep 13, 2007, at 4:07 AM, Davide Gesino wrote:
>>
>>>
>>> Hi Fred,
>>>
>>> With "Single Sign On" I meant a mechanism to have a series of messages
>>> authenticated only once (with the first of the series) and treated
>>> as a
>>> conversation, instead of autenthicate each message.
>>> I some way I would want to emulate something similar to initial login
>>> followed by and exchange of messages.
>>> Maybe this pertains the WS-SecureConversation specification, that
>>> I've seen
>>> will be covered in CXF 2.1.
>>> There is a way to use Kerberos authentication token in wss4j ?!
>>>
>>> David
>>>
>>>
>>>
>>>
>>> Fred Dushin-3 wrote:
>>>>
>>>> No question is silly or bad.
>>>>
>>>> CXF itself provides no single sign-on capabilities, though one could
>>>> certainly try to implement one over CXF.
>>>>
>>>> The challenge is to do it in a way that provides reasonable assurance
>>>> and protection from replay and man-in-the-middle attacks. The naive
>>>> approach is to grant the client a "cookie" in virtue of a login
>>>> event, and then for the client to present that cookie as "evidence"
>>>> of its identity. This way, the client is just using an opaque token
>>>> in lieu of otherwise sensitive security information. (I presume this
>>>> is what you mean by "single sign-on"). To do this, you need to lock
>>>> down your communications channels, presumably in your case, using
>>>> SSL. And you need to ensure that the dispensed cookies can't be
>>>> stolen or hijacked. That's a lot of trust you need to place in how
>>>> you deploy your infrastructure, and it only gets you so far.
>>>>
>>>> The more compelling solution (IMO) is to use SSO technologies that
>>>> are already out there, such as Kerberos (which is arguably the most
>>>> deployed SSO solution going). But I'm guessing that's not what
>>>> you're after.
>>>>
>>>> -Fred
>>>>
>>>> On Sep 12, 2007, at 9:04 AM, Davide Gesino wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> may be a silly or bad question but....
>>>>> there is a way to have a single sign on mechanism in CXF (in WS in
>>>>> general)
>>>>> or I have to check the user credentials each time for each message?
>>>>> There is a way to estabilish something similar to the Http Session
>>>>> between
>>>>> WS client and server?!?
>>>>> In my app I have CXF deployed on Tomcat and the transport is Http.
>>>>>
>>>>> David
>>>>> --
>>>>> View this message in context: http://www.nabble.com/WS-Security-
>>>>> Single-Sign-On-tf4429137.html#a12634942
>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context: http://www.nabble.com/WS-Security-
>>> Single-Sign-On-tf4429137.html#a12650564
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/WS-Security-Single-Sign-On-tf4429137.html#a13912318
Sent from the cxf-user mailing list archive at Nabble.com.