privacyIDEA Workshop – Teil 3 privacyIDEA mit Policies präzise steuern

Im dritten Teil der Workshop-Reihe zu privacyIDEA zeigen wir, wie man mit Policies das Verhalten bei der Authentifizierung oder bei der Verwaltung von Token durch Administratoren oder Helpdesk-Benutzer regelt. Oder wie man mit den Richtlinien die Berechtigungen der normalen Benutzer im Selfservice-Portal steuert.

In den ersten beiden Teilen unseres privacyIDEA-Workshops haben wir ein privacyIDEA-System installiert und einen TOTP-Token ausgerollt und dann mit FreeRADIUS ein VPN-System angebunden.

Im dritten Teil wollen wir uns eine zentrale Komponente von privacyIDEA anschauen, die es ermöglicht, das System in unterschiedlichen, komplexen Szenarien einzusetzen: Die privacyIDEA Policies oder Richtlinien. Mit ihnen kann der Administrator das Verhalten bei der Authentifizierung oder bei der Verwaltung von Token durch Administratoren oder Helpdesk-Benutzer regeln oder die Berechtigungen der normalen Benutzer im Selfservice-Portal steuern.

Policies gelten in einem „Scope“, werden unter bestimmten „Bedingungen“ angewendet und erzeugen eine bestimmte „Aktion“. Wir schauen uns direkt die wichtigen Scopes an.

Version 3.11 verfügbar

Passkeys zur sicheren Anmeldung in privacyIDEA

Die Scopes – der Geltungsbereich

In privacyIDEA gibt es verschiedene Geltungsbereiche für Richtlinien. Diese sind „admin“, „user“, „auth (authentication)“, authz (authorization)“, „webui“, „enrollment“ und „register“. Diese werden wir uns nun in den folgenden Abschnitten im Detail ansehen.

Admin- und User-Policies zur Steuerung von Nutzerrechten

Die Scopes „admin“ und „user“ regeln die Aktionen, die ein Administrator oder ein Benutzer in privacyIDEA durchführen darf. Ein „Administrator“ ist dabei ein Account, der prinzipiell Dinge am System durchführen kann und ebenfalls Token für anderen Benutzer verwalten darf.

Ein Benutzer ist wiederum ein Account, der prinzipiell nichts am System ändern darf sondern dem es nur erlaubt ist, Aktionen auf seinen eigenen Token durchzuführen.

Nach der Installation haben wir in Teil 1 des Workshops einen ersten Administrator angelegt. Dieser darf erst mal so lange alles, bis die erste Policy im Scope „admin“ die Rechte von Administratoren regelt. Sehr einfache Installation können durchaus mit einem einzelnen, allmächtigen Admin-Account ohne jegliche „admin“-Policies auskommen. Die admin-Richtlinien erlauben es aber auch komplexe Abstufungen der Berechtigungen zu definieren, so dass sich Rollen wie „Superuser“, „Operator“ oder „Helpdesk“ abbilden lassen.

privacyIDEA Workshop – Teil 1

So geht Mehr-Faktor-Authentifizierung mit Open Source

Administrative Realms vorbereiten

Administrative Realms machen alle Benutzer eines Realms zu administrativen Accounts. Hierzu editieren wir auf der Kommandozeile die Datei /etc/privacyidea/pi.cfg in der folgenden Zeile:

Diese Zeile definiert Benutzer-Realms in privacyIDEA, die von privacyIDEA zukünftig als administrative Realms behandelt werden. Es handelt sich dabei um eine Python Liste.

Den Realm „helpdesk“ werden wir später noch im WebUI anlegen.

Der Eintrag „(?#internal admins)“ ist ein regulärer Ausdruck für einen leeren String. Den Sinn dahinter betrachten wir gleich.

Wenn wir die Datei geändert haben, speichern wir sie ab und starten den Apache2 neu, damit die Konfigurationsdatei neu eingelesen wird.

Helpdesk-Benutzer aus einer AD-Gruppe lesen

In unserem Fall werden wir die Helpdesk-Benutzer ebenfalls im AD finden, und zwar in einer Security-Gruppe „MFA-Helpdesk“.

Dazu müssen wir erst wieder einen Resolver anlegen. Prüfen Sie ggf. hierzu den ersten Teil dieser Workshopreihe, in dem wir auch einen Resolver und Realm angelegt haben.

• Name: security-insider-helpdesk

• URL des Domaincontrollers

• TLS 1.2

• TLS verifizieren ausschalten

• BINDDN und BIND-Passwort eines Service Accounts

• Attribute-Mapping „Active Directory vorbelegen“.

Um nun ausschließlich die Helpdesk-User zu erhalten, müssen wir einen Filter auf die Gruppenmitgliedschaft setzen. Das machen wir im „Suchfilter“ mit dem Eintrag:

Und auch hier erzeugen wir nun schließlich den Realm mit dem gerade eben angelegten Resolver. Dies tun wir unter Konfiguration → Realms mit dem Realm-Name „helpdesk“ und dem zugehörigen Resolver „security-insider-helpdesk“.

Wenn Sie sich als „superuser“ nun im Hauptmenü unter „Benutzer“ alle Benutzer anzeigen lassen, können sie linker Hand zwischen den beiden Realms „sec-ins“ und „helpdesk“ umschalten.

Der allmächtige Superuser

Nun trennen wir die Berechtigungen für den superuser und die Helpdesk Benutzer.

Wir benötigen einen Administrator, der alles im System machen darf. Um wirklich alle Berechtigungen zu erhalten, müsste man in privacyIDEA viel klicken. Dabei helfen uns die Policy-Templates, die zentral in Github definiert sind.

Admin-Policies

In den Bedingungen geben wir bei Administrator nun noch den Namen unseres Administrators an „superuser“, so dass sich all diese Rechte genau auf unseren initialen Administrator beziehen.

Bei Admin-Realm wählen wir den Eintrag „(?#internal admins)“ aus. Dies stellt sicher, dass sich diese Richtlinie eben tatsächlich nur auf einen Benutzer bezieht, der den Namen „superuser“ hat und dessen Realm-Anteil ein leerer String ist. Würden wir den Admin-Realm als Bedingung leer lassen, so würde sich diese Policy auf alle Accounts beziehen, deren Name „superuser“ ist – unabhängig von dem gegebenem Admin-Realm. (Also beispielsweise Auch ein Account „superuser“ in dem Realm Helpdesk).

Nun ist unser Administrator Account nach wie vor in der Lage alle Funktionen durchzuführen, bisher hat sich für ihn nichts geändert. Wir haben aber die Grundlage gelegt, um nun die Berechtigungen von Helpdesk-Usern zu definieren, was wir im folgenden Abschnitt tun.

Berechtigungen von Helpdesk-Benutzern definieren

Wichtig: Bevor wir eine Helpdesk-Policy erzeugen, müssen wir unbedingt die Richtlinie für den Superuser erstellt haben. Denn ohne eine Policy, die für den Superuser gilt, würde dieser keine Berechtigungen mehr haben. Sollte dies dennoch mal passiert sein, können Sie als root User auf Kommandozeile die Policies ansehen:

und die störenden admin-Policies wieder temporär deaktivieren:

Doch nun zur Erstellung der helpdesk Policy. Diese erfolgt prinzipiell genau so wie das Erstellen der superuser Policy. Sie wird einzig und allein durch den definierten Inhalt zu einer Richtlinie, die die Berechtigungen der Benutzer im Helpdesk-Realm definiert.

Als Vorlage können wir das Template „helpdesk“ wählen. Hier sind die ganzen Aktionen, die den Benutzern erlauben das System zu verändern, nicht ausgewählt.

Bei den Bedingungen wählen wir den Admin-Realm „helpdesk“. Das Feld „Administrator“ lassen wir frei, dadurch greift diese Policy für alle Benutzer in diesem Realm.

Werfen Sie einen Blick in die Karteikarte „Aktion“, dort können Sie auswählen, welche Funktionen die Helpdesk-Benutzer auf die Token der Benutzer ausüben dürfen.

Wie meldet sich nun ein Helpdesk-Benutzer in privacyIDEA an?

Genauso wie ein normaler Benutzer in Teil 1 im Selfservice. Mit seinem Benutzernamen, diesmal allerdings gefolgt von dem Zusatz @helpdesk und seinem Domänenpasswort.

Bitte beachten Sie: Ein AD-Benutzer kann theoretisch im Default-Realm (hier sec-ins) sein und gleichzeitig im Helpdesk-Realm gefunden werden. Für privacyIDEA sind das zwei unterschiedliche, logische Benutzerobjekte mit unterschiedlichen Berechtigungen.

Berechtigungen von Benutzern im Selfservice

Im ersten Teil dieser Workshop-Reihe hatte sich der Benutzer im Selfservice-Portal selber einen TOTP-Token ausgerollt. Der Administrator kann aber über Richtlinien im Scope „user“ definieren, welche Aktionen ein Benutzer tatsächlich im Selfservice Portal durchführen darf.

So kann er definieren, welche Tokentypen ein Benutzer ausrollen darf, ob Benutzer ihre eigenen Token wieder löschen oder deaktivieren dürfen.

Je nach Definition der Prozesse im Unternehmen kann es beispielsweise kontraproduktiv sein, den Benutzern zu erlauben, eigene Token zu löschen. In unserem Beispiel legen wir nun für die Benutzer im Realm „sec-ins“ eine „user“-Policy an, die den Benutzern erlaubt, lediglich TOTP-Token auszurollen und die Beschreibung der Token zu setzen. Dies erreichen wir durch die Auswahl der Aktion „enrollTOTP“ und „setdescription“.

Gleichzeitig definieren wir mit dieser Policy, dass TOTP-Token immer als 60-Sekunden-Token ausgerollt werden, eine Länge von 8 Ziffern erzeugen und den Hash-Algorithmus SHA256 verwenden.

User-Policies

Das Interessante hierbei ist, dass wir durch die Einstellungen „totp_otplen“, „totp_timestep“ und „totp_hashlib“ erreichen, dass viele Authenticator Apps nicht mehr funktionieren, da die meisten (wie Microsoft Authenticator) nur SHA1 unterstützen. Diesen so generierten QR-Code kann der Benutzer aber zuverlässig mit dem privacyIDEA Authenticator scannen. So lässt sich bei Bedarf steuern, wenn es eine Unternehmensrichtlinie gibt, die beispielsweise die Nutzung von speziellen Authenticator Apps forcieren soll.

Wenn sich der Benutzer im Selfsevice Portal nun einen Token ausrollt, so bekommt er als Auswahl ausschließlich den Typ „TOTP“ und kann zusätzlich lediglich eine Beschreibung setzen. Über user-Policies lässt sich also auch regeln, wie komplex oder einfach das Selfservice-Portal für die Benutzer erscheinen wird.

Richtlinien bei Authentifizierung und Autorisierung

Die Scopes Authentication (auth) und Authorization (authz) regeln das Verhalten von privacyIDEA während der Authentifizierung – also die Anmeldung der normalen Benutzer am Netscaler (wie in Teil 2) oder an anderen Applikationen, die an privacyIDEA angebunden sind.

Wir betrachten hier nur kurz eine einfache Richtlinie, die oft zum Einsatz kommt. Die „otppin“ Policy regelt, ob privacyIDEA lediglich den zweiten Faktor prüfen soll, oder auch den ersten, also die statische Wissenskomponente.

Es gibt hierzu drei Einstellungen:

• „tokenpin“: In diesem Fall kann der Administrator oder der Benutzer für jeden Token ein dediziertes Passwort setzen. Dieses wird von privacyIDEA dann als erster Wissensfaktor überprüft.

• „userstore“: Hier wird als erster Wissensfaktor das Passwort in der Benutzerquelle, also in unserem Fall das AD Passwort des Benutzers, durch privacyIDEA geprüft.

• „none“: Unabhängig davon, ob eine Tokenpin für den Token gesetzt ist, wird diese bei der Authentifizierung nicht überprüft. privacyIDEA prüft ausschließlich den zweiten Faktor.

privacyIDEA Workshop – Teil 2

VPN an privacyIDEA anbinden

Verhalten im privacyIDEA Web Interface

Der Scope „WebUI“ regelt das Verhalten des WebUIs. Alle Funktionen im WebUI sind per se API Calls auf die REST API, so dass die tatsächlichen Berechtigungen sich bereits in den Scopes „admin“ und „user“ abspielen.

Eine sehr interessante Richtlinie im Scope WebUI ist die Aktion „login_mode“. Sie definiert wie sich ein Benutzer am privacyIDEA WebUI anmelden muss. Mögliche Einstellungen sind „userstore“, „privacyIDEA“ oder „none“.

• Bisher haben wir uns mit der Standardfunktionalität „userstore“ am privacyIDEA WebUI angemeldet.

• „None“: Eine Anmeldung am WebUI ist nicht erlaubt. Das kann in speziellen Situationen für gewissen Bedingungen sinnvoll sein. So kann man beispielsweise verhindern, dass sich Adminstratoren oder eben auch normale Benutzer von gewissen IP-Adressen oder auf spezielle privacyIDEA-Knoten (beispielsweise In der DMZ) anmelden können.

• „privacyIDEA“: Die Authentifizierung bei der Anmeldung am WebUI erfolgt gegen privacyIDEA selber. Hiermit lässt sich umsetzen, dass sich die entsprechenden Benutzer unter den definierten Bedingungen beispielsweise mit einem zweiten Faktor anmelden müssen. So lässt sich beispielsweise erreichen, dass eine Anmeldung am WebUI aus dem lokalen Netz mit einem einfachen Passwort, aus dem Internet aber nur mit einem zusätzlichen zweiten Faktor möglich ist.

Allgemeines Enrollment und der Spezialfall Register

Im Scope enrollment können Spezifika für den Rollout-Prozesse definiert werden. So kann der Administrator beispielsweise definieren, wie viele Token ein Benutzer maximal besitzen darf. Der Scope register wird genutzt, wenn am privacyIDEA Selfservice die Selbstregistrierung der Benutzer erlaubt ist.

Was steckt hinter den Policies und wie greifen sie ineinander?

Policies sind additiv. Es werden alle Richtlinien, die für einen Benutzer unter den gegebenen Bedingungen passen, zusammengerechnet. D.h. es kann durchaus mehrere admin-Policies geben, die für einen bestimmten Benutzer passen und somit seine Rechte aggregiert. In logischen Konflikten wird die Priorität der Policy herangezogen.

Dieses Verhalten kann sinnvoll genutzt werden, wenn es beispielsweise Richtlinien gibt, die für Benutzer über mehrere Realms hinweg gleich sind. Dann lässt sich eine oder mehrere Standardpolicies definieren, die durch Richtlinien mit zusätzlichen Bedingungen in den jeweiligen Situationen angereichert werden. Hierdurch lassen sich beliebige Szenarien logisch abbilden.

Die Bedingungen der Policies lassen sich nutzen, um diese Abweichungen z.B. von der IP-Adresse, der Tageszeit oder einem HTTP Header abhängig zu machen. Die komplette Betrachtung der Funktion und Mächtigkeit der Policies würden diesen bereits langen Artikel sprengen. Mit diesen grundlegenden Beispielen konnten wir hoffentlich das Grundprinzip vermitteln, damit Sie sich weiter annähern können.

Nächste Schritte in der Workshop-Reihe

Nachdem wir nun mehr über die Konfiguration von privacyIDEA und Berechtigungen gelernt haben, werden wir uns im 4. Teil der Reihe wieder einer Applikation zuwenden. Authentifizierung an Webdiensten erfolgt heute gerne über SAML oder OpenID Connect – Single Sign On. Für das Open Source SSO System Keycloak gibt es ein privacyIDEA Plugin, das Keycloak an Ihr zentrales privacyIDEA System anbindet. Wir werden uns im 4. Teil die Anbindung und die Anmeldung an Keycloak ansehen.

Im vorerst letzten Artikel der Reihe werden wir mit Hilfe des privacyIDEA Credential Providers die Anmeldung an Windows-Systemen absichern.

Über den Autor: Cornelius Kölbel ist CEO von NetKnights.

Tool-Tipp 34 Keycloak

Zentrale Verwaltung von Identitäten und Rollen mit Open Source

(ID:50357644)