<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 10/28/15 2:56 PM, Elena Ryazanova
wrote:<br>
</div>
<br>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAMtaZF1TyKRh1EfLdwq6YHemkg2O4=M7F-kZ6c=cMdMWKpenbg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Here is what the vendor says: </div>
<div>"SP has determined that IdP encrypts the assertion and then
signs the encryption</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAMtaZF1TyKRh1EfLdwq6YHemkg2O4=M7F-kZ6c=cMdMWKpenbg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>SP code works as follows: (1) First decrypt the assertion
and (2) then compute the signature</div>
</div>
</blockquote>
<br>
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. <br>
<br>
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).<br>
<br>
So, if the Response is signed, that is generally the first thing you
do, no matter what else is signed and/or encrypted.<br>
<br>
<br>
<blockquote
cite="mid:CAMtaZF1TyKRh1EfLdwq6YHemkg2O4=M7F-kZ6c=cMdMWKpenbg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>With the signature not inside the encryption SP would need
IdP to sign the assertion prior to encryption".</div>
<div><br>
</div>
<div>Are there any options in IdP configuration to control the
order. <br>
</div>
</div>
</blockquote>
<br>
No. And wouldn't make sense - there's only one correct order of
operations. <br>
<br>
<br>
<blockquote
cite="mid:CAMtaZF1TyKRh1EfLdwq6YHemkg2O4=M7F-kZ6c=cMdMWKpenbg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> Is there any standard way to encrypt and sigh assertions?</div>
<div><br>
</div>
</div>
</blockquote>
<br>
In the spec you can refer them to SAML 2 Core section 6.2, which
discusses this specifically.<br>
<br>
Essentially the order of operations at the IdP must be:<br>
<br>
1) encrypt any NameIDs and Attributes (this is unsual btw)<br>
2) sign the Assertion<br>
3) encrypt the Assertion<br>
4) sign the Response<br>
<br>
At the SP it must be basically the reverse:<br>
<br>
1) validate the signed Response<br>
2) decrypt the EncryptedAssertion(s)<br>
3) validate the signed (and decrypted) Assertion(s)<br>
4) decrypt any NameIDs and Attributes<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
</body>
</html>