axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Massimiliano Masi <m...@math.unifi.it>
Subject Re: General setup of ws-trust
Date Fri, 20 Mar 2009 12:31:35 GMT
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 <Hakon.Sagehaug@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.



Mime
View raw message