Google

Google was an early integration, so it is different from any other Yale Shibboleth Relying Party and not configured normally for most SAML SPs. Google did not give us a Metadata file, although one has been created by Yale to avoid it being flagged as an Anonymous RP. Google has a single EntityID and three AssertionConsumerService URLs for the three instances (PROD, TEST, and DEV). You can do an IdP Initiated login to Google (include the shire= if you are not going to production), but normally you go to mail.bulldogs.yale.edu, or mail.bulldogs.gtst.yale.edu, or mail.bulldogs.gdev.yale.edu and Google redirects the Browser to Shibboleth with a Request.

Each Google instance is configured to point to the corresponding DEV, TEST, or PROD Shibboleth. Therefore, Google is unusual in that you can only login to DEV Eliapps from DEV Shibboleth.

Google expects us to send a Subject containing the Google account ID (the part of the mailbox name in front of "@bulldogs.yale.edu"). This is also the part of the registered Email alias before the "@yale.edu" for the Email alias that points to a "bulldogs" mailbox.

The Yale databases are in flux. During transition, the Google ID sometimes comes from a database that tracks Mailbox creation, but when that is unavailable it can alternately be derived from the database entries that track Mail aliases. The difference is that mailboxes are created separately in DEV, TEST, and PROD while aliases are in PROD and are copied to DEV and TEST several times a year.

As a result, it was possible to create a different Google ID for your mailbox in gtst and gdev, but today this is not a reliably supported option. Shibboleth reserves the right to just assume that if you have a mailbox at all in gtst and gdev, then your GoogleID in the test domains is the same as your GoogleID in regular "bulldogs". That allows it to take the Email Alias data (that only exists for PROD) and use it as the GoogleID in DEV and TEST.

Yale has created an application named DEAL that allows a user who also owns departmental Email accounts to login as one of these accounts to perform administrative functions. This is the easiest way to add new users who have shared access to the mail. When the user has just selected one of these departmental accounts through DEAL, Shibboleth sends the GoogleID of the shared mailbox instead of the GoogleID of the user's personal mail at that user's next login.

In the event that all databases are down, it is possible to continue to login Eliapps users by taking the "mail" attribute of AD, extracting the part in front of the "@" and send it to Google. For students and faculty who have Eliapps accounts, this will match an already configured account and they will login. So during disaster recovery, if AD is up but the other databases have not been restarted, someone with both Exchange and Eliapps accounts will not be able to login to the Eliapps account, because this fallback will present the Exchange prefix to Google instead of the Google ID. Everyone will be able to login to their primary mailbox, and that should be good enough during a major failure.

SAML Subjects are supposed to exist and be unique for all users. However, many users do not have a Google account. So other users may get a dummy Subject value generated ("unconfigured-user"). They cannot login with this Subject, but having some non-null value for an attribute configured to generate Subjects keeps Shibboleth happy.

Normally Yale makes the Netid available as a Subject-generating attributes, but to be sure Google gets the right value, that attribute is specifically not released to Google.