[ogsa-wg] Liberty message-level-sec mechanisms

[Tom Scavo]

On 3/20/07, Duane Merrill III <dgm4d at 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-idwsf-security-mechanisms-saml-profile-v2.0.pdf

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