Date: Fri, 29 Mar 2024 13:48:07 +0000 (UTC) Message-ID: <800382089.8041.1711720087740@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8040_1560231411.1711720087738" ------=_Part_8040_1560231411.1711720087738 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
For the Service Providers listed on the Google Gateway home page, Google has become the I= dentity Provider of Last Resort (IdPoLR). Since many users already hav= e a Google account, using Google as the IdPoLR precludes the need for users= to create yet another password to access federated services. This is a big= win for both users and Service Provider operators.
That's not entirely true. Site Administrators may not u= se federated identities (Google or otherwise) to log into the Federation Manager. On the oth= er hand, Delegated Administrators must use federated ident= ities to log into the Federation Manager. A Delegated Administrator may use= Google for this purpose if the Site Administrator approves.
That is completely up to you. You could even create a new Google account= for exclusive use with the Gateway (although there's no particularly good = reason for doing so).
Yes, you can. At the Google sign in page, type your campus email add= ress into the email field but leave the password field blank. Google w= ill automatically redirect your browser to your campus login page.
Btw, exactly the same technique works for Google Apps for Business or an= y other Google Apps account. If you enter the email address of one of your = personal Google Apps accounts, you'll have to type your password as well (s= ince there's nowhere else to go!).
No, sorry, we only support Google at this time.
No, the Gateway maintains NO state information about the browser users w= ho use it. It does maintain log files for troubleshooting issues and compil= ing usage statistics, but that=E2=80=99s all.
No, the Gateway may be used by Internet2 Service Providers only. You may= implement your own gateway for Google authentication or contract with a co= mmercial provider for such services. InCommon's is powered by Cirrus Identi= ty.
On the near side of the Gateway, facing the SP, the protocol used is ord= inary SAML V2.0 Web Browser SSO. In that sense, the Google Gateway is = just like any other IdP in the InCommon Federation.
On the far side of the Gateway, facing Google, the protocol is OpenID Conn= ect (not to be confused with OpenID 2.0). So technically the Googl= e Gateway translates OpenID Connect (OIDC) assertions to SAML assertions, t= hat is, it is an instance of an OIDC-to-SAML gateway.
No. Since the Gateway is intended to be used by Internet2 Service Provid= ers only, including it in InCommon metadata would only confuse users on dis= covery interfaces.
The discovery interface will include "Google Sign In" will automatically= appear on the discovery interface.
Yes, the Gateway asserts an eduPersonPrincipalName
(e=
PPN
) for each user.
The ePPN
asserted by the Gateway for a particular user is t=
he same for all downstream SPs. (We say that the ePPN
is "scop=
ed to the Federation.") See the Google Gateway home page to understand how the ePPN
=
is computed by the Gateway.
Yes, see the Google Ga= teway home page for a complete list of attributes asserted by the Gatew= ay.