Die gleichen Anmeldeinformationen für Firmenapplikationen verwenden wie für Office 365? Kunden und Lieferanten sicheren und kontrollierten Zugriff auf interne Applikationen ermöglichen?
Wir zeigen die Herausforderungen beim Identity Management auf
und veranschaulichen einen cloud basierten Lösungsansatz, der diesen Anforderungen gerecht wird.
von Stefan Zettel
Die Probleme mit Identity Silos
In der Vergangenheit war es üblich, Benutzernamen, Passwörter (Hashs) und die entsprechenden Berechtigungen pro Applikation zu speichern. Das hatte zur Folge, dass derselbe Benutzer für jede Applikation unterschiedliche Anmeldeinformationen verwenden musste.
Die Administration war aufwändig, wenn zum Beispiel ein Mitarbeiter das Unternehmen verliess oder die Berechtigungen in mehreren Applikationen geändert wurden. Cloud basierte Applikationen waren genauso davon betroffen wie firmeninterne, On-Premises Anwendungen.
Authentifizierung
(engl. Authentication, AuthN)
Bin ich wirklich die Person, welche ich vorgebe zu sein? Diese Überprüfung wird heute noch oft anhand von Benutzername und Passwort durchgeführt. Die Authentifizierung ist unabhängig von der Applikation und deren Funktionalität.
Autorisierung (Berechtigung)
(engl. Authorization, AuthZ)
Welche Berechtigungen hat ein Benutzer auf bestimmte Funktionalitäten einer Applikation? Diese Berechtigungen werden z.B. von einem Administrator definiert. Die möglichen Berechtigungen sind abhängig von der Applikation und deren Funktionalität.
Eine kleine Verbesserung brachte die Authentifizierung von firmeninternen Applikationen durch einen lokalen Verzeichnisdienst wie z.B. Active Directory. Dadurch wurden die Identitäten zentral verwaltet. Einfache, gruppenbasierte Berechtigungen waren häufig anzutreffen. Wegen technischen Einschränkungen (Windows Authentication) waren diese Lösungen nicht Internet kompatibel und daher nur innerhalb des Firmennetzwerks einsetzbar. Applikationen waren jedoch nach wie vor nicht zentral administrierbar, die Berechtigungen mussten auf jeder Applikation spezifisch aufgesetzt werden.
Die Lösung mit Token basierter Authentifizierung
Um zu ermöglichen, dass jeder Benutzer:
- nur ein einziges Anmeldekonto (Login) benötigt
- sich nur einmal anmelden muss, um unterschiedliche Apps zu verwenden
ist eine Lösung erforderlich, bei welcher die Authentifizierung und die Autorisierung von der eigentlichen Applikation entkoppelt ist. Dadurch wird es möglich, beliebige Applikationen zentral zu registrieren und deren Berechtigungen für entsprechende Benutzergruppen pro Applikation zu definieren (SSO, Single Sign On).
Ein Identity Provider ist ein solcher Dienst, welcher einen Benutzer authentifiziert und ein applikationsspezifisches Datenpaket (Token) zurückliefert, welches digital signierte Informationen über den Anwender und deren Berechtigungen (Claims) enthält.
Sobald ein Benutzer z.B. auf die CRM App zugreift, bemerkt diese, dass kein gültiges Token mitgeliefert wurde und leitet den Benutzer deshalb für den Anmeldeprozess an den Identity Provider weiter. Sind Benutzername und Passwort verifiziert, werden ev. auch noch weitere Faktoren abgefragt (MFA). Dazu sendet der Identity Provider z.B. eine Benachrichtigung an eine Authenticator App, welche vom Benutzer auf dem Mobiltelefon bestätigt werden muss.
Nach einer erfolgreichen Authentifizierung werden auch die spezifischen Berechtigungen, welche der Benutzer Huber auf die CRM App hat, ausgelesen. Anschliessend stellt der Identity Provider ein digital signiertes und zeitlich begrenztes Datenpaket aus (Token), welches den Benutzername und beliebige, weitere Informationen zur App Berechtigung enthalten kann.
Schlussendlich wird der Benutzer zurück an die CRM App verwiesen. Diese überprüft das Token anhand der digitalen Signatur und wertet die darin enthaltenen Informationen aus (in unserem Beispiel also Alter und Administratorenberechtigung).
Greift der Benutzer auf andere Applikationen zu (z.B. HR App), wird ein neues, applikationsspezifisches Token ausgestellt, ohne dass sich der Benutzer erneut anmelden muss.
Ein Identity Provider ermöglicht es also, Anmeldeinformationen, Berechtigungen und Applikationsinformationen zentral abzulegen, zu administrieren und zu verifizieren, ohne dass eine Applikation davon Kenntnis haben muss (Entkopplung).
Identity und Access Management als SaaS Angebot
Nebst Authentifizierung, Autorisierung, Single Sign-On und MFA gibt es viele weitere Aspekte zum Thema Identity und Access Management. Zum Beispiel falls neue Mitarbeiter eingestellt werden bzw. diese die Firma verlassen (onboarding/offboarding), wenn Benutzer ihr Passwort selbständig ändern oder zurücksetzen möchten oder falls kundenspezifische Apps integriert werden sollen.
Nebst anderen IdP Providern wird Microsoft Azure Active Directory (AAD) häufig im Unternehmensbereich eingesetzt. AAD ist eine SaaS basierte Identity Plattform, welche auch die Basis für Office 365 bildet. Ein individueller AAD Kunde (Mandant wie z.B. Unternehmen, Schule oder andere Organisation) wird durch einen Tenant repräsentiert, welcher unter anderem Benutzeraccounts, Berechtigungen und Applikationsregistrierungen enthält. Die Daten in den Tenants sind gegenüber den anderen Kunden jedoch komplett isoliert, obwohl die Software und der Endpunkt (https://login.microsoftonline.com/) von allen AAD Kunden geteilt werden.
Zusammenarbeit mit Kunden und Lieferanten
Für die Zusammenarbeit mit Kunden und Lieferanten ergeben sich neue Möglichkeiten, falls diese Partner ebenfalls einen cloudbasierten Identity Provider wie z.B. AAD einsetzen. Das Unternehmen kann z.B. seine e-Invoicing App ihren Lieferanten zur Verfügung stellen, die dank Identity Federation ihre eigenen Benutzerkonten verwenden können.
Greifen die Benutzer von Lieferant A auf die e-Invoicing App zu, werden diese für den Anmeldevorgang zum IdP des Lieferanten A weitergeleitet. Nach erfolgreicher Authentifizierung kehrt der Lieferantenbenutzer wieder zum IdP des Unternehmens zurück. Dieser stellt nun anhand der aufgesetzten Berechtigungen (Benutzer Lieferant A, e-Invoice App) ein spezifisches Token aus.
Damit diese Verbunds Authentifizierung gelingt, muss der Unternehmensadministrator vorgängig eine Vertrauensbeziehung zu Lieferant A aufsetzen und die e-Invoice App Registrierung entsprechend konfigurieren.
Der Lieferant ist also verantwortlich für die Benutzerauthentifizierung (Login mit MFA), das Unternehmen verantwortet die Autorisierung auf die entsprechende App.
Auf diese Weise lassen sich auch viele weitere Enterprise Applikationen wie SAP, Workday, Salesforce, AWS etc. einfach integrieren.
Fazit
Die Verwendung einer cloudbasierten Identity Plattform ist die Basis für eine erfolgreiche Anbindung von Partnerorganisationen und Applikationen. Nicht nur Applikationen von Drittherstellern lassen sich einbinden, sondern auch eigene, kundenspezifisch erstellte Web und Mobile Applikationen. Verbesserungen wie Multifaktor Authentifizierung oder Passwortlose Authentifizierung sind für solche Applikationen sofort verfügbar.
Haben sie Fragen oder sind sie interessiert an unseren Dienstleistungen? Wir freuen uns von Ihnen zu hören.
