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 <[email protected]> > 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 <[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. > > > -- Håkon Sagehaug, Scientific Programmer Parallab, Bergen Center for Computational Science (BCCS) UNIFOB AS (University of Bergen Research Company)
