Pablo Cibraro wrote:
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.
I believe username for certificate is used currently with Metro
implementation.
Thanks!
Jiandong
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.
