On 3/20/07, Duane Merrill III <dgm4d@virginia.edu> wrote:
During last week's face-to-face, Frank had requested a brief overview of Liberty's message level security mechanisms.
Nice summary.
There does not appear to be a mechanism for specifying if/what encryption needs to be done at the message level (as required by the service resource). They suggest that message-level encryption be used in the presence of intermediaries, but it would appear that doing so would be at the discretion of the client; there is no mechanism for making it a provider-requirement.
In the case of SAML V2.0 tokens, the SAML assertions (or portions thereof) may themselves be encrypted. See the SAML V2.0 Core spec http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf and the ID-WSF 2.0 SecMech SAML Profile: http://www.projectliberty.org/liberty/content/download/894/6258/file/liberty... In the latter document, you will find examples of encrypted name identifiers and encrypted attributes. SAML V2.0 Core specifies encrypted assertion elements as well, but these aren't explicitly mentioned in the SecMech SAML Profile AFAICT. Also, SAML V2.0 assertions may be passed in the message header by reference (URI). See section 3.7 of the SAML V2.0 Bindings spec http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf and of course the WSS SAML Token Profile v1.1. In that case, resolution of the assertion reference is conducted over a secure channel. Moreover, the assertion itself may be encrypted (as above), which provides additional security. Tom Scavo NCSA