You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Håkon Sagehaug <Ha...@bccs.uib.no> on 2009/03/20 12:34:46 UTC
General setup of ws-trust
Hi all,
I've been trying to really to understand ws-trust from the more general
perspective, so maybe not the question should go out here, but since rampart
is ws-trust implementation I hope it's okay.
My setup is the classical ws-trust setup
1.Client
2.Sts
3.Target service
The target service does not know about user, but trust the token issued by
the sts, tokens is a set of roles.
Flow
1. The client ask for a the tokens belonging to him, is this context a list
of roles, based on the username and password of the user. Signed and
encrypted by the uses private key
2. Sts service then validates the signature and decrypts it.
3.Creates a token with the roles for the user and signs/encrypts this with
the private key of the sts service. And wrapping it inside a
RequestSecuritTokenResponse lookking something like this
<RequestSecuritTokenResponse>
<com:Token xmlns:com="http://common" xmlns:oas="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
oas:Id="id_145663">
<com:Username>testu</com:Username>
<com:RoleInProject>
<com:Role>ADMIN</com:Role>
<com:Project>testu_project</com:Project>
</com:RoleInProject>
</com:Token>
</ns:RequestedSecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="
http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference
URI="#_0de82a70b0ad68d7b29387828b2ba3ec">
<ds:Transforms>
<ds:Transform Algorithm="
http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="
http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="code ds kind rw saml
samlp typens #default xsd xsi" />
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="
http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>EFf0+eeFzPPm3eG+MJkfYbTsrrY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>GQt+8+NOn=</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>dnfjngjknfjkgnjkfngjknfjgnjf</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<RequestSecuritTokenResponse>
This of course is much similar to a saml assertion.
then this is encrypted and signed using the sts private key.
4 The client verifies that the message comes form the sts and extracts the
token from the message, finally places it in the header for the request to
the target service. signs and encrypts it with the client's private key.
5. Now the target service decrypt the message, extract the token form the
header , looks to see if this was signed with the private key of the sts. If
so the perform the authorization based on the attributes in the token.
Is this the correct way of accomplishing trust, and how the target service
knows that these tokens is issued by the sts service?
Really appreciate replays on this topic
cheers, Håkon
--
Håkon Sagehaug, Scientific Programmer
Parallab, Bergen Center for Computational Science (BCCS)
UNIFOB AS (University of Bergen Research Company)
Re: General setup of ws-trust
Posted by Massimiliano Masi <ma...@math.unifi.it>.
Hi,
Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
> Thanks for you tips and time, I'll read the paper. And take the weekend to
> try to understand the hole of this.
Yes, I think it is a good starting point. It is not
difficult to read, and it's interesting.
To put the identities inside the token, would be a good idea.
Ciao,
Massimiliano
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Re: General setup of ws-trust
Posted by Håkon Sagehaug <Ha...@bccs.uib.no>.
Hi
Thanks for you tips and time, I'll read the paper. And take the weekend to
try to understand the hole of this.
cheers, Håkon
2009/3/20 Massimiliano Masi <ma...@math.unifi.it>
> Hi Hakon,
>
> Just one issue on your token:
>
> Please use an enveloped signature (the signature itself
> is part of the token). In this way, if you don't sign the
> whole body, you'll be vulnerable to rewrite attacks.
Thanks for the tip
>
>
> And another suggestion: If the token is inteded for a particular
> audience, then this audience should be defined here.
>
> If the token is referring to a particular client,
> then client's identity should be here.
Inside the Token element or as a wss element like binary secret?
cheers, Håkon
>
> This paper,
>
> Prudent Engineering Practice for Cryptographic Protocols,
> Abadi and Needham, 95
>
> is a good reading.
>
> And I think that the ws-sx mailing list is more appropriate for
> this topic.
>
>
>
> Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
>
> Hi
>>
>> I guess what I'm trying to achieve with the token is to have a light
>> weight
>> SAML token. so just wanted to know if it was correct to have the
>> ds:SignedInfo inside the element itself and signed by the private key of
>> the
>> sts. Another try on the XML ;)
>>
>> <RequestSecurityTokenResponseCollection xmlns="
>> http://docs.oasis-open.org/ws-sx/ws-trust/200512">
>> <RequestSecurityTokenResponse>
>> <ns:RequestedSecurityToken xmlns:ns="">
>> <com:EsysbioToken xmlns:com="" xmlns:oas=""
>> oas:Id="_0de82a70b0ad68d7b29387828b2ba3ec">
>> <com:Username>test</com:Username>
>> <com:RoleInProject>
>> <com:Role>ADMIN</com:Role>
>> <com:Project>project</com:Project>
>> </com:RoleInProject>
>> </com:EsysbioToken>
>> </ns:RequestedSecurityToken>
>> <ds:Signature xmlns:ds="
>> http://www.w3.org/2000/09/xmldsig#
>> ">
>> <ds:SignedInfo>
>> <ds:CanonicalizationMethod Algorithm="
>> http://www.w3.org/2001/10/xml-exc-c14n#" />
>> <ds:SignatureMethod Algorithm="
>> http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
>> <ds:Reference
>> URI="#_0de82a70b0ad68d7b29387828b2ba3ec">
>> <ds:Transforms>
>> <ds:Transform Algorithm="
>> http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
>> <ds:Transform Algorithm="
>> http://www.w3.org/2001/10/xml-exc-c14n#">
>> <ec:InclusiveNamespaces xmlns:ec="
>> http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </ds:Transform>
>> </ds:Transforms>
>> <ds:DigestMethod Algorithm="
>> http://www.w3.org/2000/09/xmldsig#sha1" />
>>
>> <ds:DigestValue>EFf0+eeFzPPm3eG+MJkfYbTsrrY=</ds:DigestValue>
>> </ds:Reference>
>> </ds:SignedInfo>
>>
>> <ds:SignatureValue>CULorNPLYbHJ04f4qdQQsN63HPzmlY=</ds:SignatureValue>
>> <ds:KeyInfo>
>> <ds:X509Data>
>>
>>
>> <ds:X509Certificate>EHKFtFaX4iF1tWbGxa4+vIbbV4CaUG5s5x</ds:X509Certificate>
>> </ds:X509Data>
>> </ds:KeyInfo>
>> </ds:Signature>
>> <ns:RequestedSecurityToken xmlns:ns="">
>> </RequestSecurityTokenResponse>
>> </RequestSecurityTokenResponseCollection>
>>
>> namespaces in removed more readability.
>> 2009/3/20 Massimiliano Masi <ma...@math.unifi.it>
>>
>> Hakon,
>>>
>>> Yes, it's only xml, but is important! (The RSTRC). :-)
>>>
>>> I don't understand your security token, I don't know
>>> if you expressed it correctly:
>>>
>>> You have a
>>>
>>> <RequestSecurityTokenResponse>
>>> < -- missing RequestedSecurityToken >
>>> <com:Token that's ok
>>> but you are signing something that I cannot see
>>> and try to use a more powerful id, instead of id_145663
>>>
>>>
>>> Try to paste another XML. ;-)
>>>
>>>
>>>
>>> Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
>>>
>>> Hi
>>>
>>>>
>>>> Thanks for the replay
>>>>
>>>> see inline
>>>>
>>>> 2009/3/20 Massimiliano Masi <ma...@math.unifi.it>
>>>>
>>>> Hi,
>>>>
>>>>>
>>>>> In general you should encrypt a message using the
>>>>> public key of the recipient and sign with the private
>>>>> key of the sender. This enforces integrity (the signature),
>>>>> authentication
>>>>> (the signature) and confidentiality (the encryption).
>>>>>
>>>>> As I told you, the RSTR is not correct. You really should
>>>>> use the RSTRC instead, since it is only request/response.
>>>>>
>>>>>
>>>> I forgot to have this element, but it's only sudo xml
>>>>
>>>>
>>>>
>>>>> The service ``trust'' the token, since it is signed
>>>>> by the STS, and we suppose that the STS that owns the
>>>>> private key.
>>>>>
>>>>> Pay attention for the STS to not be an oracle.
>>>>>
>>>>>
>>>>
>>>> We're implementing a sts of our own, and trying to get it all together.
>>>> The
>>>> reason why I'm asking all these questions, for getting the hole picture.
>>>>
>>>> Also, is the way I described the security token correct? This token is
>>>> of
>>>> course not how it looks in the real world but have the important
>>>> elements.
>>>>
>>>> cheers, håkon
>>>>
>>>>
>>>>
>>>> Please, look at the
>>>>
>>>>> 11 suggestions on how to write security protocols, written
>>>>> in 80's by Martin Abadi.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>> I've been trying to really to understand ws-trust from the more
>>>>>> general
>>>>>> perspective, so maybe not the question should go out here, but since
>>>>>> rampart
>>>>>> is ws-trust implementation I hope it's okay.
>>>>>>
>>>>>> My setup is the classical ws-trust setup
>>>>>> 1.Client
>>>>>> 2.Sts
>>>>>> 3.Target service
>>>>>>
>>>>>> The target service does not know about user, but trust the token
>>>>>> issued
>>>>>> by
>>>>>> the sts, tokens is a set of roles.
>>>>>>
>>>>>> Flow
>>>>>> 1. The client ask for a the tokens belonging to him, is this context a
>>>>>> list
>>>>>> of roles, based on the username and password of the user. Signed and
>>>>>> encrypted by the uses private key
>>>>>>
>>>>>> 2. Sts service then validates the signature and decrypts it.
>>>>>> 3.Creates a token with the roles for the user and signs/encrypts this
>>>>>> with
>>>>>> the private key of the sts service. And wrapping it inside a
>>>>>> RequestSecuritTokenResponse lookking something like this
>>>>>>
>>>>>> <RequestSecuritTokenResponse>
>>>>>> <com:Token xmlns:com="http://common" xmlns:oas="
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>>>> "
>>>>>> oas:Id="id_145663">
>>>>>> <com:Username>testu</com:Username>
>>>>>> <com:RoleInProject>
>>>>>> <com:Role>ADMIN</com:Role>
>>>>>> <com:Project>testu_project</com:Project>
>>>>>> </com:RoleInProject>
>>>>>> </com:Token>
>>>>>> </ns:RequestedSecurityToken>
>>>>>> <ds:Signature xmlns:ds="
>>>>>> http://www.w3.org/2000/09/xmldsig#
>>>>>> ">
>>>>>> <ds:SignedInfo>
>>>>>> <ds:CanonicalizationMethod Algorithm="
>>>>>> http://www.w3.org/2001/10/xml-exc-c14n#" />
>>>>>> <ds:SignatureMethod Algorithm="
>>>>>> http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
>>>>>> <ds:Reference
>>>>>> URI="#_0de82a70b0ad68d7b29387828b2ba3ec">
>>>>>> <ds:Transforms>
>>>>>> <ds:Transform Algorithm="
>>>>>> http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
>>>>>> <ds:Transform Algorithm="
>>>>>> http://www.w3.org/2001/10/xml-exc-c14n#">
>>>>>> <ec:InclusiveNamespaces xmlns:ec="
>>>>>> http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="code ds kind rw
>>>>>> saml
>>>>>> samlp typens #default xsd xsi" />
>>>>>> </ds:Transform>
>>>>>> </ds:Transforms>
>>>>>> <ds:DigestMethod Algorithm="
>>>>>> http://www.w3.org/2000/09/xmldsig#sha1" />
>>>>>>
>>>>>> <ds:DigestValue>EFf0+eeFzPPm3eG+MJkfYbTsrrY=</ds:DigestValue>
>>>>>> </ds:Reference>
>>>>>> </ds:SignedInfo>
>>>>>> <ds:SignatureValue>GQt+8+NOn=</ds:SignatureValue>
>>>>>> <ds:KeyInfo>
>>>>>>
>>>>>> <ds:X509Data>dnfjngjknfjkgnjkfngjknfjgnjf</ds:X509Certificate>
>>>>>> </ds:X509Data>
>>>>>> </ds:KeyInfo>
>>>>>> </ds:Signature>
>>>>>> <RequestSecuritTokenResponse>
>>>>>>
>>>>>> This of course is much similar to a saml assertion.
>>>>>>
>>>>>> then this is encrypted and signed using the sts private key.
>>>>>>
>>>>>> 4 The client verifies that the message comes form the sts and extracts
>>>>>> the
>>>>>> token from the message, finally places it in the header for the
>>>>>> request
>>>>>> to
>>>>>> the target service. signs and encrypts it with the client's private
>>>>>> key.
>>>>>>
>>>>>> 5. Now the target service decrypt the message, extract the token form
>>>>>> the
>>>>>> header , looks to see if this was signed with the private key of the
>>>>>> sts.
>>>>>> If
>>>>>> so the perform the authorization based on the attributes in the token.
>>>>>>
>>>>>> Is this the correct way of accomplishing trust, and how the target
>>>>>> service
>>>>>> knows that these tokens is issued by the sts service?
>>>>>>
>>>>>> Really appreciate replays on this topic
>>>>>>
>>>>>> cheers, Håkon
>>>>>>
>>>>>> --
>>>>>> Håkon Sagehaug, Scientific Programmer
>>>>>> Parallab, Bergen Center for Computational Science (BCCS)
>>>>>> UNIFOB AS (University of Bergen Research Company)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ----------------------------------------------------------------
>>>>> This message was sent using IMP, the Internet Messaging Program.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Håkon Sagehaug, Scientific Programmer
>>>> Parallab, Bergen Center for Computational Science (BCCS)
>>>> UNIFOB AS (University of Bergen Research Company)
>>>>
>>>>
>>>>
>>>
>>> ----------------------------------------------------------------
>>> This message was sent using IMP, the Internet Messaging Program.
>>>
>>>
>>>
>>>
>>
>> --
>> Håkon Sagehaug, Scientific Programmer
>> Parallab, Bergen Center for Computational Science (BCCS)
>> UNIFOB AS (University of Bergen Research Company)
>>
>>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
--
Håkon Sagehaug, Scientific Programmer
Parallab, Bergen Center for Computational Science (BCCS)
UNIFOB AS (University of Bergen Research Company)
Re: General setup of ws-trust
Posted by Massimiliano Masi <ma...@math.unifi.it>.
Hi Hakon,
Just one issue on your token:
Please use an enveloped signature (the signature itself
is part of the token). In this way, if you don't sign the
whole body, you'll be vulnerable to rewrite attacks.
And another suggestion: If the token is inteded for a particular
audience, then this audience should be defined here.
If the token is referring to a particular client,
then client's identity should be here.
This paper,
Prudent Engineering Practice for Cryptographic Protocols,
Abadi and Needham, 95
is a good reading.
And I think that the ws-sx mailing list is more appropriate for
this topic.
Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
> Hi
>
> I guess what I'm trying to achieve with the token is to have a light weight
> SAML token. so just wanted to know if it was correct to have the
> ds:SignedInfo inside the element itself and signed by the private key of the
> sts. Another try on the XML ;)
>
> <RequestSecurityTokenResponseCollection xmlns="
> http://docs.oasis-open.org/ws-sx/ws-trust/200512">
> <RequestSecurityTokenResponse>
> <ns:RequestedSecurityToken xmlns:ns="">
> <com:EsysbioToken xmlns:com="" xmlns:oas=""
> oas:Id="_0de82a70b0ad68d7b29387828b2ba3ec">
> <com:Username>test</com:Username>
> <com:RoleInProject>
> <com:Role>ADMIN</com:Role>
> <com:Project>project</com:Project>
> </com:RoleInProject>
> </com:EsysbioToken>
> </ns:RequestedSecurityToken>
> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#
> ">
> <ds:SignedInfo>
> <ds:CanonicalizationMethod Algorithm="
> http://www.w3.org/2001/10/xml-exc-c14n#" />
> <ds:SignatureMethod Algorithm="
> http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
> <ds:Reference
> URI="#_0de82a70b0ad68d7b29387828b2ba3ec">
> <ds:Transforms>
> <ds:Transform Algorithm="
> http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
> <ds:Transform Algorithm="
> http://www.w3.org/2001/10/xml-exc-c14n#">
> <ec:InclusiveNamespaces xmlns:ec="
> http://www.w3.org/2001/10/xml-exc-c14n#"/>
> </ds:Transform>
> </ds:Transforms>
> <ds:DigestMethod Algorithm="
> http://www.w3.org/2000/09/xmldsig#sha1" />
>
> <ds:DigestValue>EFf0+eeFzPPm3eG+MJkfYbTsrrY=</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
>
> <ds:SignatureValue>CULorNPLYbHJ04f4qdQQsN63HPzmlY=</ds:SignatureValue>
> <ds:KeyInfo>
> <ds:X509Data>
>
> <ds:X509Certificate>EHKFtFaX4iF1tWbGxa4+vIbbV4CaUG5s5x</ds:X509Certificate>
> </ds:X509Data>
> </ds:KeyInfo>
> </ds:Signature>
> <ns:RequestedSecurityToken xmlns:ns="">
> </RequestSecurityTokenResponse>
> </RequestSecurityTokenResponseCollection>
>
> namespaces in removed more readability.
> 2009/3/20 Massimiliano Masi <ma...@math.unifi.it>
>
>> Hakon,
>>
>> Yes, it's only xml, but is important! (The RSTRC). :-)
>>
>> I don't understand your security token, I don't know
>> if you expressed it correctly:
>>
>> You have a
>>
>> <RequestSecurityTokenResponse>
>> < -- missing RequestedSecurityToken >
>> <com:Token that's ok
>> but you are signing something that I cannot see
>> and try to use a more powerful id, instead of id_145663
>>
>>
>> Try to paste another XML. ;-)
>>
>>
>>
>> Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
>>
>> Hi
>>>
>>> Thanks for the replay
>>>
>>> see inline
>>>
>>> 2009/3/20 Massimiliano Masi <ma...@math.unifi.it>
>>>
>>> Hi,
>>>>
>>>> In general you should encrypt a message using the
>>>> public key of the recipient and sign with the private
>>>> key of the sender. This enforces integrity (the signature),
>>>> authentication
>>>> (the signature) and confidentiality (the encryption).
>>>>
>>>> As I told you, the RSTR is not correct. You really should
>>>> use the RSTRC instead, since it is only request/response.
>>>>
>>>
>>> I forgot to have this element, but it's only sudo xml
>>>
>>>
>>>>
>>>> The service ``trust'' the token, since it is signed
>>>> by the STS, and we suppose that the STS that owns the
>>>> private key.
>>>>
>>>> Pay attention for the STS to not be an oracle.
>>>>
>>>
>>>
>>> We're implementing a sts of our own, and trying to get it all together.
>>> The
>>> reason why I'm asking all these questions, for getting the hole picture.
>>>
>>> Also, is the way I described the security token correct? This token is of
>>> course not how it looks in the real world but have the important elements.
>>>
>>> cheers, håkon
>>>
>>>
>>>
>>> Please, look at the
>>>> 11 suggestions on how to write security protocols, written
>>>> in 80's by Martin Abadi.
>>>>
>>>>
>>>>
>>>>
>>>> Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
>>>>
>>>> Hi all,
>>>>
>>>>>
>>>>> I've been trying to really to understand ws-trust from the more general
>>>>> perspective, so maybe not the question should go out here, but since
>>>>> rampart
>>>>> is ws-trust implementation I hope it's okay.
>>>>>
>>>>> My setup is the classical ws-trust setup
>>>>> 1.Client
>>>>> 2.Sts
>>>>> 3.Target service
>>>>>
>>>>> The target service does not know about user, but trust the token issued
>>>>> by
>>>>> the sts, tokens is a set of roles.
>>>>>
>>>>> Flow
>>>>> 1. The client ask for a the tokens belonging to him, is this context a
>>>>> list
>>>>> of roles, based on the username and password of the user. Signed and
>>>>> encrypted by the uses private key
>>>>>
>>>>> 2. Sts service then validates the signature and decrypts it.
>>>>> 3.Creates a token with the roles for the user and signs/encrypts this
>>>>> with
>>>>> the private key of the sts service. And wrapping it inside a
>>>>> RequestSecuritTokenResponse lookking something like this
>>>>>
>>>>> <RequestSecuritTokenResponse>
>>>>> <com:Token xmlns:com="http://common" xmlns:oas="
>>>>>
>>>>>
>>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>>> "
>>>>> oas:Id="id_145663">
>>>>> <com:Username>testu</com:Username>
>>>>> <com:RoleInProject>
>>>>> <com:Role>ADMIN</com:Role>
>>>>> <com:Project>testu_project</com:Project>
>>>>> </com:RoleInProject>
>>>>> </com:Token>
>>>>> </ns:RequestedSecurityToken>
>>>>> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#
>>>>> ">
>>>>> <ds:SignedInfo>
>>>>> <ds:CanonicalizationMethod Algorithm="
>>>>> http://www.w3.org/2001/10/xml-exc-c14n#" />
>>>>> <ds:SignatureMethod Algorithm="
>>>>> http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
>>>>> <ds:Reference
>>>>> URI="#_0de82a70b0ad68d7b29387828b2ba3ec">
>>>>> <ds:Transforms>
>>>>> <ds:Transform Algorithm="
>>>>> http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
>>>>> <ds:Transform Algorithm="
>>>>> http://www.w3.org/2001/10/xml-exc-c14n#">
>>>>> <ec:InclusiveNamespaces xmlns:ec="
>>>>> http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="code ds kind rw
>>>>> saml
>>>>> samlp typens #default xsd xsi" />
>>>>> </ds:Transform>
>>>>> </ds:Transforms>
>>>>> <ds:DigestMethod Algorithm="
>>>>> http://www.w3.org/2000/09/xmldsig#sha1" />
>>>>>
>>>>> <ds:DigestValue>EFf0+eeFzPPm3eG+MJkfYbTsrrY=</ds:DigestValue>
>>>>> </ds:Reference>
>>>>> </ds:SignedInfo>
>>>>> <ds:SignatureValue>GQt+8+NOn=</ds:SignatureValue>
>>>>> <ds:KeyInfo>
>>>>>
>>>>> <ds:X509Data>dnfjngjknfjkgnjkfngjknfjgnjf</ds:X509Certificate>
>>>>> </ds:X509Data>
>>>>> </ds:KeyInfo>
>>>>> </ds:Signature>
>>>>> <RequestSecuritTokenResponse>
>>>>>
>>>>> This of course is much similar to a saml assertion.
>>>>>
>>>>> then this is encrypted and signed using the sts private key.
>>>>>
>>>>> 4 The client verifies that the message comes form the sts and extracts
>>>>> the
>>>>> token from the message, finally places it in the header for the request
>>>>> to
>>>>> the target service. signs and encrypts it with the client's private key.
>>>>>
>>>>> 5. Now the target service decrypt the message, extract the token form
>>>>> the
>>>>> header , looks to see if this was signed with the private key of the
>>>>> sts.
>>>>> If
>>>>> so the perform the authorization based on the attributes in the token.
>>>>>
>>>>> Is this the correct way of accomplishing trust, and how the target
>>>>> service
>>>>> knows that these tokens is issued by the sts service?
>>>>>
>>>>> Really appreciate replays on this topic
>>>>>
>>>>> cheers, Håkon
>>>>>
>>>>> --
>>>>> Håkon Sagehaug, Scientific Programmer
>>>>> Parallab, Bergen Center for Computational Science (BCCS)
>>>>> UNIFOB AS (University of Bergen Research Company)
>>>>>
>>>>>
>>>>>
>>>>
>>>> ----------------------------------------------------------------
>>>> This message was sent using IMP, the Internet Messaging Program.
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Håkon Sagehaug, Scientific Programmer
>>> Parallab, Bergen Center for Computational Science (BCCS)
>>> UNIFOB AS (University of Bergen Research Company)
>>>
>>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>>
>
>
> --
> Håkon Sagehaug, Scientific Programmer
> Parallab, Bergen Center for Computational Science (BCCS)
> UNIFOB AS (University of Bergen Research Company)
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Re: General setup of ws-trust
Posted by Håkon Sagehaug <Ha...@bccs.uib.no>.
Hi
I guess what I'm trying to achieve with the token is to have a light weight
SAML token. so just wanted to know if it was correct to have the
ds:SignedInfo inside the element itself and signed by the private key of the
sts. Another try on the XML ;)
<RequestSecurityTokenResponseCollection xmlns="
http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<RequestSecurityTokenResponse>
<ns:RequestedSecurityToken xmlns:ns="">
<com:EsysbioToken xmlns:com="" xmlns:oas=""
oas:Id="_0de82a70b0ad68d7b29387828b2ba3ec">
<com:Username>test</com:Username>
<com:RoleInProject>
<com:Role>ADMIN</com:Role>
<com:Project>project</com:Project>
</com:RoleInProject>
</com:EsysbioToken>
</ns:RequestedSecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#
">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="
http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference
URI="#_0de82a70b0ad68d7b29387828b2ba3ec">
<ds:Transforms>
<ds:Transform Algorithm="
http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="
http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="
http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="
http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>EFf0+eeFzPPm3eG+MJkfYbTsrrY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>CULorNPLYbHJ04f4qdQQsN63HPzmlY=</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>EHKFtFaX4iF1tWbGxa4+vIbbV4CaUG5s5x</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<ns:RequestedSecurityToken xmlns:ns="">
</RequestSecurityTokenResponse>
</RequestSecurityTokenResponseCollection>
namespaces in removed more readability.
2009/3/20 Massimiliano Masi <ma...@math.unifi.it>
> Hakon,
>
> Yes, it's only xml, but is important! (The RSTRC). :-)
>
> I don't understand your security token, I don't know
> if you expressed it correctly:
>
> You have a
>
> <RequestSecurityTokenResponse>
> < -- missing RequestedSecurityToken >
> <com:Token that's ok
> but you are signing something that I cannot see
> and try to use a more powerful id, instead of id_145663
>
>
> Try to paste another XML. ;-)
>
>
>
> Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
>
> Hi
>>
>> Thanks for the replay
>>
>> see inline
>>
>> 2009/3/20 Massimiliano Masi <ma...@math.unifi.it>
>>
>> Hi,
>>>
>>> In general you should encrypt a message using the
>>> public key of the recipient and sign with the private
>>> key of the sender. This enforces integrity (the signature),
>>> authentication
>>> (the signature) and confidentiality (the encryption).
>>>
>>> As I told you, the RSTR is not correct. You really should
>>> use the RSTRC instead, since it is only request/response.
>>>
>>
>> I forgot to have this element, but it's only sudo xml
>>
>>
>>>
>>> The service ``trust'' the token, since it is signed
>>> by the STS, and we suppose that the STS that owns the
>>> private key.
>>>
>>> Pay attention for the STS to not be an oracle.
>>>
>>
>>
>> We're implementing a sts of our own, and trying to get it all together.
>> The
>> reason why I'm asking all these questions, for getting the hole picture.
>>
>> Also, is the way I described the security token correct? This token is of
>> course not how it looks in the real world but have the important elements.
>>
>> cheers, håkon
>>
>>
>>
>> Please, look at the
>>> 11 suggestions on how to write security protocols, written
>>> in 80's by Martin Abadi.
>>>
>>>
>>>
>>>
>>> Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
>>>
>>> Hi all,
>>>
>>>>
>>>> I've been trying to really to understand ws-trust from the more general
>>>> perspective, so maybe not the question should go out here, but since
>>>> rampart
>>>> is ws-trust implementation I hope it's okay.
>>>>
>>>> My setup is the classical ws-trust setup
>>>> 1.Client
>>>> 2.Sts
>>>> 3.Target service
>>>>
>>>> The target service does not know about user, but trust the token issued
>>>> by
>>>> the sts, tokens is a set of roles.
>>>>
>>>> Flow
>>>> 1. The client ask for a the tokens belonging to him, is this context a
>>>> list
>>>> of roles, based on the username and password of the user. Signed and
>>>> encrypted by the uses private key
>>>>
>>>> 2. Sts service then validates the signature and decrypts it.
>>>> 3.Creates a token with the roles for the user and signs/encrypts this
>>>> with
>>>> the private key of the sts service. And wrapping it inside a
>>>> RequestSecuritTokenResponse lookking something like this
>>>>
>>>> <RequestSecuritTokenResponse>
>>>> <com:Token xmlns:com="http://common" xmlns:oas="
>>>>
>>>>
>>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>>> "
>>>> oas:Id="id_145663">
>>>> <com:Username>testu</com:Username>
>>>> <com:RoleInProject>
>>>> <com:Role>ADMIN</com:Role>
>>>> <com:Project>testu_project</com:Project>
>>>> </com:RoleInProject>
>>>> </com:Token>
>>>> </ns:RequestedSecurityToken>
>>>> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#
>>>> ">
>>>> <ds:SignedInfo>
>>>> <ds:CanonicalizationMethod Algorithm="
>>>> http://www.w3.org/2001/10/xml-exc-c14n#" />
>>>> <ds:SignatureMethod Algorithm="
>>>> http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
>>>> <ds:Reference
>>>> URI="#_0de82a70b0ad68d7b29387828b2ba3ec">
>>>> <ds:Transforms>
>>>> <ds:Transform Algorithm="
>>>> http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
>>>> <ds:Transform Algorithm="
>>>> http://www.w3.org/2001/10/xml-exc-c14n#">
>>>> <ec:InclusiveNamespaces xmlns:ec="
>>>> http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="code ds kind rw
>>>> saml
>>>> samlp typens #default xsd xsi" />
>>>> </ds:Transform>
>>>> </ds:Transforms>
>>>> <ds:DigestMethod Algorithm="
>>>> http://www.w3.org/2000/09/xmldsig#sha1" />
>>>>
>>>> <ds:DigestValue>EFf0+eeFzPPm3eG+MJkfYbTsrrY=</ds:DigestValue>
>>>> </ds:Reference>
>>>> </ds:SignedInfo>
>>>> <ds:SignatureValue>GQt+8+NOn=</ds:SignatureValue>
>>>> <ds:KeyInfo>
>>>>
>>>> <ds:X509Data>dnfjngjknfjkgnjkfngjknfjgnjf</ds:X509Certificate>
>>>> </ds:X509Data>
>>>> </ds:KeyInfo>
>>>> </ds:Signature>
>>>> <RequestSecuritTokenResponse>
>>>>
>>>> This of course is much similar to a saml assertion.
>>>>
>>>> then this is encrypted and signed using the sts private key.
>>>>
>>>> 4 The client verifies that the message comes form the sts and extracts
>>>> the
>>>> token from the message, finally places it in the header for the request
>>>> to
>>>> the target service. signs and encrypts it with the client's private key.
>>>>
>>>> 5. Now the target service decrypt the message, extract the token form
>>>> the
>>>> header , looks to see if this was signed with the private key of the
>>>> sts.
>>>> If
>>>> so the perform the authorization based on the attributes in the token.
>>>>
>>>> Is this the correct way of accomplishing trust, and how the target
>>>> service
>>>> knows that these tokens is issued by the sts service?
>>>>
>>>> Really appreciate replays on this topic
>>>>
>>>> cheers, Håkon
>>>>
>>>> --
>>>> Håkon Sagehaug, Scientific Programmer
>>>> Parallab, Bergen Center for Computational Science (BCCS)
>>>> UNIFOB AS (University of Bergen Research Company)
>>>>
>>>>
>>>>
>>>
>>> ----------------------------------------------------------------
>>> This message was sent using IMP, the Internet Messaging Program.
>>>
>>>
>>>
>>>
>>
>> --
>> Håkon Sagehaug, Scientific Programmer
>> Parallab, Bergen Center for Computational Science (BCCS)
>> UNIFOB AS (University of Bergen Research Company)
>>
>>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
--
Håkon Sagehaug, Scientific Programmer
Parallab, Bergen Center for Computational Science (BCCS)
UNIFOB AS (University of Bergen Research Company)
Re: General setup of ws-trust
Posted by Massimiliano Masi <ma...@math.unifi.it>.
Hakon,
Yes, it's only xml, but is important! (The RSTRC). :-)
I don't understand your security token, I don't know
if you expressed it correctly:
You have a
<RequestSecurityTokenResponse>
< -- missing RequestedSecurityToken >
<com:Token that's ok
but you are signing something that I cannot see
and try to use a more powerful id, instead of id_145663
Try to paste another XML. ;-)
Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
> Hi
>
> Thanks for the replay
>
> see inline
>
> 2009/3/20 Massimiliano Masi <ma...@math.unifi.it>
>
>> Hi,
>>
>> In general you should encrypt a message using the
>> public key of the recipient and sign with the private
>> key of the sender. This enforces integrity (the signature), authentication
>> (the signature) and confidentiality (the encryption).
>>
>> As I told you, the RSTR is not correct. You really should
>> use the RSTRC instead, since it is only request/response.
>
> I forgot to have this element, but it's only sudo xml
>
>>
>>
>> The service ``trust'' the token, since it is signed
>> by the STS, and we suppose that the STS that owns the
>> private key.
>>
>> Pay attention for the STS to not be an oracle.
>
>
> We're implementing a sts of our own, and trying to get it all together. The
> reason why I'm asking all these questions, for getting the hole picture.
>
> Also, is the way I described the security token correct? This token is of
> course not how it looks in the real world but have the important elements.
>
> cheers, håkon
>
>
>
>> Please, look at the
>> 11 suggestions on how to write security protocols, written
>> in 80's by Martin Abadi.
>>
>>
>>
>>
>> Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
>>
>> Hi all,
>>>
>>> I've been trying to really to understand ws-trust from the more general
>>> perspective, so maybe not the question should go out here, but since
>>> rampart
>>> is ws-trust implementation I hope it's okay.
>>>
>>> My setup is the classical ws-trust setup
>>> 1.Client
>>> 2.Sts
>>> 3.Target service
>>>
>>> The target service does not know about user, but trust the token issued by
>>> the sts, tokens is a set of roles.
>>>
>>> Flow
>>> 1. The client ask for a the tokens belonging to him, is this context a
>>> list
>>> of roles, based on the username and password of the user. Signed and
>>> encrypted by the uses private key
>>>
>>> 2. Sts service then validates the signature and decrypts it.
>>> 3.Creates a token with the roles for the user and signs/encrypts this with
>>> the private key of the sts service. And wrapping it inside a
>>> RequestSecuritTokenResponse lookking something like this
>>>
>>> <RequestSecuritTokenResponse>
>>> <com:Token xmlns:com="http://common" xmlns:oas="
>>>
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>> "
>>> oas:Id="id_145663">
>>> <com:Username>testu</com:Username>
>>> <com:RoleInProject>
>>> <com:Role>ADMIN</com:Role>
>>> <com:Project>testu_project</com:Project>
>>> </com:RoleInProject>
>>> </com:Token>
>>> </ns:RequestedSecurityToken>
>>> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#
>>> ">
>>> <ds:SignedInfo>
>>> <ds:CanonicalizationMethod Algorithm="
>>> http://www.w3.org/2001/10/xml-exc-c14n#" />
>>> <ds:SignatureMethod Algorithm="
>>> http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
>>> <ds:Reference
>>> URI="#_0de82a70b0ad68d7b29387828b2ba3ec">
>>> <ds:Transforms>
>>> <ds:Transform Algorithm="
>>> http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
>>> <ds:Transform Algorithm="
>>> http://www.w3.org/2001/10/xml-exc-c14n#">
>>> <ec:InclusiveNamespaces xmlns:ec="
>>> http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="code ds kind rw saml
>>> samlp typens #default xsd xsi" />
>>> </ds:Transform>
>>> </ds:Transforms>
>>> <ds:DigestMethod Algorithm="
>>> http://www.w3.org/2000/09/xmldsig#sha1" />
>>>
>>> <ds:DigestValue>EFf0+eeFzPPm3eG+MJkfYbTsrrY=</ds:DigestValue>
>>> </ds:Reference>
>>> </ds:SignedInfo>
>>> <ds:SignatureValue>GQt+8+NOn=</ds:SignatureValue>
>>> <ds:KeyInfo>
>>>
>>> <ds:X509Data>dnfjngjknfjkgnjkfngjknfjgnjf</ds:X509Certificate>
>>> </ds:X509Data>
>>> </ds:KeyInfo>
>>> </ds:Signature>
>>> <RequestSecuritTokenResponse>
>>>
>>> This of course is much similar to a saml assertion.
>>>
>>> then this is encrypted and signed using the sts private key.
>>>
>>> 4 The client verifies that the message comes form the sts and extracts the
>>> token from the message, finally places it in the header for the request
>>> to
>>> the target service. signs and encrypts it with the client's private key.
>>>
>>> 5. Now the target service decrypt the message, extract the token form the
>>> header , looks to see if this was signed with the private key of the sts.
>>> If
>>> so the perform the authorization based on the attributes in the token.
>>>
>>> Is this the correct way of accomplishing trust, and how the target service
>>> knows that these tokens is issued by the sts service?
>>>
>>> Really appreciate replays on this topic
>>>
>>> cheers, Håkon
>>>
>>> --
>>> Håkon Sagehaug, Scientific Programmer
>>> Parallab, Bergen Center for Computational Science (BCCS)
>>> UNIFOB AS (University of Bergen Research Company)
>>>
>>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>>
>
>
> --
> Håkon Sagehaug, Scientific Programmer
> Parallab, Bergen Center for Computational Science (BCCS)
> UNIFOB AS (University of Bergen Research Company)
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Re: General setup of ws-trust
Posted by Håkon Sagehaug <Ha...@bccs.uib.no>.
Hi
Thanks for the replay
see inline
2009/3/20 Massimiliano Masi <ma...@math.unifi.it>
> Hi,
>
> In general you should encrypt a message using the
> public key of the recipient and sign with the private
> key of the sender. This enforces integrity (the signature), authentication
> (the signature) and confidentiality (the encryption).
>
> As I told you, the RSTR is not correct. You really should
> use the RSTRC instead, since it is only request/response.
I forgot to have this element, but it's only sudo xml
>
>
> The service ``trust'' the token, since it is signed
> by the STS, and we suppose that the STS that owns the
> private key.
>
> Pay attention for the STS to not be an oracle.
We're implementing a sts of our own, and trying to get it all together. The
reason why I'm asking all these questions, for getting the hole picture.
Also, is the way I described the security token correct? This token is of
course not how it looks in the real world but have the important elements.
cheers, håkon
> Please, look at the
> 11 suggestions on how to write security protocols, written
> in 80's by Martin Abadi.
>
>
>
>
> Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
>
> Hi all,
>>
>> I've been trying to really to understand ws-trust from the more general
>> perspective, so maybe not the question should go out here, but since
>> rampart
>> is ws-trust implementation I hope it's okay.
>>
>> My setup is the classical ws-trust setup
>> 1.Client
>> 2.Sts
>> 3.Target service
>>
>> The target service does not know about user, but trust the token issued by
>> the sts, tokens is a set of roles.
>>
>> Flow
>> 1. The client ask for a the tokens belonging to him, is this context a
>> list
>> of roles, based on the username and password of the user. Signed and
>> encrypted by the uses private key
>>
>> 2. Sts service then validates the signature and decrypts it.
>> 3.Creates a token with the roles for the user and signs/encrypts this with
>> the private key of the sts service. And wrapping it inside a
>> RequestSecuritTokenResponse lookking something like this
>>
>> <RequestSecuritTokenResponse>
>> <com:Token xmlns:com="http://common" xmlns:oas="
>>
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> "
>> oas:Id="id_145663">
>> <com:Username>testu</com:Username>
>> <com:RoleInProject>
>> <com:Role>ADMIN</com:Role>
>> <com:Project>testu_project</com:Project>
>> </com:RoleInProject>
>> </com:Token>
>> </ns:RequestedSecurityToken>
>> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#
>> ">
>> <ds:SignedInfo>
>> <ds:CanonicalizationMethod Algorithm="
>> http://www.w3.org/2001/10/xml-exc-c14n#" />
>> <ds:SignatureMethod Algorithm="
>> http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
>> <ds:Reference
>> URI="#_0de82a70b0ad68d7b29387828b2ba3ec">
>> <ds:Transforms>
>> <ds:Transform Algorithm="
>> http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
>> <ds:Transform Algorithm="
>> http://www.w3.org/2001/10/xml-exc-c14n#">
>> <ec:InclusiveNamespaces xmlns:ec="
>> http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="code ds kind rw saml
>> samlp typens #default xsd xsi" />
>> </ds:Transform>
>> </ds:Transforms>
>> <ds:DigestMethod Algorithm="
>> http://www.w3.org/2000/09/xmldsig#sha1" />
>>
>> <ds:DigestValue>EFf0+eeFzPPm3eG+MJkfYbTsrrY=</ds:DigestValue>
>> </ds:Reference>
>> </ds:SignedInfo>
>> <ds:SignatureValue>GQt+8+NOn=</ds:SignatureValue>
>> <ds:KeyInfo>
>>
>> <ds:X509Data>dnfjngjknfjkgnjkfngjknfjgnjf</ds:X509Certificate>
>> </ds:X509Data>
>> </ds:KeyInfo>
>> </ds:Signature>
>> <RequestSecuritTokenResponse>
>>
>> This of course is much similar to a saml assertion.
>>
>> then this is encrypted and signed using the sts private key.
>>
>> 4 The client verifies that the message comes form the sts and extracts the
>> token from the message, finally places it in the header for the request
>> to
>> the target service. signs and encrypts it with the client's private key.
>>
>> 5. Now the target service decrypt the message, extract the token form the
>> header , looks to see if this was signed with the private key of the sts.
>> If
>> so the perform the authorization based on the attributes in the token.
>>
>> Is this the correct way of accomplishing trust, and how the target service
>> knows that these tokens is issued by the sts service?
>>
>> Really appreciate replays on this topic
>>
>> cheers, Håkon
>>
>> --
>> Håkon Sagehaug, Scientific Programmer
>> Parallab, Bergen Center for Computational Science (BCCS)
>> UNIFOB AS (University of Bergen Research Company)
>>
>>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
--
Håkon Sagehaug, Scientific Programmer
Parallab, Bergen Center for Computational Science (BCCS)
UNIFOB AS (University of Bergen Research Company)
Re: General setup of ws-trust
Posted by Massimiliano Masi <ma...@math.unifi.it>.
Hi,
In general you should encrypt a message using the
public key of the recipient and sign with the private
key of the sender. This enforces integrity (the signature), authentication
(the signature) and confidentiality (the encryption).
As I told you, the RSTR is not correct. You really should
use the RSTRC instead, since it is only request/response.
The service ``trust'' the token, since it is signed
by the STS, and we suppose that the STS that owns the
private key.
Pay attention for the STS to not be an oracle. Please, look at the
11 suggestions on how to write security protocols, written
in 80's by Martin Abadi.
Quoting Håkon Sagehaug <Ha...@bccs.uib.no>:
> Hi all,
>
> I've been trying to really to understand ws-trust from the more general
> perspective, so maybe not the question should go out here, but since rampart
> is ws-trust implementation I hope it's okay.
>
> My setup is the classical ws-trust setup
> 1.Client
> 2.Sts
> 3.Target service
>
> The target service does not know about user, but trust the token issued by
> the sts, tokens is a set of roles.
>
> Flow
> 1. The client ask for a the tokens belonging to him, is this context a list
> of roles, based on the username and password of the user. Signed and
> encrypted by the uses private key
>
> 2. Sts service then validates the signature and decrypts it.
> 3.Creates a token with the roles for the user and signs/encrypts this with
> the private key of the sts service. And wrapping it inside a
> RequestSecuritTokenResponse lookking something like this
>
> <RequestSecuritTokenResponse>
> <com:Token xmlns:com="http://common" xmlns:oas="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
> oas:Id="id_145663">
> <com:Username>testu</com:Username>
> <com:RoleInProject>
> <com:Role>ADMIN</com:Role>
> <com:Project>testu_project</com:Project>
> </com:RoleInProject>
> </com:Token>
> </ns:RequestedSecurityToken>
> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <ds:SignedInfo>
> <ds:CanonicalizationMethod Algorithm="
> http://www.w3.org/2001/10/xml-exc-c14n#" />
> <ds:SignatureMethod Algorithm="
> http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
> <ds:Reference
> URI="#_0de82a70b0ad68d7b29387828b2ba3ec">
> <ds:Transforms>
> <ds:Transform Algorithm="
> http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
> <ds:Transform Algorithm="
> http://www.w3.org/2001/10/xml-exc-c14n#">
> <ec:InclusiveNamespaces xmlns:ec="
> http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="code ds kind rw saml
> samlp typens #default xsd xsi" />
> </ds:Transform>
> </ds:Transforms>
> <ds:DigestMethod Algorithm="
> http://www.w3.org/2000/09/xmldsig#sha1" />
>
> <ds:DigestValue>EFf0+eeFzPPm3eG+MJkfYbTsrrY=</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
> <ds:SignatureValue>GQt+8+NOn=</ds:SignatureValue>
> <ds:KeyInfo>
>
> <ds:X509Data>dnfjngjknfjkgnjkfngjknfjgnjf</ds:X509Certificate>
> </ds:X509Data>
> </ds:KeyInfo>
> </ds:Signature>
> <RequestSecuritTokenResponse>
>
> This of course is much similar to a saml assertion.
>
> then this is encrypted and signed using the sts private key.
>
> 4 The client verifies that the message comes form the sts and extracts the
> token from the message, finally places it in the header for the request to
> the target service. signs and encrypts it with the client's private key.
>
> 5. Now the target service decrypt the message, extract the token form the
> header , looks to see if this was signed with the private key of the sts. If
> so the perform the authorization based on the attributes in the token.
>
> Is this the correct way of accomplishing trust, and how the target service
> knows that these tokens is issued by the sts service?
>
> Really appreciate replays on this topic
>
> cheers, Håkon
>
> --
> Håkon Sagehaug, Scientific Programmer
> Parallab, Bergen Center for Computational Science (BCCS)
> UNIFOB AS (University of Bergen Research Company)
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.