shibboleth Idp attributes with vendor SP using Samly

[Jehan PROCACCIA]

I understand that I could use only one IDP, and because I needed a test IDP to validate/debug with that specific SP , I took advantage of that situation to create a v4 one . 
but that vendor SP is to be used by our dozen of schools that all have their own ID referentials (ldap), although they do have their own IDP, because that SP cannot provide users with an intermediate WAYF/DS before login in, I must have a uniq IDP that federate them all for that SP .
usually we take advantage of the french national federation + WAYF/DS to redirect our users to their home IDP before login in a federated SP ,
but here I need a dedicated IDP that can identify all our schools users IDs in a single referential. 
I cannot imagine a single IDP that could check IDs in a local ldap for Wayf/DS requests and check another ldap , or daisy chain againt all dozens of school's ldap when checking IDs for that specific SP that don't provide WAYF/DS .
Perhaps I missunderstood something , but I am pretty sure I cannot do this other way ? 

anyway, now it works fine with that vendor SP and dedicated IDP .
Now my next step to enable that IDP to check IDs against multiple ldap servers , is this possible ? (maybe I should create a new thread with according subject ...) 

Thanks .

----- Mail original -----
De: "Peter Schober" <peter.schober at univie.ac.at>
À: "users" <users at shibboleth.net>
Envoyé: Jeudi 16 Juillet 2020 14:34:04
Objet: Re: shibboleth Idp attributes with vendor SP  using Samly

* 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
-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net