<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 5/6/17 4:07 AM, Jehan Procaccia
wrote:SecurityConfiguration-SigningandEncryptionEnablement
</div>
<blockquote type="cite" cite="mid:590D845C.4030105@it-sudparis.eu"><code
class="xml string"></code><br>
<code class="xml string"></code>
<div class="container" title="Hint: double-click to select code">
<div class="line number9 index8 alt2"><code class="xml string">
<br>
</code>I set <code class="xml color1">signAssertions</code><code
class="xml plain">=</code><code class="xml string">"true"</code>
<code class="xml color1">p:encryptAssertions</code><code
class="xml plain">=</code><code class="xml string">"true" </code>,
and now lightsmal SP accept the now signed assertions. <br>
<br>
we have dozens of IDPs in our federation, it would be
cumbersome to ask each IDP mainteners to set this bean for
that SP ,<br>
</div>
</div>
</blockquote>
<br>
Well, if that's a specific requirement of the SP, then that's what
they require. That's why the RP overrides exist.<br>
<br>
<blockquote type="cite" cite="mid:590D845C.4030105@it-sudparis.eu">
<div class="container" title="Hint: double-click to select code">
<div class="line number9 index8 alt2"> isn't there a global
default setting to ask the IDP to sign assertions in any case
? <br>
</div>
</div>
</blockquote>
<br>
Yes, you set the same attribute on the same profile config for the
'shibboleth.DefaultRelyingParty', instead of on a specific RP
override. But that seems ill-advised at best - why incur that cost
for every response to every RP? At worst it might even break some
SPs who now will get signed assertions and don't know what to do
with them (Hopefully not, but maybe. We've seen crazier things
happen.)<br>
<br>
<blockquote type="cite" cite="mid:590D845C.4030105@it-sudparis.eu">
<div class="container" title="Hint: double-click to select code">
<div class="line number9 index8 alt2"> would it overload the
saml echanges in a significant manner? <br>
</div>
</div>
</blockquote>
<br>
Signing is expensive, so needlessly signing the assertions to every
RP is going to incur a lot more computational cost, for no real
reason. You should really just configure to sign assertions to this
one RP, if that's what they require.<br>
<br>
As a side note, it's questionable whether this lightSAML SP
implementation really ought to be requiring signed Assertions, based
on that language in the spec. The spec says in Profiles, sec
4.1.3.5, line 498:<br>
<br>
<blockquote type="cite">The <Assertion> element(s) in the<br>
<Response> MUST be signed, if the HTTP POST binding is used,
and MAY be signed if the HTTPArtifact<br>
binding is used.</blockquote>
<br>
but I think our interpretation (and apparently most SP
interpretations, since they don't have this requirement) is not that
the Assertion itself literally has to be signed. We interpret to
mean more broadly that the Assertion has to be covered by a
signature. So a signature on the SAML Response covers the Assertion
also, as would a POST SimpleSign binding-level signature.<br>
<br>
Scott may have different take on it. If we take the Profiles
language in its literal interpretation, then that's potentially a
problem for our IdP. But I don't think that's the case.<br>
<br>
<br>
</body>
</html>