Erklären Sie einem 5-Jährigen die „anspruchsbasierte Authentifizierung“

Nun, nicht gerade für einen 5-Jährigen, aber bitte vermeiden Sie Schlagworte und Unternehmenssprache, wenn möglich.

Die anspruchsbasierte Authentifizierung scheint derzeit der letzte Schrei zu sein, aber ich konnte keine einfache und bodenständige Erklärung dafür finden, was es tatsächlich ist und wie es sich von dem unterscheidet, was wir jetzt haben (ich gehe davon aus, "was wir jetzt haben"). rollenbasierte Authentifizierung), welche Vorteile bietet die Verwendung usw.

@Marnix hat eine ziemlich gute Antwort, aber um sich vom technischen Aspekt zu entfernen:

Bei der anspruchsbasierten Authentifizierung geht es darum, zu definieren, wem Sie vertrauen, um genaue Informationen zur Identität zu erhalten, und immer nur die bereitgestellten Informationen zu verwenden. Mein Beispiel ist in einer Bar. Stellen Sie sich für einen Moment vor, Sie möchten ein Bier an der Bar trinken. Theoretisch sollte der Barkeeper Sie um einen Altersnachweis bitten. Wie beweisen Sie es? Nun, eine Möglichkeit ist, sich vom Barkeeper halbieren zu lassen und die Anzahl der Ringe zu zählen, aber es könnte einige Probleme damit geben. Die andere Möglichkeit besteht darin, Ihren Geburtstag auf ein Blatt Papier zu schreiben, das der Barkeeper genehmigt oder ablehnt. Die dritte Möglichkeit besteht darin, zur Regierung zu gehen, einen Ausweis zu erhalten und den Ausweis dann dem Barkeeper vorzulegen.

Einige mögen über die Idee lachen, Ihren Geburtstag nur auf ein Blatt Papier zu schreiben, aber dies geschieht, wenn Sie Benutzer innerhalb der Anwendung selbst authentifizieren, da es Sache des Barkeepers (oder Ihrer Anwendung) ist, dem Blatt Papier zu vertrauen . Wir vertrauen jedoch der Behauptung der Regierung, dass der Geburtstag auf dem Ausweis gültig ist und der Ausweis für die Person gilt, die das Getränk anfordert. In jeder Hinsicht ist es dem Barkeeper (oder der Anwendung) aufgrund des Vertrauens egal, wie die Authentifizierung erfolgt ist. Der Barkeeper weiß nichts über Sie außer Ihrem Geburtsdatum, denn das ist alles, was der Barkeeper wissen muss. Jetzt könnte der Barkeeper Informationen speichern, die er für wichtig hält, wie Ihr Lieblingsgetränk, aber die Regierung kümmert sich nicht darum (da dies nicht die maßgebliche Quelle ist).

Der Schlüssel zu CBA lautet: "Wer ist die maßgebliche Quelle der Identität?"

(Dies ist meine persönliche Einstellung dazu, andere können abweichen. Bitte posten Sie andere Standpunkte als separate Antworten.)

Bei der anspruchsbasierten Identität / Authentifizierung / Autorisierung geht es darum, die Verwaltung von Benutzerberechtigungen und die Benutzeranmeldung von einer (Web-) Anwendung zu trennen, indem Authentifizierung / Autorisierung in einen separaten (Web-) Dienst umgewandelt wird.

Wenn ich beispielsweise zum ersten Mal zu einer Webanwendung mit aktiviertem Anspruch navigiere, wird mein Browser zu einem Anmeldedienst umgeleitet, dem er vertraut. Ich werde mich bei diesem Dienst authentifizieren (mithilfe der Windows-Authentifizierung, einer Smartcard oder was auch immer) und als Antwort ein "Token" zurücksenden, das der Browser an die Webanwendung zurücksendet. Jetzt überprüft die Webanwendung, ob das Token von ihrem vertrauenswürdigen Anmeldedienst digital signiert ist, und überprüft dann die "Ansprüche" im Token. Auf der Grundlage dieser Ansprüche entscheidet die Anwendung, welche Funktionalität dem Benutzer angeboten wird.

Die Ansprüche enthalten fast immer die Identität des Benutzers. Oft gibt es auch autorisierungsbezogene Ansprüche ("Dieser Benutzer kann Verkaufsdaten anzeigen, aber nicht aktualisieren") und manchmal auch andere Informationen ("Schuhgröße = 42").

Der entscheidende Punkt ist, dass die Anwendung weder weiß noch interessiert, wie der Benutzer authentifiziert wurde oder wie die Berechtigungen verwaltet werden: Sie verwendet nur die Informationen aus den Ansprüchen im signierten Token, um zu bestimmen, wer der Benutzer ist und / oder was der Benutzer kann sehen oder tun und / oder andere Informationen über den Benutzer.

(Ja, ich gehe hier von einem ziemlich intelligenten und gut informierten 5-Jährigen aus. :-)

Das folgende Beispiel aus der Praxis stammt aus einem Leitfaden zur anspruchsbasierten Identitäts- und Zugriffskontrolle (2. Ausgabe) .

Eine sehr bekannte Analogie ist das Authentifizierungsprotokoll, das Sie bei jedem Besuch eines Flughafens befolgen . Sie können nicht einfach zum Tor gehen und Ihren Reisepass oder Führerschein vorlegen. Stattdessen müssen Sie zuerst am Ticketschalter einchecken. Hier präsentieren Sie alle Anmeldeinformationen, die sinnvoll sind. Wenn Sie nach Übersee gehen, zeigen Sie Ihren Reisepass. Bei Inlandsflügen legen Sie Ihren Führerschein vor. Nachdem der Agent überprüft hat, ob Ihr Bildausweis mit Ihrem Gesicht übereinstimmt ( Authentifizierung ), überprüft er Ihren Flug und überprüft, ob Sie für ein Ticket bezahlt haben ( Autorisierung ). Vorausgesetzt, alles ist in Ordnung, erhalten Sie eine Bordkarte, die Sie zum Gate bringen.

Eine Bordkarte ist sehr informativ. Gate-Agenten kennen Ihren Namen und Ihre Vielfliegernummer (Authentifizierung und Personalisierung), Ihre Flugnummer und Sitzplatzpriorität (Autorisierung) und vielleicht sogar noch mehr. Die Gate-Agenten haben alles, was sie brauchen, um ihre Arbeit effizient zu erledigen.

Es gibt auch spezielle Informationen auf der Bordkarte. Es ist im Barcode und / oder im Magnetstreifen auf der Rückseite codiert. Diese Informationen (z. B. eine Bordseriennummer) beweisen, dass der Pass von der Fluggesellschaft ausgestellt wurde und keine Fälschung ist.

Im Wesentlichen handelt es sich bei einer Bordkarte um eine unterschriebene Reihe von Ansprüchen der Fluggesellschaft gegen Sie . Es besagt, dass Sie zu einer bestimmten Zeit in einen bestimmten Flug einsteigen und auf einem bestimmten Sitzplatz sitzen dürfen. Natürlich müssen Agenten nicht sehr tief darüber nachdenken. Sie validieren einfach Ihre Bordkarte, lesen die Angaben darauf und lassen Sie in das Flugzeug einsteigen.

Es ist auch wichtig zu beachten, dass es mehrere Möglichkeiten gibt, die unterschriebenen Ansprüche zu erhalten, die Ihre Bordkarte sind. Sie können zum Ticketschalter am Flughafen gehen oder die Website der Fluggesellschaft nutzen und Ihre Bordkarte zu Hause ausdrucken. Den Gate-Agenten, die an Bord des Fluges gehen, ist es egal, wie die Bordkarte erstellt wurde. Es ist ihnen egal, welchen Emittenten Sie verwendet haben, solange die Fluggesellschaft ihm vertraut. Sie kümmern sich nur darum, dass es sich um eine authentische Reihe von Behauptungen handelt, die Ihnen die Erlaubnis geben, in das Flugzeug einzusteigen.

In der Software wird dieses Anspruchsbündel als Sicherheitstoken bezeichnet . Jedes Sicherheitstoken wird von dem Aussteller signiert, der es erstellt hat. Eine anspruchsbasierte Anwendung betrachtet Benutzer als authentifiziert, wenn sie ein gültiges, signiertes Sicherheitstoken eines vertrauenswürdigen Ausstellers vorlegen .

Bitten Sie ihn für einen 5-jährigen Jungen anzunehmen, dass er eine neue Schule besucht hat, indem Sie den Antrag seiner Eltern unterschreiben. Nach Genehmigung der Schulleitung für seinen Antrag erhält er eine Zugangskarte, die alle unten aufgeführten Informationen enthält, die wir als ANSPRÜCHE für den Eintritt in die Schule bezeichnen können.

1. NAME des JUNGEN ist BOB.
2. SCHULNAME IST MONTISSORI HIGH SCHOOL
3. KLASSE IST 8. STUFE

Am ersten Tag seiner Schule, als er die Schule betrat, wischte er seine Zugangskarte und die Tore öffneten sich, was bedeutet, dass er als einer der Mitarbeiter der Schule beansprucht wurde. Auf diese Weise ist er eine AUTHENTIFIZIERTE PERSON, die die Schule betritt.

Nachdem er seine Klasse erreicht hatte, benutzte er eine Zugangskarte, um in jede Klasse einzutreten, aber in der 8. Standardklasse öffneten sich die Türen, als er behauptete, vom 8. Standard zu sein.

In der Schule ist er nur AUTORISIERT, in seine Klasse einzutreten, da er jetzt den 8. Standard studiert. Und wenn er versucht, in den 6. Standard einzutreten, wird der Schullehrer ihn NICHT AUTORISIEREN.

So untechnisch wie möglich:

Wenn Sie etwas darüber beschreiben würden, wer Sie sind und was Sie sehen oder tun durften, wäre jedes dieser Dinge etwas, von dem Sie "behaupten", dass es wahr ist, und daher wäre jedes "Ding" auf dieser Liste ein " Anspruch".

Jedes Mal, wenn Sie jemandem etwas über sich erzählen oder "behaupten", dass Sie etwas sehen oder tun dürfen, geben Sie ihm Ihre Liste der Ansprüche. Sie werden bei einer Behörde überprüfen, ob Ihre Behauptungen wahr sind, und wenn dies der Fall ist, werden sie alles auf dieser Liste von Behauptungen glauben. Wenn Sie also behaupten, dass Sie Brad Pitt sind, heißt es in Ihrer Liste der Ansprüche, dass Sie Brad Pitt sind, und es wurde mit der Autorität überprüft, dass Ihre Behauptungen alle wahr sind - dann werden sie glauben, dass Sie Brad Pitt sind alles andere in dieser Liste.

Behauptung : Was Sie für wahr halten. Dies kann eine Information oder eine Beschreibung einer Berechtigung sein, die Sie angeblich haben. Das System, dem Sie Ihre Ansprüche vorlegen, muss nur verstehen, was der Anspruch ist / bedeutet, und sich bei der Behörde verifizieren lassen.

Autorität : Das System, das Ihre Liste von Ansprüchen zusammenstellt und unterschreibt und im Grunde sagt: "Nach meiner Autorität ist alles in dieser Liste wahr." Solange das System, das die Ansprüche liest, bei der Behörde überprüfen kann, ob die Signatur korrekt ist, wird alles in der Liste der Ansprüche als authentisch und wahr angesehen.

Nennen wir es auch nicht "anspruchsbasierte Authentifizierung", sondern "anspruchsbasierte Identität".

Etwas technischer:

In diesem Prozess authentifizieren Sie sich nun mithilfe eines Mechanismus (Benutzername / Passwort, Client-Geheimnis, Zertifikat usw.), der Ihnen ein Token gibt, das beweist, dass Sie der sind, für den Sie sich ausgeben. Anschließend tauschen Sie dieses Zugriffstoken gegen ein ID-Token. Bei diesem Vorgang wird Ihre Identität verwendet, um eine Liste von Ansprüchen zu finden und zu erstellen, diese zu unterschreiben und Ihnen dann ein ID-Token zurückzugeben, das alle Ihre Ansprüche enthält.

Je nach Implementierung überprüft die Ressource als Autorisierungsschritt Ihr ID-Token (Ansprüche) und prüft dann, ob Sie über die erforderlichen Ansprüche für den Zugriff auf diese Ressource verfügen.

Wenn beispielsweise in der Ressource "CastleBlack / CommandersTower" angegeben ist, dass "Sie Zugriff auf Castle Black haben und Lord Commander sein müssen, wird in Ihrer Liste der Ansprüche geprüft, ob diese beiden Dinge zutreffen.

Wie Sie sehen, können "Ansprüche" alles sein. Es kann eine Rolle sein, es kann eine Tatsache sein, es kann eine Flagge sein. Es ist nur eine Liste von Schlüssel-Wert-Paaren und der "Wert" ist optional. Manchmal geht es nur darum zu sehen, ob der Anspruch besteht:

claims : [
    {"type": "name", "value": "Jon Snow"},
    {"type": "home", "value": "Winterfell, The North, Westeros"},   
    {"type": "email", "value": "jon@nightswatch-veterans.org"},
    {"type": "role", "value": "veteran;deserter;"},
    {"type": "department", "value": "none"},    
    {"type": "allowEntry", "value": "true"},
    {"type": "access", "value": "castleblack;eastwatch;"}
]

Wenn sich Jon anmeldet und versucht, auf die oben beschriebene Ressource zuzugreifen, wird er abgelehnt, da er, obwohl er der ist, von dem er sagt, dass er er ist, und er Zugriff auf Castle Black hat, weder Lord Commander noch expliziter Zugriff auf ihn ist der Turm des Kommandanten und kann daher nicht implizit den Turm des Kommandanten betreten.

Insbesondere wäre "CastleBlack" wahrscheinlich ein [größerer] Bereich, und jeder Bereich wäre eine spezifische Erlaubnis, aber das ist eine andere Diskussion.

Wie jede Anwendung mit dem Zugriff umgeht, wird unterschiedlich sein, aber es werden Ansprüche verwendet, um dies zu tun.

Wenn man bedenkt, dass ein Anspruch ein Attribut ist, das etwas über den Benutzer aussagt (Name, Alter, ethnische Zugehörigkeit usw.), arbeiten Sie gegen einen Sicherheitstoken-Dienst, um diese Ansprüche zu validieren, und verwenden sie neben der Authentifizierung auch zur Autorisierung.

Der folgende Auszug stammt aus Wikipedia ( http://en.wikipedia.org/wiki/Claims-based_identity ) und ist die beste Analogie, die ich bisher gefunden habe

"Um das Konzept des Sicherheitstoken-Dienstes besser zu verstehen, betrachten Sie die Analogie eines Nachtclubs mit einem Portier. Der Portier möchte verhindern, dass minderjährige Gäste eintreten. Um dies zu erleichtern, fordert er einen Kunden auf, einen Führerschein und eine Krankenversicherungskarte vorzulegen oder eine andere Identifikation (das Token), die von einem vertrauenswürdigen Dritten (dem Sicherheitstoken-Dienst) ausgestellt wurde, z. B. der Provinz- oder staatlichen Fahrzeuglizenzabteilung, dem Gesundheitsamt oder der Versicherungsgesellschaft. Der Nachtclub wird somit von der Verantwortung für die Bestimmung des Benutzers entlastet Alter. Es muss nur der ausstellenden Behörde vertrauen (und natürlich selbst ein Urteil über die Echtheit des vorgelegten Tokens fällen). Nach Abschluss dieser beiden Schritte hat der Nachtclub den Benutzer erfolgreich in Bezug auf die Behauptung authentifiziert, von der er oder sie stammt gesetzliches Mindestalter für Alkoholkonsum.

In Fortsetzung der Analogie verfügt der Nachtclub möglicherweise über ein Mitgliedersystem, und bestimmte Mitglieder können regulär oder VIP sein. Der Portier könnte nach einem anderen Token fragen, der Mitgliedskarte, die einen weiteren Anspruch erheben könnte. dass das Mitglied ein VIP ist. In diesem Fall wäre die vertrauenswürdige ausstellende Behörde des Tokens wahrscheinlich der Club selbst. Wenn die Mitgliedskarte den Anspruch erhebt, dass der Benutzer ein VIP ist, kann der Club entsprechend reagieren und den authentifizierten Anspruch auf VIP-Mitgliedschaft in eine Erlaubnis umsetzen, z. B. dass der Benutzer im exklusiven Loungebereich sitzen und kostenlose Getränke erhalten darf. "