shibboleth Idp attributes with vendor SP using Samly

[Peter Schober]

* Jehan PROCACCIA <jehan.procaccia at tem-tsp.eu> [2020-07-16 13:38]:
> thank you for your detail responses, it helped a lot and this
> experience me to IDP v4 which seems to work like a charm with recent
> environement (OS, tomcat, java) .

Glad I could help.

> this is not a demo, I created a dedicated IDP for that SP because it
> ask for specific restrictions as for that unique use of a single
> certificate for signing and no encrypt.
> I do have an IDP v3 in production that works fine in our French
> federation, but didn't want to tweak with it for that SP that
> "samly" SP also doesn't support discovery service, so we'll have to
> consolidate ldap directories in that dedicated IDP v4

I may not have the full picture here but I thought in the end there
was nothing you had to change on the IDPv4 for that SP, anyway?
Which means you should be able to use your existing IDP with that SP
just fine (as you also demonstrated earlier by hooking up your IDPv3
successfully)?

So no need for a separate IDP or extensive (or any!) tuning of the
existing IDP just for this SP -- just update your IDPv3 to v4 when you
have the time (before the end of the year) and move on to other
problems!

Even if that SP required a configuration change on your IDP: Running a
separate IDP for a single SP only to avoid having to configure your
software (as it is intended to be configured, as needed) is madness.
You'd end up running dozens of IDPs pretty soon if you followed that
method consistently, I think.
So I'd urge you to reconsider running two IDPs when a single one can
should be able to do that easily.

The fact that the SP doesn't support SAML IDP Discovery is not
surprising (since it only supports hard-coded IDP config, AFAIU) but
also irrelevant to your IDP configuration or choice of version (v3
vs. v4): You just hardcode the IDP's entityID into the SP.
So that doesn't factor into this discussion at all.

Cheers,
-peter