The
problem is that to decrypt the data you have to understand the XML which tells
you the algorithm, key identifier, etc. To do that you have to parse the XML so
if you have an invalid schema, that is a problem.
Of
course there are workarounds, like not validating the schema, but the SS TC
considered it desirable to make the encrypted data a part of the SAML Schema. I
think the motivation was that since the contents of the Assertion are something
that will be depended upon to make security decisions, it is desirable to define
it very tightly so as to avoid ambiguity or misuse.
Hal
-----Original Message-----
From:
[mailto:]
Sent: Monday, October 31, 2011 3:27
PM
To: Hal Lockhart
Cc: Cantor, Scott; Yang, Gang USA CTR
(US);
Subject: RE: [saml-dev]
encrypting saml protocol messages
Thanks, Hal,
agreed.. but can't
a Saml Response element contain an encrypted element inside of it? If we
detect the EncryptedElement in DOM/SAX then before passing things to OpenSAML
(which is the reference implementation we are using), we should decrypt it
first.
Isn't that the assumption
that we're going to have to work with?
we are working with SAML 2.0
thanks so much
Stephen
From: Hal Lockhart <>
To:
"Yang, Gang USA CTR (US)"
<>
Cc: , "Cantor, Scott"
<>
Date: 10/31/2011 08:53 AM
Subject: RE: [saml-dev] encrypting saml protocol messages
First note that the Request,
Response and Assertion may all be strongly Authenticated and Integrity
Protected with a signature. In fact Integrity protection is crucial for the
SSO Profiles, otherwise anyone could present any Assertion they wanted.
If you
look at the contents of the Request and Response, aside from the Assertion,
the other fields are generally known or can easily be guessed from simply
observing the message flows, the timer of day, etc. Further the "intermediary
agent" is in fact the user agent, i.e. Browser. It is hard to see how there
could be a threat of the user knowing that he will shortly be asked to
Authenticate or the request was successful or unsuccessful.
No XML level
encryption was provided in SAML 1.0 or 1.1. (Wrapped keys could be
transmitted, but that simply referenced other specs.) In most cases, all the
information including attribute names and values was well known to everyone.
The key security issue was whether they were being asserted by a trusted
authority.
For SAML 2.0 three usecases for encryption were identified:
1) encrypt the entire Assertion, 2) encrypt the NameID and 3) encrypt
Attributes. The primary motive was privacy protection. One goal was to include
the encrypted data in the schema, so that Assertions with encrypted components
would be Schema valid.
Of course you can always encrypt any XML document
as specified by XML Encryption, if you don't care about Schema
validity.
Hal
-----Original
Message-----
From: Yang, Gang USA CTR (US) [mailto:]
Sent: Friday, October 28, 2011 12:54 PM
To: Hal
Lockhart
Subject: RE: [saml-dev] encrypting saml protocol
messages
Thanks to all replies. I don't
have a special use case, except trying to implement the Web SSO profile. I
understand that WS-Security can be used to protect SAML messages in SOAP
bindings. But if HTTP-Redirect or HTTP-POST bindings are used, then SAML
messages are in the clear to the intermediary agent even if TLS is used for
hub-to-hub protection. But as you pointed out, what need to be protected is in
the Assertion and does have encryption define. Isn't there any thing that is
worth protecting in the rest of the SAML messages besides the
Assertion?
Any way, just curious why encryption is singled out for
SAML messages.
Thanks,
Gang
From: Hal Lockhart
[]
Sent: Thursday, October 27, 2011 9:57
AM
To: Yang, Gang USA CTR (US);
Subject: RE: [saml-dev] encrypting
saml protocol messages
The
SAML request/response protocol is carried over SOAP which means you can use
either WS-Security or TLS to encrypt the message in transit (and in the case
of WS-Security, keep the encrypted message around if you wish.) When
Assertions are returned over HTTP, TLS may be used. The SAML TC did not see a
need to difine yet another way to do the same thing. The assumption was that
if you wish to persist data which needs to be confidential, that data will be
contained in the Assertion.
What is your use case?
Hal
-----Original
Message-----
From: Yang, Gang USA CTR (US) [mailto:]
Sent: Monday, October 24, 2011 3:09 PM
To:
Subject: [saml-dev] encrypting saml
protocol messages
Hi,
I'm trying to
implement Web SSO profile and wondering why SAML 2.0 did not define the
encryption of SAML procotol messages (request/response), but only encryption
of the SAML assertion and some sub elements. Can any one shed some light on
this?
Thanks,
Gang
