Office365 & SURFconext

Choosing a sign-in model for Office 365 Microsoft biedt momenteel 3 manieren om identiteiten te beheren en mensen te laten authenticeren voor diensten. Links: “alles in de cloud” (dus geen lokale AD meer), in het midden een synchronisatie van gebruikers-accounts en hashes van gebruikerswachtwoorden en rechts echt federatief (alleen gebruikersaccounts worden dan gesynchroniseerd ivm provisioning) Lager “Effort to implement” Hoger Lager “Capability” Hoger Bron: https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/

Passwords & “alles moet werken” Bij het “Synchronized Identity”-scenario van Microsoft heeft Microsoft oplossingen proberen te vinden voor zoveel mogelijk situaties waarbij er gebruik wordt gemaakt van protocollen die niet goed werken met federatief inloggen. Een voorbeeld is het IMAP-protocol voor email. Het voordeel van de manier waarop Microsoft dat probeert op te lossen is dat er daardoor veel werkt (niet altijd alles). Het nadeel is dat gebruikers hun wachtwoord soms in schermpjes intikken waarbij dat wachtwoord voor Microsoft en soms ook app-bouwers etc zichtbaar zijn. Microsoft maakt op enig moment een hash van dat wachtwoord zodat die vergeleken kan worden met de hash die ze hebben van de lokale user-store. Het is belangrijk dat je je beseft dat het wachtwoord via minimaal 1 en mogelijk meer partijen gaat, waarbij het een keuze is of je vindt dat dat acceptabel is.

Inloggen op Office 365 “MS Modern Authentication” Is het acceptabel dat wachtwoorden naar Microsoft gaan? Ja Nee Koppel met Microsoft (Active) Werkt met MS apps en browser Werkt met MS SA Werkt soms met apps van derden (bv Thunderbird via IMAP Maak gebruik van een federatieve koppeling (Passive) Werkt met browser en veel MS apps Werkt vaak niet met apps van anderen Free/busy (wellicht meer) werkt niet Mogelijk in de toekomst SURFconext Sterke Authenticatie Dit plaatje probeert de vraag “hoe wil ik met O365 koppelen” zo simpel mogelijk te maken. Als je ”zoveel mogelijk wil laten werken” is wat Microsoft de “synchronized identity”-oplossing noemt (de linker tak van bovenstaand plaatje) het best. Nadeel is zoals eerder gezegd dat er mogelijk wachtwoorden via 1 of meer derden (waaronder Microsoft) gaan. Wil je die wachtwoorden niet via andere partijen laten lopen, dan is de rechtertak het best. Daarbij kan dan zowel voor een directe koppeling via ADFS worden gekozen als koppelen via SURFconext. Op https://wiki.surfnet.nl/pages/viewpage.action?pageId=54703743 zetten we op een rij wat de voor- en nadelen zijn. Active connection - this describes a WS-Trust non-browser-based connection to Office 365 Passive connection - this describes a SAML2P or WS-Federation browser-based connection to Office 365 SAML vs WS-Federation Office 365 supports both SAML2 and WS-Federation protocols. While SAML2 provides more profiles, WS-Federation is more widely used in Office 365 and works with more clients. The configurations are much the same, but the attribute contracts are slightly different. Office 365 expects the SAML2 Subject to be unique (usually the objectGUID) and the attribute IDPEmail to be the user's userPrincipalName whereas Office 365 expects WS-Federation to provide a UPN attribute containing the userPrincipalName and the ImmutableID to be unique (also usually the objectGUID). https://ping.force.com/Support/PingIdentityArticle?id=kA340000000PMraCAG Wilt u graag werken via SURFconext “MS Modern Authentication” Nee Ja Koppel direct met MS via een Passive connection (ADFS) Koppel via SURFconext

Toelichting Als je bij het configureren van een rechtstreekse koppeling tussen instelling en Microsoft de beveiliging op het niveau wil hebben zoals het via SURFconext loopt, loop je tegen dezelfde dingen aan als wanneer je het via SURFconext laat lopen. Microsoft ondersteunt federatieve authenticatie (nog) niet volledig. Of Office365 voor ‘een’ instelling op ‘een’ moment werkt hangt af van de configuratie bij de instelling, het scenario (wat wil men gebruiken van Office365, via welke clients gaan er gebruik worden gemaakt) en het bij vragen/problemen vinden van de mensen met de juiste kennis. Wat wel en niet werkt met federatieve sign-in is aan verandering onderhevig. De kennis van SAML binnen Microsoft lijkt beperkt. Support op routes waar ook SAML gebruikt wordt, hebben kunnen uitdagingen hebben indien support nodig is In andere landen werkt koppelen via de nationale federatie soms wel. Deze federaties (oa. VS) werken met Shibboleth (SAML-software) en dit ondersteunt het SAML-ECP protocol. Microsoft ondersteunt deze SAML variant ook. Deze variant wordt niet ondersteund door SURFconext, omdat ook hier wachtwoordinformatie naar Microsoft gaat.

Status of client support of fed.authN Zie voor actuele stand: https://blogs.office.com/2015/11/19/updated-office-365-modern- authentication-public-preview/ Status 3 feb 2017:

Nuttige links Wiki over Office 365 en SURFconext: https://wiki.surfnet.nl/display/services/Microsoft+Office+365 Microsoft pagina over wat wel en (nog) niet werkt: https://blogs.office.com/2015/11/19/updated-office-365-modern-authentication-public-preview/ Wat staat mbt ‘Modern Authentication’ standaard aan/uit in Office365: http://social.technet.microsoft.com/wiki/contents/articles/32711.exchange-online-how-to- enable-your-tenant-for-modern-authentication.aspx Toets Office365 tegen normenkader: https://www.surf.nl/nieuws/2015/08/microsoft-getoetst- aan-juridisch-normenkader-cloudservices.html SURFconext: www.surfconext.nl Sterke Authenticatie: https://www.surf.nl/diensten-en-producten/surfconext/wat-is- surfconext/surfconext-sterke-authenticatie/index.html SURFmarket: https://www.surf.nl/nieuws/2014/01/contractmogelijkheden-microsoft-office-365- uitgebreid.html SURFspot: https://www.surfspot.nl/microsoft-office-365-proplus-nl-uk.html Discussie over veiligheid van de Outlook app: https://4sysops.com/archives/is-microsofts- outlook-app-for-ios-and-android-insecure/

Vragen?

raoul.teeuwen@surfnet.nl @raoulteeuwen raoul_teeuwen www.linkedin.com/in/raoulteeuwen https://www.surf.nl 0887873000