Hi Jiandong, What security policy are using for securing the messages of the Active STS and the requestor ?. The specification did not mentioned anything about this.
ActAs is just a wrapper element in the WS-Trust RST message to include the SAML assertion for the end user, as you already said. However, it does not mention anything about the way you identify the requestor or secure the message, that's part of the security policy. What we are proposing here is to use an additional X509 certificate to authenticate the requestor, and a X509 certificate (The STS certificate) to secure the message. Thanks Pablo. -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, September 29, 2009 4:02 PM To: [email protected] Subject: Re: Possible change in the Claim Based Implementation specification The Active STS has its own policy for securing the messages with the credentials of the STS and the requestor. The ActAs credential ( SAML assertion for the end user) is included in the pay load of the RST to the STS. The issued SAML assertion from the Active STS combines the identity/attributes for the end user and the requestor (with an actas attribute). This is how it is handled with Metro based implementation. The way that ActAs element in the RST is standard based and we have an agreement for the form of the actas attribute to ensure interoperability. Thanks! Jiandong Pablo Cibraro wrote: > We just found a possible security hole in the current application > specification. According to the specification, there is a trust relationship > between the Active STS and the Passive STS, so the web client should only > send the SAML token issued by the Passive STS (Signed with a certificate) to > the Active STS using WS-Trust with "ActAs". > The specification does not mention anywhere that the web application should > send an additional client credential (like a X509 certificate) to > authenticate itself against the Active STS. We discussed this with Vittorio > Bertocci, and he basically mentioned the following, > > "I would *strongly* encourage to secure the call between the frontend and the > ActAs STS. I would also suggest being extremely careful when using loaded > terms like "trust" in this context, "business trust" is not a well defined > term (ie does not map to a set of concrete requirements). > Attaching a token from the passive STS means nothing from the security > perspective: anybody who can obtain a token from the passive STS can pretend > to be your app, and validating the appliesto doesn't save you from DNS > attacks. > My suggestion would be to secure the RTS to the actas STS with the same cert > used for HTTPS on the frontend" > > This change in the specification certainly requires changes in the existing > implementations, and I am not sure if we are prepared to do that at this > point. We want to hear your opinions about whether we should move forward > with this change or not. > > Thanks > Pablo. > >
