Attributzertifikate als Alternative zum zentralen IAM

19.10.2022

Zugangsberechtigungen sind ein zentraler Bestandteil vieler Anwendungen, denn in der Regel werden Daten verarbeitet, die es zu schützen gilt. Manches darf nicht einmal öffentlich einsehbar sein – mindestens aber dürfen die Daten nur durch bestimmte Personen verändert werden.

Um einen kontrollierten Zugang zu ermöglichen, nutzt man in der Regel ein Identity and Access Management, kurz IAM. Ein gängiger Vertreter ist z.B. Keycloak, welches standardmäßig RBAC zur Verwaltung nutzt.

Nehmen wir als Beispiel mal einen Webshop her: hier müssen Produkte verwaltet, sowie Bestellungen angenommen und abgerechnet werden. Das wird aber durch unterschiedliche Personen erledigt.

Was ist RBAC*?

Wer bereits mit Berechtigungen im Softwareumfeld zu tun hatte, wird mit ziemlicher Sicherheit ein zentral gesteuertes, rollenbasiertes Modell gesehen haben. RBAC steht hier somit auch für „Role Based Access Control“. Dieser klassische Ansatz definiert eine Menge an Rechten (in unserem Beispiel etwa Schreibrechte auf Produktbeschreibungen oder Löschrechte für Bestellungen). Diese Rechte sind dann oft in Rollen zusammengefasst (z.B. könnte die Rolle Produktmanager Lese, Schreib- und Löschrechte auf Produkte kombinieren). Rollen können dann gezielt Benutzern oder Benutzergruppen zugeordnet werden.

Versucht jetzt Benutzer Tom ein Produkt zu löschen, muss ich aus meiner Anwendung heraus mit dem IAM kommunizieren und abfragen, ob dem Benutzer das passende Recht zugeordnet ist. Ist das IAM Teil der Hauptanwendung, ist das ein durchaus valider Ansatz. Je weiter weg allerdings das IAM von der verarbeitenden Anwendung entfernt ist, desto komplexer und fehleranfälliger wird das System. Häufige Berechtigungsanfragen erzeugen zudem auch eine Auslastung im Netzwerk. Und sollte das IAM ausfallen, geht in der Anwendung gar nichts mehr.

Attributzertifikate

Attributzertifikate bieten hier einen dezentralen Ansatz. Melde ich mich mit einem Zertifikat an der Webshopverwaltung an, dann muss die Anwendung nur die Gültigkeit des Zertifikats validieren. Dazu braucht es nur das übergeordnete Unternehmenszertifikat, welches lokal vorgehalten werden kann. Eine Kommunikation mit einem anderen System ist nicht notwendig.

Anschließend können wir die im Zertifikat hinterlegten Attribute nutzen, um zu ermitteln, ob die geplante Aktion für den Benutzer erlaubt ist. Der Inhalt der Attribute ist dabei für den eigenen Kontext frei zu definieren und kann unterschiedlichste Informationen über den Benutzer beinhalten, z.B.:

  • Abteilungen oder Rollen
  • erlaubte Aktionen, wie lesen oder schreiben
  • zugeordnete Produktkategorien

Wir könnten also prüfen, ob der Benutzer Schreibrechte auf Produkt X hat und dann mit der Aktion fortfahren.

Zugangskarte ermöglicht Autorisierung
Attribute in dem Zertifikat ermöglichen Autorisierung

Wie kann man darauf zugreifen?

Zuerst einmal muss natürlich das Zertifikat zur Anwendung übertragen werden. Dabei müssen wir unterscheiden: für die allgemeine Anmeldung an einem System (um also herauszufinden, das der Benutzer „Tom“ ist) braucht man ein Public Key Certificate (PKC), für die anschließende Zugriffskontrolle dann das Attribute Certificate (AC). Auch das AC ist aber signiert und kann somit validiert werden.

Im Java-Umfeld bietet sich (wieder einmal) BouncyCastle an, um mit dieser Art von Zertifikaten umzugehen:

https://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/asn1/x509/AttributeCertificate.html

Hier findet sich auch ein Beispiel, wie mit diesen Klassen gearbeitet werden kann:

https://github.com/bcgit/bc-java/blob/master/misc/src/main/java/org/bouncycastle/jcajce/examples/AttrCertExample.java

Dazu sei aber gesagt, dass die Verbreitung der Nutzung dieses Ansatzes anscheinend recht gering ist – zumindest lässt sich bisher wenig Material dazu finden und gerade in Verbindung mit gängigen Frameworks (z.B. Spring) wird es dünn.

Nachteile

Anpassungen an den ACs, beispielsweise bei Zuweisung einer neuen Rolle, erfordern eine Neuausstellung des Zertifikats und es muss dann dem Benutzer wieder zugänglich gemacht werden. Prinzipiell ist es aber genauso möglich, die ACs zentral bei Bedarf von einem System abzufragen – mit allen Konsequenzen wie beim klassischen Ansatz.

Sollte ein AC einmal vorzeitig (also vor dem eingespeicherten Ablaufdatum) seine Gültigkeit verlieren, ist Vorsicht geboten. Das kann der Fall sein, wenn ein Mitarbeiter beispielsweise das Unternehmen verlässt. In diesem Fall muss ich der Anwendung mitteilen, dass dieses Zertifikat nicht mehr akzeptiert werden darf – das Stichwort lautet hier „Revoke list“.

 

* Abgrenzung ABAC:

Prinzipiell lässt sich sowohl mit einem zentralen als auch mit einem dezentralen IAM Ansatz RBAC sowie ABAC (attribute based access control) umsetzen. Da das aber nochmal ein eigener Beitrag wäre, gehe ich hier nicht weiter darauf ein.

Zurück zur Übersicht

2 Kommentare zu “Attributzertifikate als Alternative zum zentralen IAM

  1. Hallo Jochen,

    das ist eine spannende Frage! Tatsächlich sehe ich beide Standards sehr nah beieinander und JWT hat hier definitiv den Vorteil, bereits weitgehend akzeptiert zu sein.

    Im Gegensatz zum JWT ist es bei einem Attributzertifikat aber leichter möglich, mit Revokelists zu arbeiten. Wenn die JWTs aber ohnehin nur eine kurze Gültigkeit besitzen, spielt das in der Realität keine allzu große Rolle.

    Interessanterweise ist der RFC5755 sogar älter als sein JWT Pendant (RFC7519), kam aber nicht ansatzweise so gut in der Umsetzung an. Das hat sicher auch etwas mit der Komplexität von x509 im Vergleich zu JSON zu tun.

    Viele Grüße
    Jan

  2. Hallo Jan!

    Ich verstehe noch nicht ganz den Unterschied zu einem signierten JWT Access Token, wie es z.B. bei OAuth 2 verwendet wird. Oder ist ein solches Token ein Attributzertifikat?

    Viele Grüße
    Jochen

Kommentar verfassen

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

*Pflichtfelder

*