John Craddock, Infrastructure and Security Architect, XTSeminars Ltd
(Ach, welch ein Vergnügen, John ist ein Engländer mit einem unglaublich angenehmen Akzent.... British English ...)
Wichtig für die Zusammenarbeit mit der Cloud
Wie schaut Authentifizierung in der eigenen Umgebung aus ?
Single Sign on, Kerberos..
Developer müssen, um zu wissen, ob der User in einer bestimmten Gruppe ist, verschiedene Möglichkeiten prüfen.. Ad Lookup, SQL Lookup, ...
Wie schauts aus mit der Authentifizierung von draussen ?
Wie schaut die Authentifizierung über die Cloud aus ?
Wie gebe ich Partnern Zugriff auf meine Services ?
Das sind Herausforderungen heute... Wie löse ich das ?
Ziel ist ein Identity Framework das dies löst...
- Ein Framework, dass von allen Apps genutzt werden kann, unabhängig von der Location
- Ein Framework, das mehr INformationen enthält als nur der Benutzername und Gruppenmitgliedschaft – wo ich als Developer sagen kann, welche INformationen über den Benutzer ich brauche (Abteilung, Full Time Employee...)
- Ein Framework, wo ich einen Trust zu meinem Partner baue, dass er seine Benutzer, die bei mir Zugreifen, selber authentifiziert
- Ein Framework, das auf Industriestandards basiert
- Ein Framework das für Browser und Webservcies funktioniert
Die Lösung: Federation of Identity
Da gibt es viele Spieler im Markt – Microsoft Lösung ist Active Directory Federation Servcies (ADFS) 2.0
Key-Konzept:
Identity Profider (IP) – authentifiziert den Benutzer,
Security Token Service (STS)
User macht einen Identity Request: BItte gib mir einen Security-Token, der mir ermöglicht auf Ressource X zuzugreifen
Die Ressource X (Ressource Provider) vertraut dann meinem Security-Token
Wir brauchen Claims Aware Applikationen – Appliaktionen, die mit diesem Token umgehen können – spannend ist, dass die Authentifizierung intern, im Extranet, im INternet und in der Cloud gleich funktioniert
SharePoint Servcies und SharePoint 2010 können enabled werden, um claim based identity zu unterstützen
ADFS ist INdustrie Standard und unterstützt aktive udn passive Clients
Passive Client
User greift auf Applikation zu
App stellt fest, User ist nicht authentifiziert und schickt uUser zur STS, der die App vertraut
ADFS STS authentifiziert User gegenüber dem AD
ADFS STS erzeugt einen Security Token mit allen notwendigen Informationen
User greift mit diesem Zertifikat auf App zu
X.509 Certificates
PKI ist für Kommunikation zwischen App und STS notwendig
Federation Metadata
Wenn ich die Verbindung zwischen der app und meinem ADFS herstelle, definiere ich, welche Infos ich bereitstellen kann, welche die App akzeptiert, tausche die Public Keys aus
Installing ADFS
recht einfach, ich brauche Server 2008 R2, braucht IIS, .net 3.5 SP1, WIF, Server Zertifikat, ...
Configuration
Ich muss dem ADFS mein AD als claims provider definieren
Ich muss die App als Claim requester defineiren
Ich kann pro Applikation festlegen, welche Infos diese Requesten darf und welche Benutzer meines ADs (oder auch aus einem SQL Server) diese App “nutzen” dürfen bzw. sich gegenüber dieser App authentifizieren dürfen
Sehr flexibel und wesntlich besser als bei ADFS 1.0
Sehr coole Lösung – für den Benutzer auf seinem Corp-Rechner schaut es so aus, als hätte er ein Single-Sign On beim Zugriff auf eine Partner-Webseite
In Wirklichkeit hat im Hintergrund sein AD ihn Authentifiziert und ihm ein Zertifikat ausgestellt...
Warum ist das auch noch interessant ?
Weil in Office365 die Authentifizierung über ADFS passiert (passieren kann) und damit ein echtes Single Sign on ist...
Christian, live aus Berlin von der Technet
Christian.decker@microsoft.com