Argumente für eine anspruchsbasierte Identität

Ein wichtiger Teil Ihrer allgemeinen Sicherheitsstrategie für die Informationstechnologie muss berücksichtigen, wie Ihre Anwendung mit der Benutzeridentität umgeht. Insbesondere umfasst die Benutzeridentität im digitalen Sinne Informationen über einen Benutzer, die für Anwendungen zur Verwendung bereitgestellt werden. Der Begriff Benutzer ist hier leicht irreführend. Ein Benutzer muss keine tatsächliche Person sein, sondern kann auch ein anderes Gerät oder eine andere Anwendung sein. Nicht alle Strategien sind in Bezug auf Flexibilität und Auswahl in Bezug auf Erweiterbarkeit und Interoperabilität gleich. In diesem Artikel werde ich die anspruchsbasierte Identität als Strategie zur Adressierung der Benutzer- und Geräteidentität innerhalb und außerhalb Ihres Unternehmens erläutern.

Traditionell haben Benutzer einer Anwendung ihren Identitätsnachweis in Form eines Benutzernamens und eines Kennworts vorgelegt. Eine Anwendung überprüft dann mithilfe eines von vielen möglichen Mitteln, ob der Benutzer derjenige ist, von dem sie sagt, dass er sie ist, und zwar durch einen Prozess namens Authentifizierung (AuthN). Der nächste Schritt besteht häufig darin, zusätzliche Informationen über den Benutzer abzurufen, z. B. die ihm zugewiesenen Rollen, um zu überprüfen, ob der Benutzer Zugriff auf bestimmte Anwendungsfunktionen hat oder nicht.

Dieser Vorgang wird als Autorisierung (AuthZ) bezeichnet. Sobald ein Benutzer authentifiziert und autorisiert ist, kann die Anwendung weiterhin alle anderen verfügbaren Informationen über den Benutzer verwenden, um die beabsichtigte Funktionalität auszuführen. Beispielsweise kann eine Anwendung E-Mail-Benachrichtigungen an einen Benutzer senden, wenn dieser die E-Mail-Adresse kennt, oder eine Startseite personalisieren, indem der Name des angemeldeten Benutzers angezeigt wird.

Entscheidung über die richtige Benutzeridentitätsstrategie

Die meisten Geschäftsanwendungen erfordern eine digitale Benutzeridentität. Bei der Auswahl der richtigen Technologie zur Übermittlung von Benutzeridentitäten innerhalb einer bestimmten Anwendung müssen Sie berücksichtigen, wie die Anwendung verwendet wird und wo sie sich befindet, welche Identitätsinformationen erforderlich sind und welche Auswirkungen dies auf Ihre IT-Infrastruktur und Ihre Mitarbeiter haben würde.

Für Anwendungen, die nur im Intranet Ihres Unternehmens verfügbar sind und auf die ausschließlich Mitarbeiter innerhalb derselben Sicherheitsgrenze oder Domäne zugreifen, scheint die Lösung zunächst unkompliziert zu sein. Technologien wie Verzeichnisdienste erleichtern die Bereitstellung einer einmaligen Anmeldung für alle Anwendungen im internen Netzwerk Ihres Unternehmens. Anwendungen können den Verzeichnisdienst einfach nach zusätzlichen Informationen abfragen, die bei der ersten Anmeldung des Benutzers nicht angegeben wurden.

Für Anwendungen, die ausschließlich mit dem Internet verbunden sind, besteht die Lösung möglicherweise darin, einfach eine formularbasierte Authentifizierung zu verwenden und Benutzernamen und Kennwörter sicher in einer Datenbank zu speichern, zusammen mit möglicherweise einigen Personalisierungsinformationen als Teil des Benutzerprofils.

Heraklit von Ephesus glaubte, dass „nichts Bestand hat als sich zu ändern“. Ein anderer, bekannter Begriff ist „Veränderung ist die einzige Konstante“. Man kann sagen, dass dies sicherlich für die Technologiebranche gilt.

Von modernen Anwendungen kann nicht mehr erwartet werden, dass sie einfach Integrationspunkte durch Batch-Datenextrakte und -importe bereitstellen. Für den heutigen Benutzer müssen Anwendungen nahezu Echtzeit-Integrationsfunktionen unterstützen. Von Anwendungen wird erwartet, dass sie zusätzlich zu den Benutzeroberflächen APIs für konsumierende Entitäten bereitstellen. Dies spricht jedoch dafür, wie eine Anwendung verwendet werden könnte. Wo eine Anwendung ausgeführt wird und wer sie verwendet, kann sich ebenfalls ändern.

Anwendungen und ihre Endpunkte sollten so gesichert werden, dass sie nicht nur den Anforderungen der Benutzer von heute, sondern auch den Benutzern von morgen gerecht werden, wenn sich die Geschäftslandschaft ändert. Die IT muss vorbereitet sein oder riskieren, in ihrer Fähigkeit, das Geschäftstempo zu unterstützen, ins Hintertreffen zu geraten.

Was ist zum Beispiel, wenn Ihr Unternehmen eine Fusion oder Akquisition durchführt oder eine Partnerschaft mit einer anderen Organisation eingeht und nun den Zugriff auf Ihre internen Anwendungen auf diese neue Organisation ausweiten muss? Wie werden Sie Identitäten freigeben, wenn Ihre Organisation Windows verwendet und Ihr Partner Linux oder Macs verwendet? Was wäre, wenn Ihre Geschäftsleitung beschließen würde, Software as a Service (SaaS) als Geschäftsstrategie zu integrieren? Wie werden Ihre Kunden auf die Software zugreifen? Wie greifen die Kunden Ihrer Kunden auf die Software zu? Was ist, wenn ein Produktmanager entscheidet, dass Ihre Anwendungen auch Facebook-Konten unterstützen sollen? Was ist, wenn Ihr CXO beschließt, eine langfristige Strategie zur Verlagerung Ihrer internen Anwendungen in die Cloud umzusetzen?

Nehmen wir für einen Moment an, dass die oben genannten Szenarien zu echten Anforderungen für eine unvorbereitete IT-Organisation werden. Ohne eine flexible Identitätsstrategie bemüht sich die Organisation, sich anzupassen. Vielleicht beginnt es damit, zuerst die betroffenen Anwendungen zu ändern, um die neuen Identitätsszenarien zu unterstützen, die vom Unternehmen gefordert werden.

Es wird schnell klar, dass die vorhandenen Anwendungen auf plattformbasierten Sicherheitsfunktionen basieren, die eng mit dem Anwendungscode verknüpft sind und nicht so einfach erweiterbar sind. Möglicherweise wird ein benutzerdefinierter Sicherheitsauthentifizierungsansatz durch die Entwicklung als kurzfristige „Problemumgehung“ entwickelt, bei der mehrere Authentifizierungsmechanismen auf nicht standardmäßige Weise zusammen gehackt werden.

Diese Problemumgehungen können zu unbeabsichtigten Sicherheitslücken führen, was das Sicherheitsteam des Unternehmens sehr bestürzt. Die Produktion muss auch unterstützt werden, während diese neue Sicherheitsinfrastruktur eingerichtet wird. Benutzerdefinierte Sicherheitsimplementierungen, die nicht auf bekannten und bewährten Industriestandards und -protokollen basieren, sind in der Regel nicht erweiterbar oder interoperabel. Solche Implementierungen führen zu Albträumen bei der Unterstützbarkeit und beeinträchtigen die IT-Produktivität.

Data Governance in Bezug auf Identitätsinformationen ist häufig ein nachträglicher Gedanke unter dem Druck des Zeitplans. Benutzer müssen möglicherweise mit mehreren Kontospeichern umgehen, und die Fragmentierung der Identität nimmt zu. Diese benutzerdefinierten Sicherheitsansätze können zu Identitätsspeichern führen, die für Identitätsverwaltungsprodukte nicht sichtbar sind. Letztendlich wird wertvolle Zeit für die Entwicklung und Veröffentlichung neuer Anwendungsfunktionen benötigt, die einen geschäftlichen Mehrwert bieten.

Querschnittsthemen wie Sicherheit erfordern die Einbeziehung und Beteiligung von IT-Infrastruktur-, Betriebs- und Entwicklungsgruppen. Es sollte sorgfältig überlegt werden, eine kohärente Strategie für den Umgang Ihrer Anwendungen mit der Benutzeridentität zu formulieren, und es sollten einige Investitionen in die entsprechende Infrastruktur getätigt werden.

Als häufig angeforderte Funktion für Anwendungen abstrahiert der Begriff „Single Sign-On“ nicht triviale Herausforderungen, und der Aufwand für die Implementierung wird häufig unterschätzt. Es gibt viele Möglichkeiten, Single Sign-On zu implementieren. Sie können jedoch nicht davon ausgehen, dass Sie immer die Kontrolle über die Anwendungen haben, für die Ihre Benutzer Single Sign-On benötigen, und Sie können auch nicht davon ausgehen, dass Ihre Anwendungen immer in Ihrer Netzwerkumgebung ausgeführt werden.

Argumente für eine anspruchsbasierte Identität

Welche Strategie können Sie also einführen, damit Ihre IT-Infrastruktur und -Anwendungen in Bezug auf die Benutzeridentität flexibel bleiben und sich in einem Tempo ändern können, das immer noch den gewünschten Geschäftswert bietet, pünktlich und im Rahmen des Budgets? Gibt es eine Option, die für jede Situation geeignet ist (vor Ort, zwischen Organisationen oder in der Cloud)? Was würde uns dieser Identitätsutopie näher bringen, damit die Harmonie zwischen Business und IT angesichts solcher Herausforderungen im Gleichgewicht bleibt?

Ein Ansatz besteht darin, eine Identitätsstrategie für Ihre Anwendungen zu integrieren, die auf allgemein anerkannten Industriestandards basiert, die für die Zusammenarbeit über Plattform- und Organisationsgrenzen hinweg konzipiert sind. Diese Standards haben auch eine breite und breite Unterstützung von Anbietern in Bezug auf Produktimplementierungen.

Mit einer solchen Strategie können Unternehmen von der Dynamik und Konvergenz profitieren, insbesondere wenn es um Infrastruktur wie Sicherheit geht, und können leicht von den Investitionen anderer in diesem Bereich profitieren. Dies nennt man Fortschritt.

Hier kommt die anspruchsbasierte Identität ins Spiel.

Im Allgemeinen bezieht sich die anspruchsbasierte Identität auf eine Reihe von Abstraktionen und einen konsistenten Ansatz für die Identitäts- und Zugriffskontrolle, mit deren Hilfe einige der Herausforderungen bewältigt werden können, denen moderne Anwendungen gegenüberstehen, z. B. die Unterstützung der einmaligen Anmeldung zwischen mehreren Organisationen, unabhängig davon, ob es sich um eine Anwendung handelt Vor Ort, in der Cloud oder in einem Hybrid-Hosting-Modell gehostet.

Ein zentrales Konzept ist der Begriff eines Anspruchs:

  • Eine Aussage, die ein Thema, wie eine Person oder Organisation, dazu oder zu einem anderen Thema macht.
  • Eine Darstellung von etwas über einen Benutzer, wie E-Mail, Rollenmitgliedschaft oder Lieblingseis.
  • Ausgestellt von einem Schadenanbieter, kurz Emittent genannt. Ein Identitätsanbieter (IdP) ist eine Art Anspruchsanbieter, der Benutzeranmeldeinformationen validieren und Ansprüche ausstellen kann.

Wie anspruchsbasierte Identität funktioniert

Die auf Ansprüchen basierende Identität beruht auf expliziten Vertrauensbeziehungen, die zuerst zwischen den Antragstellern und den vertrauenden Parteien hergestellt werden müssen. Vertrauensperson (RP) ist ein Begriff, der sich auf eine Anwendung oder ein Gerät bezieht, die bzw. das sich auf Ansprüche auf Benutzeridentität und Zugriffskontrolle stützt. Eine vertrauende Partei akzeptiert Ansprüche eines Emittenten nur dann, wenn sie dem Emittenten oder einem anderen Emittenten in der Vertrauenskette vertraut.

Ansprüche werden an vertrauende Parteien in Form eines Sicherheitstokens gesendet, das in einer beliebigen Anzahl von Formaten dargestellt werden kann, z. B. in der XML-basierten Security Assertion Markup Language (SAML) oder im Simple Web Token (SWT). Software, die als Security Token Service (STS) bezeichnet wird und normalerweise eine Softwarekomponente eines Ausstellers ist oder einem Aussteller gehört, ist für die Verarbeitung von Tokenanforderungen von vertrauenden Parteien verantwortlich.

Ein STS packt einen oder mehrere Ansprüche in ein Sicherheitstoken, signiert es kryptografisch und sendet es an eine vertrauende Partei, die auf dem Kabel verschlüsselt ist. Wenn eine vertrauende Partei das Token erhält, überprüft sie die Tokensignatur und verwendet, falls gültig, die Ansprüche für zusätzliche Entscheidungen, die sie möglicherweise durchführen muss, wie z. B. Autorisierungsprüfungen oder Personalisierung.

Aber was veranlasst eine vertrauende Partei, zunächst ein Sicherheitstoken anzufordern?

Mit einem auf Ansprüchen basierenden Ansatz müssen sich Anwendungen oder vertrauende Parteien nicht mehr darum kümmern, die Verantwortung für die Authentifizierung von Benutzern, die Verwaltung von Kennwörtern, die Bereitstellung von Mechanismen zum Zurücksetzen von Kennwörtern usw. zu übernehmen. Viele dieser Verantwortlichkeiten werden an eine externe Stelle ausgelagert, z ein Anspruchsanbieter.

Hier ist ein typischer Ablauf für die Authentifizierung eines Benutzers in einer anspruchsfähigen Webanwendung:


  1. Ein Benutzer versucht, über einen Browser auf eine anspruchsfähige Webanwendung zuzugreifen.
  2. Die Anwendung prüft, ob ein spezielles HTTP-Cookie vorhanden ist. Wenn es nicht gefunden wird, wird der Browser des Benutzers unter Verwendung bekannter Protokolle an seinen vertrauenswürdigen Aussteller umgeleitet, um die Authentifizierungsdetails zu verarbeiten.
  3. Abhängig von den konfigurierten Authentifizierungsmechanismen und den Besonderheiten der Authentifizierungsanforderung authentifiziert sich der Aussteller automatisch bei einem Identitätsspeicher, fordert den Benutzer zur Eingabe eines Heimatbereichs auf oder fordert den Benutzer zur Eingabe seiner Anmeldeinformationen auf.
  4. Sobald der Benutzer vom jeweiligen Aussteller authentifiziert wurde, erstellt der Aussteller ein Sicherheitstoken mit einer Reihe von Ansprüchen an den Benutzer.
  5. Über den Browser des Clients sendet der Aussteller das Sicherheitstoken an die Anwendung.
  6. Die Anwendung überprüft das Token und geht, da sie dem Aussteller vertraut, davon aus, dass der Benutzer authentisch ist, und richtet eine Sitzung mit dem Client-Browser ein. Beachten Sie, dass es weiterhin Sache der Anwendung ist, zusätzliche Berechtigungsprüfungen für die vorgelegten Ansprüche durchzuführen, um zu entscheiden, ob der Benutzer Zugriff auf bestimmte Funktionen hat (z. B. die Überprüfung auf einen Rollenanspruch „Manager“).

Sobald ein Benutzer ein Sicherheitstoken von einem Aussteller erhalten hat, kann er das Sicherheitstoken für den Zugriff auf andere Anwendungen von vertrauenswürdigen Parteien nutzen, die dem Aussteller vertrauen, und so eine einmalige Anmeldeerfahrung erzielen. Ich habe vorhin eine Emittenten-Vertrauenskette erwähnt.

Dies ist insofern ziemlich mächtig, als selbst wenn die vertrauende Partei dem Aussteller des Sicherheitstokens nicht direkt vertraut, solange sie einem Aussteller vertraut, der dem Aussteller dieses Sicherheitstokens vertraut, alles funktioniert. Dies wird als Identitätsverbund bezeichnet und ermöglicht die einmalige Anmeldung über Bereiche hinweg, die unterschiedliche Organisationen und Sicherheitsgrenzen repräsentieren.

Ihr Aussteller kann nicht nur Sicherheitstoken ausstellen, sondern auch Token von anderen Emittenten akzeptieren, denen er vertraut.

Dies funktioniert so, dass der Aussteller Remotebenutzer umleitet, um sich zuerst bei ihrem eigenen Aussteller zu authentifizieren. Sobald der Browser ein Token von seinem Heimatbereich erhalten hat, wird sein Token Ihrem Aussteller angezeigt, der das Token akzeptiert und seinerseits ein neues Token für Ihre Anwendung ausstellt. Bei diesem Token-Austausch wird häufig ein Satz von Ansprüchen in den Satz von Ansprüchen umgewandelt, den Ihre vertrauende Partei erwartet. Ihr vertrauenswürdiger Aussteller wird in diesem Szenario zu einem so genannten Verbundanbieter.

Auf diese Weise bündeln Sie die Sicherheit über Unternehmensgrenzen hinweg. Wenn Sie beispielsweise einfach eine vertrauenswürdige Beziehung zwischen dem Aussteller Ihrer Anwendung und dem Aussteller Ihres Partners herstellen, können Sie den Zugriff auf Ihre Anwendung auf einfache Weise für die Benutzerbasis Ihres Partners aktivieren. Die Anwendung muss sich überhaupt nicht ändern, lediglich eine kleine Konfiguration auf Infrastrukturebene basierend auf einer vereinbarten Sicherheitsrichtlinie.

Fazit

Indem wir Anwendungsansprüche bewusst machen, die Verantwortung für die Authentifizierung von Benutzern aus Anwendungen entfernen und nur einen kleinen Teil der unterstützenden IT-Infrastruktur einrichten, erhalten wir Folgendes:

  • Anwendungssicherheitsarchitekturen, die hochflexibel, konfigurierbar und an die sich ändernden Anforderungen des Unternehmens angepasst sind
  • Vereinfachte Anwendungsarchitekturen, da Anwendungen sich nicht mehr mit benutzerdefinierten Authentifizierungsmechanismen befassen oder benutzerdefinierte Identitätsspeicher verwalten müssen
  • Anwendungen, die auf Codeebene nicht geändert werden müssen, um zusätzliche Benutzerbasen aufgrund von Fusionen und Übernahmen oder neu gegründeten Partnerschaften zu unterstützen
  • Glücklichere Benutzer, da Benutzer sich nicht mehr mehrere Kennwörter merken oder Informationen in mehreren Anwendungen erneut eingeben müssen
  • Interoperable Sicherheit basierend auf allgemein anerkannten Standards
  • Anwendungsarchitekturen, die Cloud-fähig sind, wenn es um digitale Identität geht, und die einfach erweitert werden können, um Online-Identitätsanbieter zu unterstützen

Unternehmen, die daran interessiert sind, Schritte in Richtung einer anspruchsbasierten Identität zu unternehmen, und deren Geschäftsstrategie die in diesem Artikel beschriebene Flexibilität in Bezug auf die Benutzeridentität erfordert, können schrittweise Schritte in Richtung einer anspruchsbasierten Identität unternehmen. Beispielsweise können neue Anwendungsentwicklungsbemühungen beginnen, anspruchsbasierte APIs (die abwärtskompatibel mit vorhandenen Authentifizierungsmechanismen sind) zu nutzen, bis sie bereit sind, ihre Identitätsinfrastruktur zu verschieben, um künftig Verbundidentitätsszenarien zu berücksichtigen. Änderungen an vorhandenen Systemen sollten im Hinblick auf den Return on Investment bewertet werden, wobei die spezifischen organisatorischen Umstände im Zusammenhang mit neuen Funktionsanforderungen im Vergleich zu den Kosten für Support und Wartung nicht standardmäßiger Sicherheitsmechanismen zu berücksichtigen sind.

Von Michael Papasevastos

Michael ist Senior Architect bei Geneca, einem in Chicago ansässigen Unternehmen für kundenspezifische Softwareentwicklung. Er verfügt über mehr als 17 Jahre Erfahrung in der IT-Branche.



© Copyright 2021 | pepebotifarra.com