Federated Identities und SSO mit Windows Azure Tom Hofmann Cambridge Technology Partners

Tom Hofmann / Senior Consultant Identity and Access Managment Identity Federation and SSO Cloud Security Public Key Infrastructure Mobile Device Management / BYOD

Ein Überblick Identity Federation Federation & Azure Use Cases

Ein Überblick

Wo stehen wir heute? Einmaliges anmelden SingleSignOn durch Kerberos Authorisierung via AD Gruppen Lokales Identity and Access Management

Neue Anforderungen Cloud Services Mobile Devices Wachsende Zusammenarbeit (Identity Federation) Mobilität und Vernetzung

und neue Herausforderungen User und Account Management (3rd Parties in meinem AD?) Umgang mit mobilen Endgeräten Sicherheit wo liegen meine Userinformationen? welche Passwordrichtlinien gelten? Auditing? Logging? Integration der Cloud Dienste SingleSignOn, unabhängig von Gerät, Dienst und Lokation Öffnung hin zu sozialen Diensten (Facebook, Yahoo, Google, etc.)

benötigen neue Lösungen Cambridge Technology Partners entwickelt eine Testplatform in der Cloud, solutions-for-clouds.ch 100% Cloud basierend (IaaS, PaaS, SaaS) Integration unterschiedlichster Cloud Dienste Unterstützung neuer form factor devices (Smartphones, Tablets)

solutions-for-clouds.ch Implementation einer virtualisierten Firmeninfrastruktur mit Windows Azure IaaS AD FS als Cloud Service mit Windows Azure PaaS Integration der UC Struktur via Office 365 SaaS Vollständige DNS Integration Erweiterung durch 3rd Party SaaS Angebote Mobile Device Unterstützung

Architekturübersicht Microsoft Azure Azure Access Control Service IaaS Virtual Network Active Directory DS Public Key Infrastructure DirSync SharePoint 2013 Foundation Office365 SAP Salesforce.com Trust Trust PaaS AD FS Server 2012 AD FS Server 2012R2 Virtual Loadbalancer Trust

Azure Überblick Hands on

Ein Einstieg Identity Federation

Was ist Identity Federation 1 digitale Identität für beliebig viele Anwendungen Unabhängig davon wo bzw. durch wen die Anwendung betrieben wird. SingleSignOn Funktionalität Einbindung der Identitäten von Partnern und Kunden Einbindung sozialer Identitäten (Facebook, Google, etc.) Nutzung unterschiedlicher Protokolle (SAML, WS-*, OpenID)

Wie funktioniert Federation? User App (Reliying Party) Federation Service AD 1 Access request 3 Redirect user to federation service 2 Unauthenticated user 4 Get federation login page 5 Present user forms based login 6 Send user credentials 7 Verify credentials 9 Build claim and send it to user 8 Send user information 10 Send token to relaying party 12 Grant access to user 11 Verify token

Ein Beispiel Authentifizierungsflow zwischen Client, Federation Service und SharePoint Ausgestelltes SAML Token mit UPN, emailadress und role claims

Features durch Identity Federation Trennung Applikation und Authentisierung Standortunabhängig (on-premise, cloud, partner) Anwendungsspezifische Informationen (Claims) Flexibilität innerhalb der Claims (AD, SQL, Custom Store) Unabhängig vom Identity Provider (AD, Facebook, Google) Credentials werden nicht exponiert, sondern bleiben innerhalb der Firma Keine 3rd Party Software benötigt Device unabhänig (Laptops, Tablets, Mobiles)

Der Federation Service mit solutions-for-clouds.ch Federation & Azure

Federation Service & Azure Federation Service werden über eine URL eindeutig identifizierbar (login.sts.solutions-for-clouds.ch) CNAME der Firmendomain enthält pointer auf den Azure Cloud Service (-> solutions-sts.cloudapp.net) 2 unabhängige AD FS Server mit lokaler Datenbank (1x Server 2012, 1x Server 2012R2 Preview) Beide Server werden durch den Azure eigenen Load Balancer verwaltet

Die Vorteile... Eine Federation URL, ein Cloud Service, many servers Extrem hohe Verfügbarkeit Flexibilität (einfacher Ausbau der Farm) Skalierbarkeit (Scale by metric, scale by schedule) Easy to use Pre-Production Umgebung Einbindung weiterer PaaS Dienste (SQL Server) PowerShell management (config, backup, restore) Lokale Integration mit Hybrid Cloud Szenarien

Federation as Cloud Service Hands on

Use Cases

Federation mit “traditionellen” Geräten FedAuth Zugriff auf eine lokale SharePoint app Initialer request Redirect an den Federation Service Verifizierung der Credentials und Erstellung des Tokens Token wird an den SharePoint internen STS übergeben Der STS erstellt das FedAuth Cookie und leitet den Browser auf die ursprünglich angeforderte Seite Active Directory Portal App SharePoint STS Verify Credentials and gather information ADFS ADFS SharePoint 2013 Foundation Virtual Loadbalancer Return SAML token Redirect for authentication Initial Request

Federation SSO mit SaaS Applikationen SingleSignOn über mehrere Anwendung und Provider hinweg Initialer request Redirect an den Federation Service, zusammen mit den MSISAuth und MSISAuthenticated Cookies zur Validierung ADFS prüft die Gültigkeit der Session und den Identifier der anfragenden Applikation (wtrealm) Anhand der Claim Rules wird das neue, anwendungsspezifische Token erstellt Der Client schickt das Token an die Applikation und erhält Zugriff Active Directory Office365 SAP Salesforce Retrieve app specific informations ADFS ADFS Session validation Virtual Loadbalancer Return SAML token Provide cookies Initial Request

Federation mit Social IdPs Redirect user to Google login page FedAuth Zugriff auf die SP Portal app wird über den lokalen ADFS gesteuert: Initialer request Redirect an den Federation Service User wählt «Social IdPs» auf der HomeRealmDiscovery Seite des ADFS Redirect auf die HomeRealmDiscovery Seite des Windows Azure Access Control Service User wählt Google als IdP Login mit Google Credentials Google erstellt ein OpenID Token, welches an Azure ACS zurückgeliefert wird Azure ACS erhält das OpenID Token, evaluiert mögliche Claim Rules und erstellt ein neues SAML Token an den ADFS Server Das ADFS Token wird an den SharePoint internen STS übergeben Der STS erstellt das FedAuth Cookie und leitet den Browser auf die ursprünglich angeforderte Seite OpenID token Portal App SharePoint STS Access Control Service SharePoint 2013 Foundation ACS SAML token ADFS Redirect user to ACS HomeRealmDiscovery ADFS SAML token Redirect for authentication Initial Request

Federation mit mobile devices FedAuth Zugriff auf Applikationen via Federation über mobile devices (WLAN, 4G, 3G, etc.) Initialer request durch Browser app Redirect an den Federation Service Verifizierung der Credentials und Erstellung des Tokens Token wird an den SharePoint internen STS übergeben Der STS erstellt das FedAuth Cookie und leitet den Browser auf die ursprünglich angeforderte Seite SSO Funktionalität ist ebenfalls gegeben Active Directory Portal App SharePoint STS Verify Credentials and gather information ADFS ADFS SharePoint 2013 Foundation Virtual Loadbalancer Return SAML token Redirect for authentication Initial Request

Federation mit mobile apps Zugriff auf Applikationen via native mobile apps. Office365 mit OWA und SkyDrivePro for iOS. App prüft beim start cached credentials Redirect an den Federation Service zur Authentifizierung Verifizierung der Credentials und Erstellung des Tokens Zustellung des Tokens an die App Überprüfen des Tokens und Zugriffsvalidierung Ablage der Zugangsinformationen im lokalen App Cache für SingleSignOn Active Directory Verify Credentials and gather information ADFS ADFS Virtual Loadbalancer Return SAML token Send token Redirect for authentication

Zusammenfassung Heutige Anforderungen und Herausforderungen durch die Cloud Ein Einblick, was ist Federation Welche Möglichkeiten bieten sich für solche Dienste in Verbindung mit Windows Azure Integration von mobilen Endgeräten Einbindung sozialer Identitäten

Q & A

Vielen Dank für Ihr Interesse

Für Fragen und weitere Informationen 3/28/2017 1:50 PM Für Fragen und weitere Informationen Thomas.Hofmann@ctp.com vCard © 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.