<div dir="ltr">This is the explanation I was given. It seems I'm able to control RelayState as described. <div><br></div><div><span style="color:rgb(0,0,0);font-size:13.5px">"if you create custom service URLs for primary and secondary domains, as explained at </span><a href="https://support.google.com/a/answer/53340" rel="noreferrer" target="_blank" style="font-size:13.5px">https://support.google.com/a/<wbr>answer/53340</a><span style="color:rgb(0,0,0);font-size:13.5px">, 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 </span><a href="http://webmail.primary.edu">http://webmail.primary.edu</a><span style="color:rgb(0,0,0);font-size:13.5px">, and if you create </span><a href="http://webmail.secondary.com">http://webmail.secondary.com</a><span style="color:rgb(0,0,0);font-size:13.5px">, when a user from the </span><a href="http://secondary.com">secondary.com</a><span style="color:rgb(0,0,0);font-size:13.5px"> domain attempts to access </span><a href="http://webmail.secondary.com">http://webmail.secondary.com</a><span style="color:rgb(0,0,0);font-size:13.5px">, they'll be redirected to </span><a href="https://mail.google.com/a/">https://mail.google.com/a/</a><wbr><a href="http://secondary.com">secondary.com</a><span style="color:rgb(0,0,0);font-size:13.5px">, for which it is an alias, which in turn will redirect to your Shibboleth IdP, bypassing </span><a href="https://accounts.google.com/" rel="noreferrer" target="_blank" style="font-size:13.5px">https://accounts.google.com</a><span style="color:rgb(0,0,0);font-size:13.5px">. 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 </span><a href="https://mail.google.com/a/secondary.com">https://mail.google.com/a/secondary.com</a><span style="color:rgb(0,0,0);font-size:13.5px">."</span></div><div><span style="color:rgb(0,0,0);font-size:13.5px"><br></span></div><div><span style="color:rgb(0,0,0);font-size:13.5px">dean</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 2, 2017 at 11:34 AM, Boyd, Todd M. <span dir="ltr"><<a href="mailto:tmboyd1@ccis.edu" target="_blank">tmboyd1@ccis.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
-Todd<br>
<br>
<br>
From: users <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a>> on behalf of Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>><br>
Sent: Thursday, November 2, 2017 10:29:22 AM<br>
To: Shib Users<br>
Subject: RE: SSO with multiple Google domains<br>
<br>
> Google is suggesting using the relay state of the authentication request to<br>
> derive domain information which can then be used to build the appropriate<br>
> email address for the SAML response. Is this something that can be done in<br>
> the IdP?<br>
<br>
You can control the RelayState if using unsolicited responses starting at the IdP, otherwise it's whatever came from the SP.<br>
<br>
> Are there other options/recommendations?<br>
<br>
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.<br>
<br>
-- Scott<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/<wbr>confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
<br>
--<br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/<wbr>confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="text-align:left"><pre cols="72"><font size="2">Dean Knape<br>University Information Systems<br>NJ Institute of Technology<br></font></pre></div></div></div>
</div>