Invalid `KeyInfo` when per-SP idP configuration is used

31 views
Skip to first unread message

Linos Giannopoulos

unread,
Nov 25, 2020, 9:37:18 AM11/25/20
to CAS Community
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]:


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.

Ray Bon

unread,
Nov 25, 2020, 12:57:19 PM11/25/20
to cas-...@apereo.org
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. 
--
Ray Bon
Programmer Analyst
Development Services, University Systems

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.

Linos Giannopoulos

unread,
Nov 27, 2020, 5:29:29 AM11/27/20
to cas-...@apereo.org

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

--
- 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 cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/15387cae0fc961e68b12ff227052ece911c9ef60.camel%40uvic.ca.

Ray Bon

unread,
Nov 27, 2020, 11:45:03 AM11/27/20
to cas-...@apereo.org
Linos,

That post outlines a very neat feature.
It looks like you had it set up correctly according to the blog. I thought you were changing your certs globally, but you are doing something different.

Out of curiosity, why do you want to have different IdP metadata for each service?
What happens if your IdP (and some of the services) want to be part of a federation?

Ray
Reply all
Reply to author
Forward
0 new messages