shibboleth Idp attributes with vendor SP using Samly

[Jehan PROCACCIA]

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 wonder if it is capable to "daisy chain" over our different school's individuals ldap ?  

Anyway , my initial pb regarding the certificat is resolved , it was just a missmatch between the one publish in metadata for signing and the one loaded by the idp ( idp-backchannel.crt vs idp-signing.crt !) , sorry for noise regarding that pb . 
the one about resolving attribute was also corrected by an intervention on the vendor SP side (not sure but probably a simple missmatch between mail vs email attribute name )

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

Regards .   


   

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

* Jehan PROCACCIA <jehan.procaccia at tem-tsp.eu> [2020-07-15 20:42]:
> I did not update idp v3 to v4
> I created a completly new VM aside the v3 
> that new VM is centos 8 , java 11, tomcat 9 , it has it's own new EntityID and hence new cert and new metadata.

So is this all just a toy/test/demo environment?
Why else would you ever change your entityID -- as part of a software
upgrade or otherwise?

So if this is a completely different IDP (new entityID, new endpoints,
new keys) everything you said about IDPv3 working with this SP is
pretty much irrelevant, I guess.

IMO this thread simply comes down to using a fresh IDPv4 instance with
that specific SP implementation. Since we already identified the
likely source of the error (see my previous post) the only thing left
to do here is picking the right certificate to manually configure into
the SP, with no changes to the IDP's default configuration /at all/.

-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