Google Apps

1) License

1. The institution informs SURFmarket that they want to participate and supplies the following info with an email to software@surfmarket.nl :
   • The full official name of your university;
   • The official address of your university;
   • The domain names that you will be using:
Please note that if you will be using university.nl and alumni.university.nl, we only need to list the main domain ie. university.nl;
   • The number of years the contract will be valid for: 1 year, 2 years, 3 years, 4 years, or 5 years. 
Please note that you can leave the Google Apps for Education service at any time. You can move your data freely using the tools available on dataliberation.org

2. 
SURFmarket contacts Google with the provided information. An acceptance contract will be send to the institution by the SURFmarket licensedesk.
3. After returning the signed contract Google will have to process the application. The last step is for the institution to use the online Google Apps control panel and activate the option "toepasselijkheid amendement/ EU model contract".

2) Attributes

See also SURFconext Dashboard for SAML attribute requirements.

Google needs one attribute that identifies a user, this typically is 'uid'.

• urn:mace:dir:attribute-def:uid

3) SIngle or Multi-tenancy

Google Apps is a single tenant service.

4) Configuration

In this tutorial, we will use the fictional Google Apps domain of "myuniversity.com". This should be changed to your institutions Google Apps domain name which you configured when creating your Google Apps instance.

1. Login to the Google Apps administrative interface located at https://www.google.com/a/cpanel/myuniversity.com
2. Go to Advanced Tools -> Set up single sign-on (SSO)
3. Configure the fields as follows (see the screenshot below):

   1. Check the "Enable Single Sign-On" checkbox

   2. Sign-in page URL:

      https://engine.surfconext.nl/authentication/idp/single-sign-on
      

      When you connect your Google Apps domain to a Virtual Organisation (VO) in SURFconext, this URL needs to contain the VO identifier:

      https://engine.surfconext.nl/authentication/idp/single-sign-on/vo:voidentifier
      

   3. Sign-out page URL:

      https://engine.surfconext.nl/logout
      

      This will destroy the login session of the user at the SURFfederation. However, it is likely that the user has more active sessions that would allow him to re-enter Google Apps without providing his username and password. Therefore, the strong security advise is given to close the browser. This would destroy all the user's session cookies and effectively logging the user out.

   4. Change Password URL
      This field should point to your institution's change password page. See also the section here below

   5. Verification Certificate
      This contains the file containing the SURFconext signing certificate. Either use this file or put the following in a textfile and configure that:

      -----BEGIN CERTIFICATE-----
      MIID3zCCAsegAwIBAgIJAMVC9xn1ZfsuMA0GCSqGSIb3DQEBCwUAMIGFMQswCQYD
      VQQGEwJOTDEQMA4GA1UECAwHVXRyZWNodDEQMA4GA1UEBwwHVXRyZWNodDEVMBMG
      A1UECgwMU1VSRm5ldCBCLlYuMRMwEQYDVQQLDApTVVJGY29uZXh0MSYwJAYDVQQD
      DB1lbmdpbmUuc3VyZmNvbmV4dC5ubCAyMDE0MDUwNTAeFw0xNDA1MDUxNDIyMzVa
      Fw0xOTA1MDUxNDIyMzVaMIGFMQswCQYDVQQGEwJOTDEQMA4GA1UECAwHVXRyZWNo
      dDEQMA4GA1UEBwwHVXRyZWNodDEVMBMGA1UECgwMU1VSRm5ldCBCLlYuMRMwEQYD
      VQQLDApTVVJGY29uZXh0MSYwJAYDVQQDDB1lbmdpbmUuc3VyZmNvbmV4dC5ubCAy
      MDE0MDUwNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKthMDbB0jKH
      efPzmRu9t2h7iLP4wAXr42bHpjzTEk6gttHFb4l/hFiz1YBI88TjiH6hVjnozo/Y
      HA2c51us+Y7g0XoS7653lbUN/EHzvDMuyis4Xi2Ijf1A/OUQfH1iFUWttIgtWK9+
      fatXoGUS6tirQvrzVh6ZstEp1xbpo1SF6UoVl+fh7tM81qz+Crr/Kroan0UjpZOF
      TwxPoK6fdLgMAieKSCRmBGpbJHbQ2xxbdykBBrBbdfzIX4CDepfjE9h/40ldw5jR
      n3e392jrS6htk23N9BWWrpBT5QCk0kH3h/6F1Dm6TkyG9CDtt73/anuRkvXbeygI
      4wml9bL3rE8CAwEAAaNQME4wHQYDVR0OBBYEFD+Ac7akFxaMhBQAjVfvgGfY8hNK
      MB8GA1UdIwQYMBaAFD+Ac7akFxaMhBQAjVfvgGfY8hNKMAwGA1UdEwQFMAMBAf8w
      DQYJKoZIhvcNAQELBQADggEBAC8L9D67CxIhGo5aGVu63WqRHBNOdo/FAGI7LURD
      FeRmG5nRw/VXzJLGJksh4FSkx7aPrxNWF1uFiDZ80EuYQuIv7bDLblK31ZEbdg1R
      9LgiZCdYSr464I7yXQY9o6FiNtSKZkQO8EsscJPPy/Zp4uHAnADWACkOUHiCbcKi
      UUFu66dX0Wr/v53Gekz487GgVRs8HEeT9MU1reBKRgdENR8PNg4rbQfLc3YQKLWK
      7yWnn/RenjDpuCiePj8N8/80tGgrNgK/6fzM3zI18sSywnXLswxqDb/J+jgVxnQ6
      MrsTf1urM8MnfcxG/82oHIwfMh/sXPCZpo+DTLkhQxctJ3M=
      -----END CERTIFICATE-----

   6. Use a domain specific issuer
      Make sure to check this box. This enables SURFconext to distinguish between all connected Google Apps domains.
      
4. Register your Google Apps domain with SURFconext by sending a mail to conext-beheer@surfnet.nl. Include the following information:
   
   1. Your Google Apps domain metadata file. Because Google does not provide such a file, there is a webform (https://support.surfconext.nl/googleapps) you can complete that will generate such a metadata file for you.
   2. The attribute that is used to provision your users to Google Apps. You can review the available attributes here. Typically, the "urn:mace:dir:attribute-def:mail" attribute is used. Also specify if additional processing is necessary, for example because this attribute is multi-valued and does not always contain the correct email domain.
   3. The IDP(s) that need access to your Google Apps domain.

5) Provisioning

When using the SSO feature of Google Apps, the users must have an account before they can successfully login to the Google Apps domain. There are several methods to provision the users to Google Apps:

1. Manual. An administrator can manage users through Google Apps administrative interface. See this Google Apps support page.
2. Upload of CSV file (see this Google Apps support page)
3. LDAP synchronisation using Google Apps Directory Sync utility (see this Google Apps support page)
4. Google Apps Provisioning API (see this Google Apps support page). An example of how a PHP provisioning script could look like is attached here.
5. On first login of the user. This functionality is provided by SURFconext and creates an account for the user when SURFconext detects that no account exists yet. Also, the user's group memberships are provisioned to Google Apps.

6) Other

When connecting google, please consider the following information:

• Steps to successfully use google
• Mobile access

ROLL OUT

MOBILE ACCESS

Google Apps includes some non-web based interfaces for mobile and desktop access, most notably the IMAP for mail and CalDAV for calendaring. If you want your users to be able to use these interfaces, they must have a password set in Google Apps as the authentication for these interfaces are not webbased. But because SSO is enabled, a user will not be able to set or change his password in Google Apps directly.

If you want your users to be able to use these non-web interfaces, you have several options:

1. The institution's web page that changes the user's AD/SSO password also updates the user's Google Apps password, that way the passwords should stay in sync. If you go that route, you may want to disable the ability for users to use CTRL+ALT+DEL to change the password for AD as that will cause it to fall out of sync with Google Apps.
2. Configure a separate web page that changes the user's Google Apps password. Explain that this password is only used for IMAP/POP3, Mobile clients and Outlook Sync, not SSO logins.
3. Google Apps admins can manually set users Google Apps passwords as needed via the Control Panel. This works if you have a relatively small number of users using any of the above services but as that number scales, it quickly becomes unmanageable and you should consider 2 or 3.

Additional information: