Google SSO

[Jeremiah Garmatter]

Hello,

I've recently upgraded my CAS server from 5.3.14 to 6.2.1 and had a question about Google Apps integration.

On the older system, there was a gradle dependency for google apps SAML:

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

I get a deprecation warning when using this:

CAS integration with Google Apps is now deprecated and scheduled to be removed in the future. The functionality is now redundant and unnecessary with CAS able to provide SAML2 identity provider features.To handle the integration, you should configure CAS to act as a SAML2 identity provider and remove this integration from your deployment to protected against future removals and surprises.>

I've changed to use the SAML 2 dependency:

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

but I'm not sure what to do about Google's properties. There were properties defined for public and private keys within cas.properties:

cas.google-apps.private-key-location=

cas.google-apps.public-key-location=

cas.google-apps.key-algorithm=RSA

Are there equivalent properties for SAML2?

[Richard Frovarp]

No, there isn't You configure it as a SAML 2 provider. This means you have to craft the metadata by hand. Also, it is beyond deprecated as it will kill your other SAML integrations. So it's best to just do a pure SAML setup with it. Here's the draft set of instructions I put together. I need to get these publish on the public Internet somewhere, as I suspect they would be useful to others:

G Suite now offers test domains for testing things. This can be used to validate SSO settings and changes.

So first you may want to change to "Use a domain specific issuer" to differentiate between your normal instance and the test one. That will result in a issuer looking like this:

google.com/a/gsuitetest.ndsu.edu

instead of

google.com

The Sign-in page URL is this off of your IdP

cas/idp/profile/SAML2/Redirect/SSO

The certificate provided needs to be your SAML 2 signing certificate.

From here you will need to generate metadata to give CAS. You can use this service to generate the metadata:

https://www.samltool.com/sp_metadata.php

Values:

Entity ID: The issuer, which in my case is google.com/a/gsuitetest.ndsu.edu

ACS Endpoint: This can be got by doing a test auth from G Suite and using SAML Tracer, but looks like this for my test domain: https://www.google.com/a/gsuitetest.ndsu.edu/acs

Nameid Format: Leave at 1.1 unspecified

You don't need a cert. You need to upload your SAML certificate to Google so that it can verify the response.

You will need to edit the generated metadata to remove the "validUntil" attribute, as it is set to expire very quickly.

[Jeremiah Garmatter]

Richard,

Thank you for the advice on this. We have started the creation process of our gsuitetest subdomain. While waiting for Google to verify ownership, I'd like to probe your brain some more.

In the past (CAS 5.2), using that Googleapps SAML dependency allowed you to configure the Google service with the org.apereo.cas.services.RegexRegisteredService class, if memory serves. Are you saying that I'll have to change the service entry to use the org.apereo.cas.support.saml.services.SamlRegisteredService class and configure it as a SAML2 service now? That's not an issue if I do, but I'm confused by that difference.

Also, in the past vesion of CAS, I believe we sent uid attributes to Google , if I release that through SAML2, will I need to specify the namespace used (something like urn:oid:0.9.2342.19200300.100.1.1 )?

[Richard Frovarp]

Yeah, you'll need to treat it like any other SAML2 service, including using the SamlRegisteredService configuration. Not entirely sure about attribute release. In our case, releasing the default username is all we need to make it work. But it should be like any other SAML2 service.

The difference is they used to have a helper that simplified the SAML2 bits for this service. That has been deprecated, and it actively interferes with other SAML2 services. Hence the change.

[Jeremiah Garmatter]

Ah, I see now. I should have mentioned that, in our case, the username is being sent to google as well, just through that attribute. When you set up google's single sign on, did google's side inform you of the namespace they are expecting usernames to come in as?

-Jeremiah Garmatter, Systems Administrator

-Ohio Northern University, Class of 2020

-Work: 419-772-1074 Cell: 419-672-8685

-j-gar...@onu.edu

--
- 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 a topic in the Google Groups "CAS Community" group.
To unsubscribe from this topic, visit https://groups.google.com/a/apereo.org/d/topic/cas-user/hglzuGZMIWg/unsubscribe.
To unsubscribe from this group and all its topics, 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/03c5e613172ba07fdcb4c8acf1adc1393103e2f4.camel%40ndsu.edu.

[Richard Frovarp]

I think that's controlled by the metadata, and my notes below say 1.1 unspecified.

[Jeremiah Garmatter]

Sweet, thanks for all this Richard, you've saved me a lot of headache.

-Jeremiah Garmatter, Systems Administrator

-Ohio Northern University, Class of 2020

-Work: 419-772-1074 Cell: 419-672-8685

-j-gar...@onu.edu

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/9653d7e5f1b3d3116e7967fced60c7ffcff3c455.camel%40ndsu.edu.

[Jeremiah Garmatter]

Richard,

I've got one more question for you.

First, I'd like to say that all of the sign-in procedure worked perfectly, so thank you for that.

The only problem I have now is with the logout URL on Google. Before we could set up the SSO, we had to enter a logout URL for Google to use. At first, I tried the /idp/profile/SAML2/Redirect/SLO endpoint, but after the redirect, I get a 500 internal error stating " Error: No SAMLRequest or SAMLResponse query path parameter, invalid SAML 2 HTTP Redirect message " as I am redirected to https://XXXXX/cas/idp/profile/SAML2/Redirect/SLO. I then realized that, despite being a SAML2 provider, when attempting to access my gsuitetest gmail account, I was redirected to https://XXXXX/cas/login?service=<big service string>. This lead me to believe that I could use the /cas/logout endpoint as the logout URL (https://XXXXXX/cas/logout). I was greeted with the "logout successful" page, but when I open a new tab to access my gsuitetest email, I was not prompted to enter my credentials, I could access my emails as if the cookie was still in use.

I was wondering if you knew how to properly sign a google user out of their email with the logout URL field on Google?

[Richard Frovarp]

I haven't chased down logout operation. You're going to need to look, but I'm guessing that they are getting logged out on the Google side, but an SSO session is still active in the IdP? Or is it after logout it isn't doing a logout on Google side?

[Jeremiah Garmatter]

You were right on the first guess,

Google was logging the user out, however, since CAS never properly saw the logout, it could not destroy / invalidate the ticket. It turns out something was entered incorrectly on Google's side. Once I changed the logout URL to the /cas/logout endpoint, without typos, I was able to successfully logout from both CAS and Google mail.

-Jeremiah Garmatter, Systems Administrator

-Ohio Northern University, Class of 2020

-Work: 419-772-1074 Cell: 419-672-8685

-j-gar...@onu.edu

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/bcbf5adbbb928bf9ace23c874e7cbd1be25de67e.camel%40ndsu.edu.

[Jeremiah Garmatter]

Richard,

I'd like to verify something with you about production deployment.

When I am ready to deploy my CAS instance to my organization, I will need to change the google metadata and service entry. So I should change the service entry from:

"serviceId" : "google.com/a/gsuitetest.onu.edu"     to     "serviceId" : "google.com/a/onu.edu" ?

and the metadata from:

entityID="google.com/a/gsuitetest.onu.edu"     and     Location="https://www.google.com/a/gsuitetest.onu.edu/acs"

to

entityID="google.com/a/onu.edu"    and    Location="https://www.google.com/a/onu.edu/acs"

Does that all seem correct? I'd really like to verify as this is one of the most used services on campus.

[Richard Frovarp]

Yes. The one caveat is that you would need to enable the "Use a domain specific" issuer on prod otherwise it will spit it out with generic values, which doesn't have onu.edu in it. I don't remember what the generic values are. When we upgraded CAS, I logged in to click that button to swap prod over.

[Jeremiah Garmatter]

Great!

Thank you again Richard, have a wonderful day.