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/CAEdMQHVsTKRg3RUjUvXH-N-YOXW60WThPCjPPeM0nnrHY1YC7w%40mail.gmail.com.
