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.
