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.


Reply via email to