how to force idp v3 to sign saml assertion

[Brent Putman]

On 5/6/17 4:07 AM, Jehan Procaccia
wrote:SecurityConfiguration-SigningandEncryptionEnablement
> ||
> ||
> |
> |I set |signAssertions||=||"true"| |p:encryptAssertions||=||"true" |,
> and now lightsmal SP accept the now signed assertions.
>
> we have dozens of IDPs in our federation, it would be cumbersome to
> ask each IDP mainteners to set this bean for that SP ,

Well, if that's a specific requirement of the SP, then that's what they
require.  That's why the RP overrides exist.

> isn't there a global default setting to ask the IDP to sign
> assertions in any case ?

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.)

> would it overload the saml echanges in a significant manner?

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.

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:

> The <Assertion> element(s) in the
> <Response> MUST be signed, if the HTTP POST binding is used, and MAY
> be signed if the HTTPArtifact
> binding is used.

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.

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170506/7c6b3251/attachment.html>