Ein Problem, dass sich im Web immer wieder ergibt und sich jetzt mit dem Trend zu Cloud Anwendungen für Unternehmen weiter zu spitzt ist die Identitätskrise im Internet.
Auf jeder Seite, für jeden Webdienst ist ein eigener Login notwendig. Das führt dann dazu, dass der User für jeden der Dienste die gleichen Login Daten verwendet.
Das Problem dabei ist: Wird das Passwort bei einem Dienst gehackt oder gestohlen, sind alle Logins des Users bei alles Diensten unsicher.
Für Administratoren in einem Unternehmen ergibt sich ein weiteres Problem, sie können keine Security Policies auf diese Passwörter definieren, und auch nicht die gewohnten Dienste wie Single Sign On, oder das zurücksetzen eines Passwortes anbieten.
Um dieses Problem in den Griff zu bekommen hat Microsoft Active Directory Federation Services (ADFS) 2.0 entwickelt. Die Idee dabei: Es gibt einen zentralisierten Dienst, der das Überprüfen der Login Daten übernimmt, und dieser gibt die einige Informationen über den User und ein Security Token an den Dienst, an den der User angemeldet werden soll.
Das Ganze ist besonders Sicher implementiert, investiert Microsoft sehr in sicheren Code, mehr Info dazu unter Microsoft Secure Development Lifecycle. Andererseits wird auch die gesamte Kommunikation zwischen ADFS und dem Dienst an dem man sich anmelden will über SSL verschlüsselte Kanäle abgewickelt. Das stellt sicher, dass unbefugte Parteien die Kommunikationen zwischen den Services nicht benutzen können um eigenen User an dem System anzumelden.
ADFS 2.0 ist vor allem in 2 Szenarien einsetzbar:
WebSSO
Im ersten Szenario geht es darum 3rd Parties Zugriff auf das eigene System zu geben, wobei aber die Accounts noch intern verwaltet werden.
Interessant ist das zB für Partner oder Kunden meiner Firma, denen ich Zugang zu einem kleinen Bereich in meinen eigenen Systemen geben möchte.
Gehen wir davon aus, dass mein Unternehmen mehrere Partnerfirmen hat, die Verkaufschancen anmelden und entsprechend Unterstützung in diesen Verkaufschancen von mir bekommen.
In diesem Szenario möchte ich, dass diese Partner in meinem Dynamics CRM System neue Verkaufschance anlegen können und ihre eigenen Verkaufschancen bearbeiten können.
Zusätzlich bekommen sie auch Marketingmaterial für Ihre Zwecke zu Verfügung gestellt, deswegen sollen sie auch Zugriff auf die Sharepointsite bekommen, in der die entsprechenden Marketingmaterialien abgelegt sind.
Der User soll sich nur einmal bei uns anmelden müssen um Zugriff auf CRM und Sharepoint zu bekommen.
ADFS übernimmt in diesem Fall die Rolle der Anmeldeseite und gibt dann die Anmeldedaten sowohl an CRM als auch Sharepoint weiter. Der User kann auf beide Systeme zugreifen, hat sich aber nur 1x angemeldet.
Federated SSO
Der nächste Ausbauschritt ermöglicht es dann dem Partner, dass sich seine User an unserem CRM anmelden, ohne Login Daten eingeben zu müssen.
Dazu benötigt auch der Partner ADFS oder ein dazu kompatibles System. Zwischen den ADFS des Partners und dem eigenen ADFS wird ein Trust erstellt. Das bedeutet, dass wir unserem ADFS erlauben, die Anmeldung an das ADFS vom Partner auszulagern.
Das ADFS vom Partner übermittelt außerdem welchen Gruppen der User angehören soll. Man nennt dies einen Security Claim.
Unser ADFS kann dann so konfiguriert werden, dass die User der Partner anhand dieses Claims unterschiedliche Sicherheitsrollen bei uns im CRM und Sharepoint zugewiesen bekommen.
In diesem Fall läuft also der gesamte Anmeldeprozess vollkommen transparent und der User der Partners kann sich an unserem CRM genauso anmelden als wäre es ein internes System des Kunden.
So erreicht man verteilt über mehrere Organisationen ein Single Sign On für den User oder ein integrierte Identität.
0 Kommentare:
Kommentar veröffentlichen