Assertion signing and encryption question

[Brent Putman]

On 10/28/15 2:56 PM, Elena Ryazanova wrote:


As preface, note that there are 2 signing possibilities here: 1) the
Assertion and 2) the Response (containing Assertion(s) or
EncryptedAssertion(s)).  I don't know which you are doing. You could be
doing both, which isn't wrong.


> Here is what the vendor says: 
> "SP has determined that IdP encrypts the assertion and then signs the
> encryption

That could only be true of the Response signature. There is literally
no way to sign the Assertion itself once it's encrypted.  There's no
place in the XML to put it.



> SP code works as follows:  (1) First decrypt the assertion and (2)
> then compute the signature

That would only be valid if they're talking about the *Assertion*
signature.  It's inside the encryption, so it has to be that way. 

This would not be really be valid if they're talking about the
*Response* signature, assuming they replaced the EncryptedAssertion in
the Response with the decrypted Assertion.  You have to validate the
Response signature over the entire Response as-is, with any
Assertion(s) and/or EncryptedAssertion(s) intact (since that's how it
was signed - see below).

So, if the Response is signed, that is generally the first thing you
do, no matter what else is signed and/or encrypted.


> With the signature not inside the encryption SP would need IdP to
> sign the assertion prior to encryption".
>
> Are there any options in IdP configuration to control the order.

No.  And wouldn't make sense - there's only one correct order of
operations. 


> Is there any standard way to encrypt and sigh assertions?
>

In the spec you can refer them to SAML 2 Core section 6.2, which
discusses this specifically.

Essentially the order of operations at the IdP must be:

1) encrypt any NameIDs and Attributes (this is unsual btw)
2) sign the Assertion
3) encrypt the Assertion
4) sign the Response

At the SP it must be basically the reverse:

1) validate the signed Response
2) decrypt the EncryptedAssertion(s)
3) validate the signed (and decrypted) Assertion(s)
4) decrypt any NameIDs and Attributes

The SP order assumes decryption- with-replacement.  If you don't do
replacement, then the order is a little more flexible.  But the above
is still the most natural ordering.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151028/618bd592/attachment.html>