shibboleth Idp attributes with vendor SP using Samly

[Jehan PROCACCIA]

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.
I did provide the new v4 metadata to the SP through there web import interface . I can confirm the did consumed them because when connecting to there SP I am redirected to my IDPv4 SSO URL as specified in those new metadata. 
there's one point where I am unsure ... it's because the SP did not support multiple certificate when importing IDP metadata, I can only have one for signing (no encrypt) , so I did tweak a little the installed metadata/idp-metadata.xml to cope with that 

I kept the 
    <KeyDescriptor use="signing">
            <ds:KeyInfo>
                    <ds:X509Data>
                        <ds:X509Certificate>
MIIEMzCCApugAwIBAgIUKri65l0V0H6cC23nYmidMHi0FgcwDQYJKoZIhvcNAQEL
...
SVNx5y5n+3dqzjCBdHjT9DLyl5wM5y8=
                        </ds:X509Certificate>
                    </ds:X509Data>
            </ds:KeyInfo>
        </KeyDescriptor>


but removed the encryption one :

        <KeyDescriptor use="encryption">
            <ds:KeyInfo>
                    <ds:X509Data>
                        <ds:X509Certificate>
MIIEMzCCApugAwIBAgIUPvK8LZh4tFf5QM/8V1XDhP0KAVMwDQYJKoZIhvcNAQEL


In conf/idp.properties I also commented out encyption.key/cert : 

idp.signing.key=%{idp.home}/credentials/idp-signing.key
idp.signing.cert=%{idp.home}/credentials/idp-signing.crt
#idp.encryption.key=%{idp.home}/credentials/idp-encryption.key
#idp.encryption.cert=%{idp.home}/credentials/idp-encryption.crt

and in  conf/credentials.xml I replace in  <util:list id="shibboleth.DefaultEncryptionCredentials">
 idp.encryption.key/cert with idp.signing.key/cert so that I repects SP need to have only one and unique signing cert :  

# diff conf/credentials.xml conf/credentials.xml.dist 
50d49
<     <!-- Jehan for recruitee, just one sign cert -->
53,54c52,53
<             p:privateKeyResource="%{idp.signing.key}"
<             p:certificateResource="%{idp.signing.cert}"
---
>             p:privateKeyResource="%{idp.encryption.key}"
>             p:certificateResource="%{idp.encryption.cert}"
55a55
> 

perhaps I did something wrong in all this .

Let me know if these actions could be wrong ? 

I did the same with the idp V3 instance, and it  worked, the VM is still there, I can roll back to v3, but it would be better to validate and run in V4 ! .
 
Thanks . 





----- Mail original -----
De: "Peter Schober" <peter.schober at univie.ac.at>
À: "users" <users at shibboleth.net>
Envoyé: Mercredi 15 Juillet 2020 18:29:27
Objet: Re: shibboleth Idp attributes with vendor SP  using Samly

* Peter Schober <peter.schober at univie.ac.at> [2020-07-15 18:06]:
> 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?
[...]
> 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 wrong code, or maybe the error comes from the applicaton, not
> the libraries I've been referring to.

OK, Github's code search simply sucks. But the issue (and code
reference) below explains the meaning and also confirms my guess that
you've probably misunderstood/botched your IDP upgrade by using
completly new/different keys from the installer. Copying over your old
IDPv3 keys should fix that. Or redoing your IDPv4 instance, really,
because who knows how many other things you've forgotten to carry over?

https://github.com/handnot2/samly/issues/42#issuecomment-457741186

  "If you search for cert_not_accepted in esaml, you will find that
  this error occurs when the cert fingerprint is not trusted. It is
  possible for this to happen when the certificate in the idp metadata
  file specified in the config does not match the one coming through
  the SAML response."

https://github.com/handnot2/esaml/blob/main/src/xmerl_dsig.erl#L209-L219

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