Linos, You should only need one metadata file, with both certs in it. Could it be that one step uses the new and one uses the old which is causing the mismatch?
Ray On Wed, 2020-11-25 at 06:37 -0800, Linos Giannopoulos wrote: Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information. Hey, We have the following setup in place to utilize the per-SP configuration for the idP and so override the keys and metadata: ``` # user@cas-node[~] → tree /etc/cas/saml /etc/cas/saml ├── service_name-6 -> /etc/cas/saml/new-keys ├── idp-encryption.crt ├── idp-encryption.key ├── idp-metadata.xml ├── idp-signing.crt ├── idp-signing.key ├── new-keys │ ├── idp-encryption.crt │ ├── idp-encryption.key │ ├── idp-metadata.xml │ ├── idp-signing.crt │ └── idp-signing.key ... ``` Basically we want to keep the old SAML keys on some services and one-by-one migrate each service to a new set of keys. In the meantime multiple idP keys/metadata are used. The issue is that, although the response is indeed signed with the correct key, *but* the SAML response contains the wrong certificate under the `ds:Signature -> ds:KeyInfo` subfield. A SAML response example [redacted]: https://gist.github.com/linosgian/9bf29bcd97808589a9d28a03f99c1cb9 The old certificate is concatenated in the `KeyInfo` field. In order to reproduce it, generate two SAML idP metadata, override the metadata and keys for a single service, then attempt to log in to that service, the response it totally valid, but the KeyInfo contains the "old" key aka the root one. I believe the issue begins at [0], where the `SamlIDPObjectSigner` attempts to find the key to concatenate in the SAML response. This does not pose an immediate issue since as per the official SAML2 RFCs[1]: > XML Signature defines usage of the <ds:KeyInfo> element. SAML does not > require the use of<ds:KeyInfo>, nor does it impose any restrictions on its > use. Therefore, <ds:KeyInfo> MAY be absent. But while attempting it integrate Jenkins with CAS (through the saml2 plugin), I ran into some warning that look like this, when the override is used. Note that, the signature is accepted (so the correct key is being used to verify the signature itself) but the warning shown below still bubbled up to my logs anyway. When no overrides are used, there is no warning. WARNING o.a.x.s.signature.XMLSignature#checkSignatureValue: Signature verification failed. Again, this shouldn't be an issue, but some SAML SP implementation out there might not work as expected due to this issue. [0]: https://github.com/linosgian/cas/blob/556b1f08e5b060afad5a448653dd96a143e0180f/support/cas-server-support-saml-idp-web/src/main/java/org/apereo/cas/support/saml/web/idp/profile/builders/enc/SamlIdPObjectSigner.java#L265 [1]: https://www.oasis-open.org/committees/download.php/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf -- Ray Bon Programmer Analyst Development Services, University Systems 2507218831 | CLE 019 | [email protected]<mailto:[email protected]> I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations. -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/15387cae0fc961e68b12ff227052ece911c9ef60.camel%40uvic.ca.
