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 <[email protected]>:
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 <[email protected]>
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 <[email protected]>:
Hi
Thanks for the replay
see inline
2009/3/20 Massimiliano Masi <[email protected]>
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 <[email protected]>:
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.
