My2Cents: Federated Identity Ma­na­ge­ment vs. Ei­ge­ne Be­nut­zer­kon­ten­ver­wal­tung

Es ist eine immer wiederkehrende Aufgabe in fast jedem Software-Projekt: Manage ich meine Benutzeranmeldung selber oder verwende ich ein bestehendes System großer Anbieter in Form von Federated Identity Managements (FIdM)?

Abgrenzung

Wir wollen in diesem Artikel nicht vertieft auf die technischen Details der Implementierungen eingehen. Es geht viel mehr um die Vorstellung des Konzepts hinter FIdM und eine Darstellung der Vor- und Nachteile.

Was genau ist FIdM?

FIdM stellt einen Dienst bereit, der meiner Anwendung die Verwaltung und Authentifizierung von Benutzer abnimmt. Ich muss mich also darum nicht selber kümmern, sondern verlagere die Logistik und Verwaltung in das FIdM bzw. den Anbieter.

Wie funktioniert FIdM?

Öffnet ein Benutzer meine Anwendung und möchte eine geschlossenen, geschützten Bereich besuchen, muss er sich i.d.R. mit einem Benutzernamen und einem Kennwort anmelden.

Diese Eingaben werden gegenüber einer Instanz geprüft, die feststellen kann, ob die eingegebenen Daten korrekt sind. Das Ergebnis der Prüfung ist ein Token bzw. Ticket falls die Eingaben erfolgreich geprüft werden konnten oder eine Fehlermeldung, falls die Daten inkorrekt sind. Ein Token bzw. ein Ticket kann man mit einem temporären Ausweis vergleichen, der für einen definierten Zeitraum gültig ist.

Diesen Ausweis zeigt der Anwender nun bei jeder Anfrage an unsere Anwendung (automatisch) vor und unsere Anwendung fragt bei der Instanz nach, ob dieser Ausweis noch gültig ist. Die Instanz kennt seine ausgestellten Ausweise und akzeptiert diese, wenn sie noch Gültigkeit haben.

Ein Ausweis wird dann ungültig, wenn der Benutzer beispielsweise in unserer Anwendung auf „abmelden“ drückt (dann machen wir den Ausweis direkt ungültig) oder ein gewisses Zeitfenster verstrichen ist (danach akzeptiert das FIdM den Ausweis nicht mehr).

Erst bei erneuter Anmeldung wird ein neuer temporärer Ausweis von der Instanz ausgestellt.

Ich habe bewusst den Ausdruck Instanz verwendet, denn vom Ablauf her verhalten sich FIdM und Eigenentwicklung prinzipiell gleich. Der Unterschied ist, dass ich im einen Fall mit einem (entfernten) Dienst-Anbieter kommuniziere und im anderen Fall mit den eigenen Komponenten, die eine ähnliche Funktion erfüllen.

Was ist mit Single Sign On?

Viele FIdM Dienste bieten die Möglichkeit des Single Sign Ons (SSO). Wenn sich der Benutzer einmal an einer Anwendung, die ebenfalls den FIdM-Dienst verwendet, angemeldet hat, dann muss er sich nicht erneut bei unserer Anwendung anmelden, sondern ist direkt eingelogged.

Dies erfolgt automatisch über den Token, den der Benutzer nach einer Anmeldung erhält. Dieser Token wird vom FIdM-Dienst auch in anderen Anwendungen erkannt und als Authentifizierung akzeptiert.

Ein Beispiel wäre hier: ich habe mich bei GMail angemeldet und bin automatisch auch bei YouTube mit meinem Account eingelogged, wenn ich die Seite aufrufe.

Ein anderes Beispiel wären Twitter und Facebook.

 

Pro und Contra von Federated Identity Mana­ge­ment

Was spricht für die Nutzung von FIdM?

Benutzerdaten sind sehr sensible Informationen, die ein erhöhtes Maß an Schutz verdienen (sollten). Grade im Bereich von Zugangsdaten kann man gar nicht vorsichtig genug sein, wenn es um den Schutz dieser Informationen geht.

Auf FIdM spezialisierte Anbieter oder Firmen, die einen starken öffentlichen Fokus haben und einen FIdM zur Verfügung stellen, haben in der Regel dafür Sorge getragen, dass sich Ihre Systeme eine grundsätzliche Robustheit auszeichnen.

Diese Robustheit ist je nach Teamgröße in einem Softwareprojekt nicht so einfach zu erreichen und setzt einiges an Fach- und Expertenwissen in dem Bereich voraus, um eine vergleichbare Qualität zu erreichen.

Bei FIdM-Diensten ist davon auszugehen, dass Experten in den Abteilungen sitzen, die sich ausschließlich mit den Themen Sicherheit und Schutz befassen. Diesen „Luxus“ kann sich nicht jeder IT-Dienstleister leisten.

Treten in Komponenten Sicherheitslücken auf, werden die FIdM-Dienste schnell darauf reagieren und die Sicherheitslücken schließen.

Bei kleinen Teams kann ein schneller Fix schon daran scheitern, dass der eine Kollege, der für die Umsetzung verantwortlich ist, aktuell oder gar nicht mehr zur Verfügung steht. Diese Gefahr besteht bei FIdM-Diensten in der Regel nicht.

Die Nutzung eines FIdM-Dienstes ist für alle Benutzer meiner Anwendung sehr bequem, sofern sie bei dem FIdM-Dienst bereits ein gültiges Konto besitzen.

Die Benutzer müssen sich also kein weiteres Passwort merken, welches sie vergessen können.

Was spricht gegen die Nut­zung von FIdM?

Legen wir diese sensiblen Informationen unserer Benutzer in die Hände eines Dritten, müssen wir diesem grundlegend vertrauen. Wir müssen sicher gehen, dass er verantwortungsvoll mit den Daten umgeht und die Daten zuverlässig schützt.

Eine Prüfung ist nur sehr schwer möglich, da FIdM-Dienste grade in Bezug auf die Schutzmaßnahmen eher verschwiegen sind, um potentiellen Angreifern kein Einfalltor auf dem Silbertablett zu servieren.

FIdM-Dienste sind attraktive Angriffsziele für Hacker, denn die hier ergaunerten Daten lassen Zugriff auf viele Anwendungen auf einmal zu. Wir müssen darauf vertrauen, dass bei einem Datendiebstahl der FIdM-Dienst seine Kunden so schnell und transparent wie möglich darüber informiert.

Wir müssen ferner darauf vertrauen, dass der Dienst jeder Zeit mit ausreichend Kapazität zur Verfügung steht. Ansonsten können sich unsere Benutzer nicht am System anmelden.

Wir begeben uns mit der Nutzung eines FIdM-Diensts immer in ein Abhängigkeitsverhältnis.

Ferner zwingen wir unsere Benutzer seine Daten bei dem FIdM-Dienst zu hinterlegen, sofern er dort noch kein Konto besitzt.

In den letzten Jahren ist es immer mehr publik geworden, dass auch Regierungsorganisationen Dienste und Firmen dazu zwingen, ihre Daten herauszugeben. Dies wird in der Regel nicht direkt transparent gemacht. Teilweise riskieren betroffene Firmen hohe Strafen, wenn sie darüber öffentlich sprechen.

Demnach bekommt man es unter Umständen gar nicht mit, wenn der FIdM-Anbieter kompromittiert ist.

FIdM-Dienste sind natürlich attraktive Ziele – nicht nur für Hacker.

Vorteil
+ keine Passwortdaten im eigenen System
+ Experten, die den FIdM-Dienst bereuen
+ bequem für den Benutzer

Nachteil
– keine Kontrolle der Daten(-sicherheit) möglich
– Abhängigkeit vom Dienstanbieter

 

Pro und Contra einer Ei­gen­ent­wick­lung

Was spricht für eine Ei­gen­ent­wick­lung?

Kümmern wir uns selber um die Entwicklung unseres Passwortmanagements, haben wir alle relevanten Aspekte und Komponenten unter unserer eigenen Hoheit.

Wir müssen unsere kostbaren Daten nicht aus der Hand geben und darauf vertrauen, dass ein Dritter vertrauensvoll damit umgeht.

Wir entscheiden selber, wie und wo meine Daten vorgehalten werden, kennen die Personen, die mit den sensiblen Daten jonglieren in der Regel persönlich und können im Falle eines kritischen Problems eigenhändig im wahrsten Sinne des Wortes den Stecker ziehen.

Darüber hinaus können wir selber bestimmen, nach welchem Schema die Daten verschlüsselt werden, wie ein Failover-Szenario aussieht, wo unsere Backups aufbewahrt werden und welche Personen mit den Daten in Kontakt kommen.

Unsere Benutzer müssen sich nicht an einem Drittsystem registrieren, was eventuell davor abschrecken würde, sich überhaupt bei uns zu registrieren.

Wir sind nicht davon abhängig, dass ein externer Dienst erreichbar ist damit unsere Anwendung vollständig für unsere Benutzer zur Verfügung steht.

Was spricht gegen eine Ei­gen­ent­wick­lung?

Die Idee unsere sensiblen Daten vollständig eigenverantwortlich vorzuhalten und uns selbst um alles zu kümmern, erscheint im ersten Moment sehr reizvoll und naheliegend.

Allerdings gibt es bei so einem Vorhaben einige Aspekte zu beachten, die nicht ganz trivial sind.

Wir brauchen ein stimmiges und schlüssiges Konzept zur Verschlüsselung unserer Daten, um sie vor dem Zugriff vor Dritten zu schützen und das Cracken der Informationen bei einem möglichen Datenverlust so schwer und teuer wie möglich zu machen.

Siehe dazu auch: Passwörter richtig speichern

(Richtige) Datenverschlüsselung ist kein einfaches Thema und birgt viele Fallstricke. Unser Team muss zwingend über entsprechende Experten verfügen / zugreifen können, um hier ein tragfähiges Konzept zu entwickeln und korrekt umzusetzen.

Kryptographie-Bibliotheken müssen auf Korrektheit geprüft werden. Ist hier ein Fehler im System, bricht unter Umständen das ganze System in sich zusammen und unsere ganze Arbeit ist vermeintlich kompromittiert.

Wir binden uns bei einer Eigenentwicklung nicht an einen externen Anbieter aber zu einem Teil an interne Mitarbeiter. Vertieftes Wissen in den Bereichen Datensicherheit, Verschlüsselungstechnologien etc. ist kein Standardwissen eines Softwareentwicklers, sondern es bedarf in der Regel eines Spezialisten, um diese Themen korrekt umzusetzen. Ein Spezialist alleine reicht nicht, da wir immer davon ausgehen müssen, dass der Kollege irgendwann mal nicht greifbar sein wird, wenn wir auf seine Expertise angewiesen sind. Hier braucht man mindestens einen zweiten Experten, der die Arbeit an der Stelle übernehmen kann. Experten auf diesem Gebiet sind nicht nur rar gesät, sondern auch entsprechend teuer. Ob und in wie weit sich ein Unternehmen dies leisten kann oder will sei dahingestellt.

Schlussendlich darf nicht unerwähnt bleiben, dass die meisten Hacker-Angriffe und Datendiebstähle gar nicht von Außen kommen, sondern aus dem Inneren der Unternehmens selbst (http://www.cio.de/a/die-groesste-gefahr-kommt-von-innen,2921119).

Fraglich ist, ob wir in der Lage sind, die internen Sicherheitsmaßnahmen so weit auszubauen, um zu verhindern, dass wir einfach Opfer eines unzufriedenen oder fehlmotivierten eigenen Mitarbeiters werden.

FIdM-Dienstanbieter haben (hoffentlich) entsprechende Maßnahmen per se vorgesehen, da es mit ihr Kerngeschäft ist, ihre Daten zu schützen.

Vorteil
+ volle Kontrolle über Daten
+ keine Abhängigkeit von externen Diensten

Nachteil
– eigene Experten im Team nötig
– technologisch Anspruchsvoll
– erhöhte Sicherheitsmaßnahmen nötig

Der Zwitter: Federated Idenetity Management On-Premise

Wollen wir unsere Daten nicht aus der Hand geben, trauen uns aber auch nicht zu, selber ein System entwickeln, warten und für die Sicherheit des Systems über Jahre sorgen zu können, gibt es eine Alternative, die interessant sein kann: wir kaufen ein System von einem (vertrauensvollen) Anbieter hinzu und betreiben die Software in unserer eigenen IT-Landschaft (also On-Premise) selber.

Beispielsweise ist Microsofts Active Directory (AD) eine FIdM-Lösung, die man kaufen und selber betreiben kann.

Betreiben wir ein AD im Unternehmen, können wir unsere Anwendungen damit verkoppeln, so dass Benutzer für unsere Anwendungen nur ein Passwort benötigen und sogar die Vorteile von SSO nutzen.

Ein AD kann viel mehr als Benutzerkonten für Anwendungen zu verwalten, diese Aspekte wollen wir hier aber außen vor lassen.

Kaufen wir eine FIdM-Software ein, müssen wir ein paar Dinge beachten und im Vorfeld einige wichtige Fragen beantworten:

  • Ist der Anbieter vertrauensvoll?
    Wenn ja: was zeichnet ihn aus?
  • Ist der Anbieter schon lange im Geschäft und ist (finanziell) Gesund?
  • Gibt es eine Garantie für Updates der Software?
    Wenn ja: wie lange werden noch Updates für die Version garantiert?
  • Lässt sich die Software nahtlos in meine IT-Landschaft integrieren oder muss ich Systeme etablieren, die neu für mich sind?
    Beispiel: betreibe ich Windowsserver und muss jetzt Linux für die Software einsetzen?
    Betreibe ich eine Microsoft SQL-Server Datenbank und brauche nun zusätzlich eine Oracle Datenbank?
  • Habe ich im Hause Experten, die das System zuverlässig betreuen können?
    Falls nicht: wie aufwändig und teuer ist eine Ausbildung/Schulung?
  • Kann ich die Grundinstallation und Ersteinrichtung vom Anbieter zukaufen?

Die Liste ist nicht vollständig aber der Gedanke dahinter dürfte klar sein.

Sich für eine FIdM-Lösung zu entscheiden ist nicht einfach und sollte nicht leichtfertig getroffen werden.

Wichtig ist hier vor allem das Vertrauen zum Anbieter, dass keine geheimen Hintertüren eingebaut sind und Updates sowohl schnell, als auch zuverlässig Sicherheitslücken schließen.

Vorteil
+ Daten bleiben im Unternehmen
+ Updates kommen vom Anbieter

Nachteil
– Experten für die Software im Unternehmen nötig
– Zuverlässigkeit von Anbietern nur schwer überprüfbar

 

Fazit

Alle drei hier dargestellten Wege haben Ihren Reiz aber auch Ihre Tücken und Herausforderungen.

Eine Lösung, die pauschal alle Szenarien abdeckt und immer die richtige Wahl ist, gibt es nicht.

Deshalb kann ich auch keine Empfehlung aussprechen. Ich denke die beleuchteten Aspekte in diesem Artikel können aber jedem bei der Entscheidungsfindung helfen.

Genutzt habe ich in Projekten bereits alle Varianten.

Will ich eine Social-Media-Plattform aufbauen, dann macht es sicherlich Sinn, künftigen Benutzern die Anmeldung so einfach wie möglich zu machen, um sie nicht abzuschrecken und schnell auf mein System zu lassen. Entsprechend erlaube ich eine Anmeldung via Twitter oder Facebook, da ich davon ausgehen kann, dass meine Benutzer ebenfalls Nutzer dieser Dienste sein werden.

Schreibe ich spezialisierte Software für einen anderen Nutzerkreis, dann kann ich über OpenID oder eine Eigenentwicklung nachdenken.

Bin ich in einem Bereich unterwegs, in dem ich Software für ein großes Unternehmen entwickle, das bereits eine große IT-Landschaft hat, dann gibt es in der Regel bereits eine On-Premise Lösung zur Benutzerverwaltung, die man idealer Weise für die Authentifizierung verwendet und bekomme oft ein SSO direkt dazu.

 

tl;dr

Habe ich Experten im Haus, kann man über Eigenentwicklung nachdenken – sonst nicht.

Benutzt etablierte Lösungen. Kauft keine Exoten. Nutzt bestehende Systeme, falls vorhanden. Bildet Experten aus, falls ihr noch keine habt. Setzt erst Zukaufsysteme ein, wenn ihr sie auch beherrscht.

Datenverluste und Sicherheitslücken sind der Tot jeder Software. Verlorenes Vertrauen kann kaum zurückgewonnen werden.

Christian Aschoff

Christian Aschoff

Senior IT-Berater bei BROCKHAUS AG
Christian Aschoff ist bei der BROCKHAUS AG in der Individualentwicklung mit Microsoft-Technologien tätig. Darüber hinaus beschäftigt er sich mit übergreifenden Themen wie IT-Security, iOS-Entwicklung mit Mono und Unity 3D. Als jemand, dem Sicherheit am Herzen liegt, schreibt er für das blogHAUS hauptsächlich über Themen aus dem Bereich Security.
Christian Aschoff
<< Vorheriger Beitrag
Nächster Beitrag >>

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.