Hey Ray,
On 11/25/20 7:57 PM, Ray Bon wrote:
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?
Initially, based on the per-SP metadata overrides guide [0], I was given
the impression that I could indeed also override the metadata too.
The thing is, that the response itself and/or the assertions are signed
with the correct (overriding) key. The only codepath that's messed up is
the one that generates the SAML response. A sample of the logs that were
generated, right before the response is signed:
```
Nov 27 12:19:57 cas-stg tomcat9[9271]: 2020-11-27 12:19:57,831 TRACE
[org.apereo.cas.support.saml.idp.metadata.locator.FileSystemSamlIdPMetadataLocator]
- <Metadata directory location for [jenk] is [/etc/cas/saml/jenk-9]>
Nov 27 12:19:57 cas-stg tomcat9[9271]: 2020-11-27 12:19:57,843 TRACE
[org.apereo.cas.support.saml.idp.metadata.locator.FileSystemSamlIdPMetadataLocator]
- <Artifact location for [idp-signing.key] and [jenk] is
[/etc/cas/saml/jenk-9/idp-signing.key]>
Nov 27 12:19:57 cas-stg tomcat9[9271]: 2020-11-27 12:19:57,843 DEBUG
[org.apereo.cas.support.saml.idp.metadata.locator.FileSystemSamlIdPMetadataLocator]
- <Using metadata artifact [idp-signing.key] at
[/etc/cas/saml/jenk-9/idp-signing.key]>
```
Where `jenk-9` is the directory containing all the overrides.
Despite that, I attempted to put both SAML keys (old and new one) in the
same metadata file as you suggested, and thus not override them in the
SP folder.
The results were the same, the response contained the wrong `KeyInfo`.
[0] https://apereo.github.io/2019/12/16/cas62x-saml2-metadata-service/
Regards,
Linos
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 <https://apereo.github.io/cas>
- Gitter Chatroom: https://gitter.im/apereo/cas
<https://gitter.im/apereo/cas>
- List Guidelines: https://goo.gl/1VRrw7 <https://goo.gl/1VRrw7>
- Contributions: https://goo.gl/mh7qDG <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]
<mailto:[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
<https://groups.google.com/a/apereo.org/d/msgid/cas-user/15387cae0fc961e68b12ff227052ece911c9ef60.camel%40uvic.ca?utm_medium=email&utm_source=footer>.
--
- 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/dac9b2f9-9324-a621-b32d-c877c0237d76%40skroutz.gr.
