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)
