GOOGLE APPS-AUTHENTICATIE VIA DE SURFFEDERATIE

G O O G L E A P P S - A U T H E N T I C AT I E V I A D E S U R F F E D E R AT I E versie 2.0, 14 april 2010

SURFNET BV, RADBOUDKWARTIER 273, POSTBUS 19035, 3501 DA UTRECHT T +31 302 305 305, F +31 302 305 329, WWW.SURFNET.NL

Google Apps-authenticatie via de SURFfederatie, versie 2.0

INHOUD

1.

Inleiding ........................................................................................ 3

2.

Federatieve toegang en Single Sign-on .................................................... 3

3.

Provisioning .................................................................................... 4

4.

5.

3.1

Inleiding ................................................................................. 4

3.2

Handmatig ............................................................................... 4

3.3

Upload CSV-bestand .................................................................... 4

3.4

LDAP-synchronisatie en Provisioning API ............................................ 4

3.5

Bij eerste inlog door gebruiker ........................................................ 5

Toegang tot e-mail: browser of e-mailclient ............................................... 5 4.1

Inleiding ................................................................................. 5

4.2

Webbrowser ............................................................................. 5

4.3

E-mailclient .............................................................................. 6

Aanbevelingen ................................................................................. 7

Appendix A – Google Apps upgraden ............................................................ 8 Appendix B – Single Sign-on Configuratie SAML 2.0........................................... 9 Appendix C – Achtergrondinformatie over Google Apps Education ........................ 10

2


1.

INLEIDING

In januari 2010 heeft SURFdiensten een licentiecontract met Google afgesloten dat het voor instellingen uit het hoger onderwijs mogelijk maakt om Google Apps af te nemen. Een van de voorwaarden uit het contract betreft het authenticeren voor de Google Appsomgeving via een aansluiting op de SURFfederatie. Google Apps biedt gebruikers van bedrijven en instellingen onder andere e-mail, agendabeheer, online documenten delen en bewerken en het maken van intranetsites. Meer achtergrondinformatie vindt u via Appendix C op pagina 10. Dit document beschrijft de relatie tussen Google Apps en de SURFfederatie. Daarnaast doen we aanbevelingen voor het inrichten van een Google Apps-omgeving met gebruik van federatieve authenticatie. Met name het provisioningproces en de manier waarop email wordt aangeboden, zijn daarbij van belang.

Contact Voor technische vragen over Google Apps kunt u contact opnemen met SURFfederatie beheer: [email protected] Voor licentievragen over Google Apps kunt u contact opnemen met SURFdiensten via: [email protected]

2.

FEDERATIEVE TOEGANG EN SINGLE SIGN-ON

Instellingen uit hoger onderwijs kunnen hun Google Apps-omgeving via SURFdiensten laten upgraden naar Google Apps for Education. Dit gaat volgens de procedure beschreven in appendix A op pagina 8. Met Google Apps for Education kunnen instellingen die gekoppeld zijn op de SURFfederatie, toegang tot de Google Appsomgeving afhandelen via de SURFfederatie. Dit heeft voor gebruikers twee belangrijke voordelen: 

Zij kunnen via hun webbrowser inloggen op de Google Apps-omgeving met hun bestaande instellingsaccount, zonder dat hun instellingswachtwoord bij Google bekend wordt gemaakt.



Single Sign-on is mogelijk: voor gebruik van zowel instellingsapplicaties als externe diensten die via de SURFfederatie worden ontsloten, hoeft een gebruiker slechts eenmaal zijn gebruikersnaam/wachtwoord combinatie in te geven.

Om Google Apps toegankelijk te maken via de SURFfederatie, kan de Administrator via de configuratie-interface van Google Apps een Security Assertion Markup Language (SAML 2.0) koppeling voor de Google Apps-omgeving configureren (zie Appendix B op pagina 9).

3


3.

PROVISIONING

3.1

Inleiding

Om gebruikers toegang te geven tot de Google Apps-omgeving, moet een administrator vooraf accounts aanmaken. Dit gebeurt via een provisioningproces. Provisioning vooraf is nodig omdat er gegevens voor gebruikers worden bijgehouden en bepaalde bronnen voor hen worden gereserveerd, waaronder opslagruimte. Er is een aantal opties om provisioning te regelen: 

handmatig



via upload van CSV-bestand



via LDAP-synchronisatie



via de Provisioning API



bij eerste inlog door gebruiker (alleen in uitzonderingsgevallen)

Welk provisioningproces het beste gebruikt kan worden, hangt onder andere af van de hoeveelheid gebruikers, de frequentie van eventuele wijzigingen en de technische infrastructuur van de gebruikende instelling. De verschillende opties worden hieronder nader besproken.

3.2

Handmatig

Het handmatig aanmaken en onderhouden van Google Apps-gebruikersaccounts is alleen zinvol voor kleine aantallen gebruikers, met relatief weinig veranderende omstandigheden. Als het gebruikersaantal groter wordt, is een geautomatiseerd proces efficiënter. De instelling moet bij deze manier van provisioning zeer zorgvuldig omgaan met het wachtwoord dat gebruikers krijgen toebedeeld. Zie hiervoor de paragraaf Wachtwoord op pagina 6.

3.3

Upload CSV-bestand

De upload van een CSV-bestand is efficiënter dan de handmatige invoer: het CSVbestand kan worden gegenereerd uit de accountdatabase van de instelling, en vervolgens handmatig worden geüpload naar Google Apps. Ook hier geldt dat bij veel veranderingen in de gebruikerspopulatie, automatische provisioning efficiënter is (zie paragraaf 3.4).

3.4

LDAP-synchronisatie en Provisioning API

Google levert voor automatisch synchonisatie via LDAP via de Provisioning API toolsets die geconfigureerd kunnen worden binnen de omgeving van de instelling. Deze toolsets zijn als volgt te benaderen: 

LDAP-synchronisatie: http://www.google.com/support/a/bin/answer.py?hl=nl&answer=106368

4




Provisioning API: http://code.google.com/intl/nl/apis/apps/gdata_provisioning_api_v2.0_reference.html

Een voordeel van deze manieren van provisionen is dat het ook mogelijk is om gebruikers te deprovisionen. Nadeel is dat het initieel veel werk is om het provisioningproces in te richten.

3.5

Bij eerste inlog door gebruiker

Via de SURFfederatie kan provisioning ook plaatsvinden op het moment dat de gebruiker voor het eerst inlogt. Dan wordt 'on the fly' een account voor hem aangemaakt. Dit is mogelijk omdat inloggen verloopt via de centrale infrastructuur van de SURFfederatie. Dit is alleen mogelijk in uitzonderingsgevallen en na overleg met SURFfederatie Beheer (via [email protected]). Het grote nadeel van deze vorm van provisioning is namelijk dat er nu geen deprovisioning van accounts kan plaatsvinden. Wanneer een gebruiker uit de instellingsdirectory verdwijnt (bijvoorbeeld door afstuderen of ontslag) wordt dit niet doorgegeven aan de Google Apps-omgeving; de gebruiker kan niet meer inloggen, maar zijn Google Apps-account en bijbehorende data blijven bestaan. Dat is in veel gevallen een onwenselijke situatie. Voordeel van deze manier van provisioning is dat de instelling zelf geen apart provisioningproces hoeft in te richten. De instelling moet bij deze manier van provisioning zeer zorgvuldig omgaan met het wachtwoord dat gebruikers krijgen toebedeeld. Zo is het vanuit veiligheidsoverwegingen onwenselijk dat wachtwoorden gedupliceerd worden. Zie verder de paragraaf Wachtwoord op pagina 6.

4.

TOEGANG TOT E-MAIL: BROWSER OF E-MAILCLIENT

4.1

Inleiding

Een van de applicaties die Google Apps biedt, is e-mail. Google Apps e-mail kan op twee manieren worden benaderd: via een internetbrowser of via een e-mailclient. De authenticatie voor het benaderen van de e-mail service verloopt voor beide applicaties op een andere manier, daarom is het van belang om een afweging te maken over de manier(en) waarop u uw e-mail dienst wilt ontsluiten.

4.2

Webbrowser

In dit geval wordt e-mail benaderd met een browser zoals Internet Explorer of Firefox, via het HTTP(S)-protocol. Het voordeel van deze manier van toegang is de goede integratie met de SURFfederatie: uw gebruikers kunnen met hun instellingsaccount

5


authenticeren voor hun e-mailomgeving. De instellingsgebruikersnaam en –wachtwoord hoeven dan niet bij Google bekend te worden gemaakt. 1

4.3

E-mailclient

E-mail wordt benaderd met een e-mailclient zoals Outlook of Thunderbird, via het IMAPprotocol. Het voordeel is dat veel gebruikers de e-mailclient die ze nu gebruiken, ook in de toekomst kunnen blijven gebruiken. Het grote nadeel is echter dat de SURFfederatie niet kan worden gebruikt om de authenticatie af te handelen. De SURFfederatie-authenticatie kan namelijk alleen gebruikt worden voor webgebaseerde diensten. Er moet daardoor een extra gebruikersnaamwachtwoordcombinatie worden aangemaakt, die bij Google wordt opgeslagen. Zie verder de paragraaf Wachtwoord. Bij het gebruik van IMAP is het noodzakelijk om een deprovisioningproces in te regelen. Zo wordt voorkomen dat gebruikers die uit de instellingsdirectory worden verwijderd, nog wel kunnen inloggen op Google Apps-mail.

Wachtwoord Het feit dat authenticatie voor e-mailtoegang niet mogelijk is via de SURFfederatie, betekent dat er een extra gebruikersnaam-wachtwoordcombinatie nodig is, die bij Google wordt opgeslagen. Deze combinatie wordt alleen voor IMAP-toegang gebruikt. Het lijkt handig en gebruiksvriendelijk om hiervoor de instellingsgegevens van een gebruiker naar Google te kopiëren, maar vanuit beveiligingsoogpunt is dit af te raden. Hierdoor worden namelijk alle instellingswachtwoorden bij Google bekend, inclusief bijvoorbeeld die van personen zoals beheerders en personeelsfunctionarissen. Juist om dat te voorkomen, is de SURFfederatie ontwikkeld. Daarom is het verstandiger om een ander wachtwoord dan het instellingswachtwoord bij Google op te slaan. Een duidelijk nadeel hiervan is echter weer dat de gebruiker een ander wachtwoord moet onthouden voor zijn webmail dan voor lokale toegang tot zijn IMAP e-mail. Een andere mogelijkheid is om een tijdelijk wachtwoord aan te maken dat de gebruiker bij de eerste inlog (die dan wel via de browser moet plaatsvinden!) moet aanpassen. De kans is dan echter groot dat de gebruiker dit wachtwoord in tweede instantie alsnog gelijkmaakt aan het instellingswachtwoord, waarmee de oorspronkelijke bedoeling van de password policy verloren gaat.

1

In het provisioningproces moet er wel een wachtwoord worden opgegeven, maar dit wordt niet gebruikt en kan dus een random waarde zijn.

6


5.

AANBEVELINGEN

Op basis van de bovenstaande overwegingen doen SURFnet en de SURFfederatie de volgende aanbevelingen voor het gebruik van Google Apps: 



Richt provisioning/deprovisioning van Google Apps-gebruikers in middels synchronisatie met uw instellingsaccountdatabase, bij voorkeur middels LDAPsynchronisatie (via Google Apps Directory Sync). Bied (voor zover mogelijk) toegang tot Google Apps e-mail alleen via een webbrowser aan, om optimaal gebruik te maken van de mogelijkheden die de SURFfederatie biedt op het vlak van beveiliging en Single Sign-on.

7


APPENDIX A – GOOGLE APPS UPGRADEN De upgrade van Google Apps naar Google Apps for Education kunt u zelf regelen bij Google. 1. Maak een domein aan via http://www.google.com/a/cpanel/education/new?type=university. 2. Vraag de upgrade naar Google Apps for Education aan via http://www.google.com/support/a/bin/request.py?contact_type=nonprofit. 3. Zorg ervoor dat de licentiecontactpersoon van uw instelling via www.surfdiensten.nl de overeenkomst van Google afsluit. Dit is onder andere nodig voor de check die Google uitvoert. Dit versnelt verder het aansluitproces. 4. Google controleert of uw domein valt onder de licentie die is afgesloten met SURFdiensten. U ontvangt hierover na maximaal drie weken bericht. 5. Stel Google Apps in met de handleiding van Google: http://www.google.com/a/help/intl/en/admins/resources/setup/



In deze Google-gids speciaal gericht op onderwijstoepassingen, leest u hoe u Google Apps kunt toepassen in de praktijk: http://www.google.com/support/a/bin/answer.py?answer=67775

8


APPENDIX B – SINGLE SIGN-ON CONFIGURATIE SAML 2.0 1. Geef de (domein)naam van uw Google Apps omgeving door in een mail aan [email protected] met het verzoek om op de SURFfederatie aan te sluiten. Wacht totdat SURFnet meldt dat uw aansluiting is geconfigureerd. U ontvangt een certificaat dat u nodig heeft bij stap 2. 2. Ga in de Google Apps configuratie-interface naar het tabblad Advanced Tools > Set up single sign-on (SSO)".

3. Vul bij Change password URL een pagina van uw instelling in waar de gebruiker zijn instellingswachtwoord kan wijzigen (indien van toepassing). 4. Klik onder Verification certificate op Replace certificate om het door SURFnet geleverde certificaat te importeren. 5. Klik op Save changes.

9


APPENDIX C – ACHTERGRONDINFORMATIE OVER GOOGLE APPS EDUCATION De volgende links bieden meer informatie over het gebruiken van Google Apps Education: 

Google Apps Education website: www.google.com/a/edu.



Veelgestelde vragen: https://www.google.com/support/a/bin/answer.py?hl=en&answer=139019



Schrijf u in voor of bekijk webinars: http://www.google.com/a/help/intl/en/edu/resource_center.html



Bekijk case studies van instellingen die Google Apps Education als gebruiken: http://www.google.com/a/help/intl/en/edu/customers.html



Fact sheet: http://docs.google.com/fileview?id=0B5AOHQcScAeNzA4NzM4MzMtZTRkOC00Y2EwLWI3MmQtZTgzYjRjYWUxMDNk&hl=en



White paper over beveiliging: http://docs.google.com/fileview?id=0B5AOHQcScAeNWNmMGI3N2EtYzAxYS00YmUwLTk1MDYtOTZkMWE2OGJkNDc4&hl=en

10

GOOGLE APPS-AUTHENTICATIE VIA DE SURFFEDERATIE

Recommend Documents