Override per-SP metadata with cron metarefresh

[Andrew Klaus]

Hello,

We currently have an IdP setup and are part of an interfederation. The interfederation metadata is handled by a single URL https://caf-shib2ops.ca/CoreServices/caf_metadata_signed_sha256.xml and metarefresh pulls it regularly using cron.

I've set 'assertion.encryption' to True by default on the IdP, but a few specific SPs don't work with assertion encryption enabled.  There is a way to override SP metadata under "template" in the metarefresh configuration file, but is there a way to override only a handful of specific entities inside the fetched metadata?

Thanks,

Andrew

[Jaime Perez Crespo]

Hi Andrew,

Not that I can recall right now.

However, you could do this in a custom authproc filter. Basically, add a new authproc filter that looks at the SP metadata, checks if the entityID is in a list of entityIDs provided via configuration, and if so, modify the metadata accordingly (in this case, modifying the “assertion.encryption” option to set it to false).

--
Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Peter Schober]

* Andrew Klaus <andre...@gmail.com> [2016-09-22 01:57]:

> I've set 'assertion.encryption' to True by default on the IdP, but a few
> specific SPs don't work with assertion encryption enabled. There is a way
> to override SP metadata under "template" in the metarefresh configuration
> file, but is there a way to override only a handful of specific entities
> inside the fetched metadata?

Are you saying those SPs expect something other than the Assertion to
be encrypted (e.g. the Reponse, or individual Attributes?)
Or do those SPs not support encryption at all?

I'm assuming the latter, but then why not fix those entities' metadata
so they don't announce keys (certificates) for uses they don't actually
support?
(And unless such SPs sign their SAML 2.0 authentication requests --
most SPs don't, even less likely for SPs that can't handle encrypted
data -- there's no reason for such an SP to carry a key at all.)

Not sure how SimpleSAMLphp deals with such cases currently. It may
need a setting that tells the IDP whether to fail the transaction when
data cannot be encrypted (either on the IDP end or by sending a SAML
error to the SP), or whether to silently send the data unencrypted.

That would then "just work" without requiring local configuration on
each IDP federating with such SPs.
-peter