Trying to determine why CAS is returning an encoded attribute to SAML SP

[Mike Osterman]

Hello,

I've been trying to determine for several hours now why a SAML-based SP is being sent different values of the Id as part of the authentication flow. Here's a sample of the "WHO" line from a single login in transaction:

WHO: user...@whitman.edu
WHO: user...@whitman.edu
WHO: YfXXXXXXXXXXXXXXXo=
WHO: YfXXXXXXXXXXXXXXXo=

Note that first, the username is provided, but later a (presumably) signed/encoded value is being returned. (Yep, those Xs are intentional--redaction)

I turned on debug for "org.apereo.cas.support.saml" and found that it seems to be happening in building the NameID response:

org.apereo.cas.support.saml.web.idp.profile.builders.nameid.SamlProfileSamlNameIdBuilder] - <NameID attribute value is set to [StringAttributeValue{value=YfXXXXXXXXXXXXXXXo=}]>

None of this would be a big deal if we hadn't run into a bizarre problem that the encoded attribute being sent *CHANGED*. 

I have one crackpot theory for what might have changed: On January 10, we enabled Google Apps support by compiling in the dependency and generating keys, which are referenced as such in our cas.properties file:

cas.googleApps.publicKeyLocation=file:public.key
cas.googleApps.keyAlgorithm=RSA
cas.googleApps.privateKeyLocation=file:private.key

So my two questions:

1) Is there any chance that the google apps keys have somehow superseded the ones that general SAML services were using previously, such that my non-Google SAML service switched to using the Google keys instead? This is the only reason why I can fathom that the NameID attribute value suddenly changed.

2) Does anyone have ideas of how to disable the signing/encoding of the NameID attribute so I can get visibility into what's getting sent? Or is that happening at the direction of the SAML SP?

Thank you!

Mike

[Misagh Moayyed]

None of this would be a big deal if we hadn't run into a bizarre problem that the encoded attribute being sent *CHANGED*. 

It would be helpful to describe the steps you took to create/duplicate this scenario.

 

So my two questions:

1) Is there any chance that the google apps keys have somehow superseded the ones that general SAML services were using previously, such that my non-Google SAML service switched to using the Google keys instead? This is the only reason why I can fathom that the NameID attribute value suddenly changed.

No. 

However, please note that the Google Apps for Education integration allows CAS to act as a miniaturized SAML2 identity provider, for deployments that may not be prepared to turn on and allow CAS to fully act as a SAML2 identity provider. This feature is deprecated and is scheduled to be removed in the future. It does not make much sense to turn on and use both features (Google Apps + SAML2 IDP) in CAS at the same time, as one outranks the other and it is likely that using both features in CAS simultaneously would interfere with the functionality of both. If you can, consider using the SAML2 identity provider functionality in CAS to handle this integration as you would any other SAML2 service provider.

Big blue box here: https://apereo.github.io/cas/6.1.x/integration/Google-Apps-Integration.html

I am not saying using both at the same time is causing this issue; just that if your deployment qualifies for that sort of condition, you're inviting additional complexity with no real benefits to your deployment.

 

2) Does anyone have ideas of how to disable the signing/encoding of the NameID attribute so I can get visibility into what's getting sent? Or is that happening at the direction of the SAML SP?

Unless your SAML2 SP is asking/forcing CAS to use encrypted NameIDs or Transient NameIDs, I don't think this is happening. IIRC, this indication will be instructed to CAS via the SP metadata. If you want to see what's happening, turn up TRACE logging for org.apereo.cas and comb through the logs.

[Mike Osterman]

Thanks, Misagh! Responses below:

On Wed, Jan 29, 2020 at 2:23 AM Misagh Moayyed <misagh....@gmail.com> wrote:

None of this would be a big deal if we hadn't run into a bizarre problem that the encoded attribute being sent *CHANGED*. 

It would be helpful to describe the steps you took to create/duplicate this scenario.

That's the rub. The only thing I can come up with that did change was my rebuilding my cas.war after adding the dependency for GoogleApps. That's when the value being sent changed. It's possible other bits got changed when I rebuilt my war file, but I didn't change the cas version in the gradle file - only added the Google Apps dependency:

compile "org.apereo.cas:cas-server-support-saml-googleapps:${project.'cas.version'}"

 

So my two questions:

1) Is there any chance that the google apps keys have somehow superseded the ones that general SAML services were using previously, such that my non-Google SAML service switched to using the Google keys instead? This is the only reason why I can fathom that the NameID attribute value suddenly changed.

No. 

However, please note that the Google Apps for Education integration allows CAS to act as a miniaturized SAML2 identity provider, for deployments that may not be prepared to turn on and allow CAS to fully act as a SAML2 identity provider. This feature is deprecated and is scheduled to be removed in the future. It does not make much sense to turn on and use both features (Google Apps + SAML2 IDP) in CAS at the same time, as one outranks the other and it is likely that using both features in CAS simultaneously would interfere with the functionality of both. If you can, consider using the SAML2 identity provider functionality in CAS to handle this integration as you would any other SAML2 service provider.

Big blue box here: https://apereo.github.io/cas/6.1.x/integration/Google-Apps-Integration.html

I am not saying using both at the same time is causing this issue; just that if your deployment qualifies for that sort of condition, you're inviting additional complexity with no real benefits to your deployment.

Ah - that makes good sense. The reason I missed that big blue box is that we're on 5.3.x, and it's not on that page: https://apereo.github.io/cas/5.3.x/integration/Google-Apps-Integration.html Perhaps it could be added there as well?

 

2) Does anyone have ideas of how to disable the signing/encoding of the NameID attribute so I can get visibility into what's getting sent? Or is that happening at the direction of the SAML SP?

Unless your SAML2 SP is asking/forcing CAS to use encrypted NameIDs or Transient NameIDs, I don't think this is happening. IIRC, this indication will be instructed to CAS via the SP metadata. If you want to see what's happening, turn up TRACE logging for org.apereo.cas and comb through the logs.

I couldn't find anything in the metadata (in the metadata backup file) that indicated a requested preference for a NameID format. Adding the tracing at that level sounds like a firehose for a production system. That said, I appreciate the pointer to where to look for more clues. I'll see if I can get the vendor to help me test this on a non-production instance with our test CAS server.

Thank you,

Mike

[Mike Osterman]

Update: well, here's yet another lesson that correlation does not equal causation. :)

Here was the root cause:

[36m2020-02-04 23:15:43,941 DEBUG [org.apereo.cas.support.saml.web.idp.profile.builders.nameid.SamlProfileSamlNameIdBuilder] - <No supported nameId formats could be determined from metadata. Added default [urn:oasis:names:tc:SAML:2.0:nameid-format:transient]>

The reason I was thinking it was the adding of the Google Apps support is because that's when I restarted the CAS service. Through some testing, I found that a consistent transient NameID was being sent until I restarted CAS, then a new transient ID was being generated.

Question: is transient the default NameID format for CAS SAML2 support, or did I somehow override that? I get that the root cause is the SP not specifying the Name ID format, but I'm surprised by the "Added default [urn:oasis:names:tc:SAML:2.0:nameid-format:transient]" part of the debug log message, as transient seems like a squirrely format to work with.

A further comment about the documentation for older supported versions, similar to my earlier note that the "big blue box" about deprecation isn't on the 5.3.x version of the Google Apps Integration page. I was able to find some extremely useful examples for forcing persistent NameID format here: https://apereo.github.io/cas/6.1.x/installation/Configuring-SAML2-Authentication.html#name-id-selection The 5.3.x version of the same documentation, however, does not have those examples: https://apereo.github.io/cas/5.3.x/installation/Configuring-SAML2-Authentication.html#name-id-selection It would be extremely helpful for documentation improvements like these to be "backported" (pardon the [mis?]use of that term) to the documentation of the older, yet still supported, versions. I only came across the 6.1.x version after stumbling across the master branch of the document here: https://github.com/apereo/cas/blob/master/docs/cas-server-documentation/installation/Configuring-SAML2-Authentication.md. 

Thanks again for the troubleshooting pointers!

-Mike

[Misagh Moayyed]

Question: is transient the default NameID format for CAS SAML2 support, or did I somehow override that?

A quick look suggests that it is the default. If an authentication request does not ask any, and the metadata does not declare support for any, and if you are not overriding the format in a service definition, then transient is chosen. [1]

 

A further comment about the documentation for older supported versions, similar to my earlier note that the "big blue box" about deprecation isn't on the 5.3.x version of the Google Apps Integration page.

Thanks for the note. I ported the warning back to 5.3.x. 

 

It would be extremely helpful for documentation improvements like these to be "backported" (pardon the [mis?]use of that term) to the documentation of the older, yet still supported, versions.

Sure. The examples are typically posted for the CAS version they were tested against (and there are or should be unit/integration tests to enforce the correctness of the example going forward). If you have one that continues to be backward compatible, you are most welcome to suggest the change in form a pull request, once you're confident that it works for an older version.

[1] Work is being done to add support for a dozen other conditions to make this truly uber-flexible :)