Nahezu jede geschäftsrelevante Applikation (Anwendungsprogramm) benötigt eine Form der Benutzeranmeldung (authentication/Authentifikation), um dem Benutzer entsprechende Rechte innerhalb der Applikation einräumen zu können.
Single Sign-on: Geschichte
Eigentlich ist Single Sign-on für Applikationen innerhalb einer Active Directory Domain schon seit dem Bestehen von Active Directory Domain Services (ADDS) kein Problem mehr. Werden jedoch Applikationen in die Cloud verschoben und der Zugriff auf sie muss von überallher via SSO erfolgen können, gilt es, ein paar Hürden zu nehmen:
Um SSO über Domaingrenzen hinweg für Public Clouds zu ermöglichen, werden andere Protokolle benötigt als jene, welche von den klassischen ADDS bereitgestellt werden. Der naheliegende Lösungsansatz ist, die ADDS einfach um diese zusätzlichen Protokolle zu erweitern. Genau diesen Ansatz verfolgt Microsoft mit seinen Active Directory Federation Services (ADFS). Mit ADFS können grundsätzlich beliebige Cloud Applikationen per Einmalanmeldung erschlossen werden. Die einzige Voraussetzung dafür ist, dass die Applikation auch die entsprechenden Protokolle unterstützt. So flexibel und mächtig die ADFS sind, so anspruchsvoll sind sie hinsichtlich ihres Betriebes und erfordern zusätzliche IT-Infrastruktur (~4 Server).
Microsoft Azure Active Directory (AzureAD) ist die Cloud-Erweiterung der ADDS. Denn Microsoft Azure Active Directory unterstützt genau jene Protokolle, die für Single Sign-on zur Cloud benötigt werden. Zudem bietet AzureAD Verzeichnisdienste für Cloud-Applikationen. Microsoft AzureAD ist aber nicht einfach ein neues Verzeichnis, das gepflegt werden muss, sondern kann (und soll) mit den ADDS synchronisiert werden, um eine konsistente User-Verwaltung zu erreichen. Einziges Problem: Wie kann sich ein ADDS-Benutzer über Single Sign-on für den Microsoft AzureAD und den angebundenen Cloud-Applikationen authentifizieren? Diese Anforderung konnte Microsoft bisher nur mit den ADFS erfüllen – doch diese Zeiten sind vorbei.
Single Sign-on als Cloud-Service
Mit Seamless SSO verhält sich AzureAD gegenüber den ADDS wie ein klassischer Service. Damit wird Single Sign-on für AzureAD möglich, ohne dass zusätzliche Services in Betrieb genommen werden müssen. Das funktioniert jedoch nur, solange der Client sich innerhalb der ADDS Domain bewegt. Außerhalb der Domain muss sich der Benutzer anmelden, um auf seine Cloud-Applikationen zugreifen zu können – für Modern-Workplace-Ansprüche ist es also noch nicht die perfekte Lösung, aber es ist eine gute Zwischenlösung, um Single Sign-on für Cloud-Applikationen auch mit älteren Clients als Windows 10 zu ermöglichen.
Windows 10 geht noch einen Schritt weiter und ermöglicht SSO von überallher. Dies wird ermöglicht, indem das Device des Benutzers im AzureAD registriert wird (ähnlich wie bei einem klassischen Domain Join). Um dem modernen Workspace Rechnung zu tragen, bietet Windows 10 verschiedene Varianten der AzureAD Device Registrierung an:
- Devices, welche bereits in die ADDS Domain eingebunden sind, werden automatisch in AzureAD registriert
»klassische« Firmen-Clients mit Windows10 - Clients können auch nur in AzureAD registriert werden
mobile Firmen-Clients mit Windows10 - Benutzer können ihren AzureAD Zugang mit ihrem privaten Gerät verbinden
private mobile Clients mit Android bzw. iPhone bzw. Windows10.
Die Kombination von Seamless Single Sign-on und der AzureAD-Device-Registrierung ergibt SSO-Lösungen für die unterschiedlichen modernen Workplace-Szenarien – auch ganz ohne den Einsatz von ADFS.
SSO und die Veröffentlichung von On-Premises-Applikationen
Bisher haben wir Single Sign-on nur für Cloud-Applikationen behandelt. Aber was ist mit bestehenden Web-Applikationen, welche als On Premises (also nicht als Cloud Computing) betrieben werden? Single Sign-on ist bei diesen Applikationen in der Regel nicht die Herausforderung. Voraussetzung ist lediglich, dass diese in irgendeiner Form in ADDS integriert sind. Spannender wird es, wenn diese Applikationen auch außerhalb des Firmennetzwerks in sicherer Art und Weise verfügbar gemacht werden sollen:
Aus sicherheitstechnischen Gründen sollten Web-Applikationen, auch wenn sie via Internet erreichbar sind, nur für legitimierte Benutzer sichtbar sein. In der Praxis wird darum die Benutzeranmeldung aus der Applikation herausgelöst und in ein für diese Aufgabe konzipiertes System ausgelagert. Erst wenn der Benutzer sich an diesem System erfolgreich angemeldet hat, gibt dieses den Zugriff auf die eigentliche Applikation frei.
Als klassische Lösung bietet Microsoft für diese Aufgabe den Web Application Proxy (WAP) an. Dieser benötigt aber zwingend ADFS. Doch auch diese Anforderung kann ohne ADFS erfüllt werden: Möchte man lieber auf ADFS verzichten, gibt es eine cloudbasierte Lösung, welche unter dem Namen AzureAD Application Proxy vermarktet wird. AzureAD Application Proxy besteht aus einem Cloud Service und einem Connector, welcher die On-Premises-Applikation mit dem Cloud Service verbindet. Somit können auch bestehende On-Premises-Applikationen ohne zusätzliche Infrastruktur einfach und sicher veröffentlicht werden – und das sogar mit SSO-Funktionalität.
Conditional Access und MFA
Single Sign-on an sich ist aus Benutzersicht eigentlich immer wünschenswert. Trotzdem gibt es heikle Applikationen, für die man sich ein sicherheitstechnisch stärkeres Anmeldeverfahren als Benutzername+Passwort wünscht, wie es Windows Clients typischerweise anbieten. Um dies zu erreichen, wird neben dem Passwort in der Praxis ein spezielles Sicherheitstool bzw. Device verwendet, welches der Benutzer bei sich tragen muss, um sich anmelden zu können. Zu den typischen Vertretern dieser Devices gehören Smartcards. Diese benötigen jedoch zusätzliche Infrastruktur und Know-how, um den Service sicher betreiben zu können. Darum gehen Hersteller wie Microsoft dazu über, das Mobiltelefon des Benutzers als Sicherheitsdevice zu verwenden. Microsoft bietet hierfür die Azure Multifactor Authentication (Azure MFA) als Cloud Service an, der grundsätzlich ohne zusätzliche Infrastruktur auskommt und komplett durch Microsoft betrieben wird.
Doch auch mit AzureMFA möchte man nur bei besonders heiklen, also nicht generell für alle Applikationen eine sicherheitstechnisch strengere Authentifizierung vom Benutzer verlangen. Zudem kann es auch sein, dass nur dann eine strengere Authentifikation gefordert wird, wenn der Benutzer sich von einem privaten oder öffentlichen Gerät aus anmeldet. Wir müssen die Anforderung der sicherheitstechnisch stärkeren Authentifizierung für eine Applikation an das Gerät binden können, von dem aus sich der Benutzer anmeldet. Genau diese Anforderung erfüllt Conditional Access. Conditional Access gibt es für AzureAD und ADFS. Dabei werden genaue Bedingungen formuliert, die erfüllt sein müssen, damit die Anmeldung zu einer Applikation ermöglicht wird. Werden diese Bedingungen nicht erfüllt, verweigert Conditional Access die Anmeldung. Damit kann sichergestellt werden, dass heikle Applikationen zum einen nur dem richtigen Benutzer und zum anderen dem Benutzer nur dann zur Verfügung stehen, wenn die Anmeldung über einen vertrauenswürdigen Client und mit einem hinreichend sicheren, strengen Authentifizierungsverfahren erfolgt ist.
Weitere interessante Blogbeiträge:
Risikofaktor Mensch - Insider Attacken verhindern
Chatbots Support-Alternativein Unternehmen
Trends im stationären Handel