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:59:20 GMT
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 <Hakon.Sagehaug@bccs.uib.no>:

> Hi
>
> Thanks for the replay
>
> see inline
>
> 2009/3/20 Massimiliano Masi <masi@math.unifi.it>
>
>> 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 <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.
>>
>>
>>
>
>
> --
> 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