SSO with multiple Google domains

[Knape, Dean M.]

This is the explanation I was given.  It seems I'm able to control
RelayState as described.

"if you create custom service URLs for primary and secondary domains, as
explained at https://support.google.com/a/answer/53340, and users access
the services via those URLs, you can use the Relay State parameter to
determine which domain the user is attempting to access. For example, you
currently have http://webmail.primary.edu, and if you create
http://webmail.secondary.com, when a user from the secondary.com domain
attempts to access http://webmail.secondary.com, they'll be redirected to
https://mail.google.com/a/secondary.com, for which it is an alias, which in
turn will redirect to your Shibboleth IdP, bypassing
https://accounts.google.com. The request to authenticate the user will
contain a SAML Request, and a Relay State, indicating what service the user
attempted to access, so for users on the secondary domain, you should see
https://mail.google.com/a/secondary.com."

dean

On Thu, Nov 2, 2017 at 11:34 AM, Boyd, Todd M. <tmboyd1 at ccis.edu> wrote:

> My only experience thus far with RelayState has been in an "unsolicited"
> SSO scenario, where our IdP was the system providing that RelayState to the
> SP. It was up to the SP to parse it and push it through their
> authentication/authorization logic.
>
> -Todd
>
>
> From: users <users-bounces at shibboleth.net> on behalf of Cantor, Scott <
> cantor.2 at osu.edu>
> Sent: Thursday, November 2, 2017 10:29:22 AM
> To: Shib Users
> Subject: RE: SSO with multiple Google domains
>
> > Google is suggesting using the relay state of the authentication request
> to
> > derive domain information which can then be used to build the appropriate
> > email address for the SAML response.  Is this something that can be done
> in
> > the IdP?
>
> You can control the RelayState if using unsolicited responses starting at
> the IdP, otherwise it's whatever came from the SP.
>
> > Are there other options/recommendations?
>
> I don't know enough about how broken their system is to really comment on
> what else might be possible. I think somebody needs to tell Google to fix
> their code.
>
> -- Scott
>
> --
> For Consortium Member technical support, see  https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 

Dean Knape
University Information Systems
NJ Institute of Technology
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171102/48847776/attachment-0001.html>