shibboleth Idp attributes with vendor SP using Samly

[Peter Schober]

* Jehan PROCACCIA <jehan.procaccia at tem-tsp.eu> [2020-07-15 17:29]:
> the remote party finnaly manage to get our mail attribute (called email on their side !) 
> so then, everything  was fine with that "old" idp v3.3.1, 
> Now I move to idp v 4.0.1 , unfortunatly now it fails again on their side , before attributes exchange, at the SSO stage, with certificate check :-( 

Note that attributes should be sent as part of the "SSO stage", not in
a later/separate "attribute exchange".

Also, you can easily compare what data your IDPv3 is/would be sending
and what IDPv4 is/would, by using each version's aacli.sh tool,
e.g. with the --saml2 parameter, without even turnign up the log
level.

> The issue they see is "cert_not_accepted". 
> indeed , we miss logs and detail information from the remote party, but I cannot get them directly and I have to reverse engineer/guess what could be wrong on both sides . 
> I compared my IDP configurations from v3.3.1 to v4.0.1 , they don't seem to change a lot exept from the size of the x509 cert "signing" which is "bigger" in latest version .
> this cert was auto-generated when I ran the initial install.sh script, 
> could there be compatibility issue in term of size of certs ? 
> is there a way to check the keysize used by the install script ?

So you installed a brand new IDPv4, giving it a separate entityID and
registered /another/ IDP with the SP?

Or did you simply install a brand new IDPv4, using the existing
entityID of your IDPv3 IDP, but using the auto-generated (i.e.,
completely different) key material that the installer would only
create for new installs (but not for upgrades) and expect the SP to
work, even though it only has the public keys for your old IDP
available?

If the latter then this is a *good* sign: If the SP accepted a signed
response/assertion from an IDP claiming to be your old IDP (by using
your existing entityID) but signing it with a completely different key
than what the SP has on record (your existing IDP's public key) the SP
would have a huge security whole (or more exactly: no security at
all).

So this all depends on what exactly you did wrt IDPv3 and IDPv4
(e.g. ignoring all the warnings and advice given on the IDPv4
documentation about upgrading from v3) and how you expect the SP to
work in light of that (maybe you provided it with changed
metadata/public keys, maybe you didn't).

I can only guess at the meaning of the error message from the SP.
To get the precise meaning you'd have to ask the SP or -- more
likely -- read the source code where that error comes from.
FWIW, I couldn't find the string "cert_not_accepted" in either the
"samly" project source code https://github.com/handnot2/samly nor in
its dependency https://github.com/handnot2/esaml -- maybe I'm looking
at the code, or maybe the error comes from the applicaton, not the
libraries I've been referring to.

Cheers,
-peter