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 On Wed, Jan 29, 2020 at 2:22 PM Mike Osterman <[email protected]> wrote: > Thanks, Misagh! Responses below: > > On Wed, Jan 29, 2020 at 2:23 AM Misagh Moayyed <[email protected]> > 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 > -- - 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/CAEdMQHU%3D0e8KtNrA9b14teQqQ-ny3A9LzNm%3Dmf50UK%2B0aLjYjA%40mail.gmail.com.
