==== Installation privacyIDEA ==== siehe [[https://gitlab.daasi.de/training/privacyidea|Installationsanleitung privacyIDEA von der DAASI GmbH]] ==== Konfiguration privacyIDEA ==== === Einrichtung eines Funktionsnutzers in privacyIDEA === Das Shibboleth-Plugin kommuniziert mit privacyIDEA über dessen API. Es werden drei Endpunkte verwendet: * /token/ (Abrufen einer Liste von Tokens) * /validate/triggerchallenge (Initiieren einer Token-Challenge) * /validate/check (Überprüfen eines OTP ggf. in Kombination mit einer PIN) Ein Nutzer muss also über die Berechtigungen verfügen, die Aktionen, die bei Aufruf dieser Endpunkte ausgelöst werden, ausführen zu dürfen. Am besten sollte dieser Nutzer über keine weiteren Rechte verfügen. \\ \\ == Anlegen eines Admin-Nutzers == ---- **Achtung**: Wir gehen davon aus, das der initiale Admin-Supernutzer //admin// vorhanden ist. Zunächst muss ein Admin-Nutzer für den Zugriff vom Identity Provider angelegt werden. Es empfiehlt sich, hierfür auch einen eigenen (administrativen) Realm anzulegen, um Berechtigungen für unterschiedliche Arten von Admin später besser trennen zu können. Der anzulegende Nutzer kann dann aus einer beliebigen externen Quelle kommen und über einen in privacyIDEA definierten Resolver importiert werden. Das Anlegen von Realms und Resolvern ist nicht Thema dieser Anleitung. Wir legen hier jedoch der Einfachheit und Anschaulichkeit wegen einen PrivacyIDEA-internen IdP-Admin-Nutzer an. pi-manage admin add idp-admin **Um die Anzahl an API-Anfragen zu reduzieren, sollte für den //idp-admin// anstelle von Benutzernamen und Passwort ein Token für den Zugriff erzeugt werden.** Dieser Token kann mit einer beliebigen Gültigkeitsdauer in Tagen (default 365) versehen werden. Das nachfolgende Beispiel legt eine Gültigkeitsdauer von zehn Jahren fest: pi-manage api createtoken -r admin -u idp-admin -d 3650 \\ == Vergeben der Berechtigungen == ---- Die notwendigen Berechtigungen werden via Policy in privacyIDEA eingetragen. **Achtung**: Admins in privacyIDEA haben zu Beginn Rechte für alle Aktionen. Dies gilt solange, wie keine Admin-Policy definiert ist. Definiert man eine Policy im Scope 'admin', so gelten für alle Admins nur noch die den Policies eingetragenen Rechte. Sollte es noch keine weitere Admin-Policy geben, sollte man daher darauf achten, sich nicht selbst aus dem Web-UI auszusperren. Zunächst wird mit der Richtlinien-Vorlage //superuser// die funktionserhaltende Richtlinie für den Admin-Supernutzer erstellt, und der Nutzer //admin// zugewiesen. Anschließend wird nun eine neue Policy für den Nutzer //idp-admin// erstellt. Hierfür wird eine neue Datei //idp-admin-policy// erstellt, welche die Parameter der Policy als Python-Dictionary enthält. Der Inhalt sollte wie folgt aussehen: { 'policy': [ { 'action': {'tokenlist':True, 'triggerchallenge':True}, 'active': True, 'adminuser': ['idp-admin'], 'name': 'idp-admin-policy', 'scope': 'admin' } ] } Die Policy kann unter Nutzung dieser Datei erstellt werden: pi-manage policy p_import -f idp-admin-policy \\ === Zusätzliche Richtlinie ab fudiscr-Version Version 1.3.0 === Das fudiscr-Plugin benötigt für bestimmte Tokenverfahren wie WebAuthn und zur Reduzierung von API-Anfragen das Recht, für ''/validate/triggerchallenge'' auf Tokentypen einschränken zu können. Hierfür wird eine neue Datei //idp-application-tokentype// erstellt, welche die Parameter der Policy als Python-Dictionary enthält. Der Inhalt sollte so aussehen: { 'policy': [ { 'action': { 'application_tokentype': True }, 'active': True, 'name': 'idp-application-tokentype', 'scope': 'authorization' } ] } Die Policy kann unter Nutzung dieser Datei erstellt werden: pi-manage policy p_import -f idp-application-tokentype \\ === Event ab fudiscr-Version 1.3.0 === Tests mit privcyIDEA haben ergeben, dass aufgrund eines Features/Bugs in Verbindung mit der zuvor genannten Policy //idp-application-tokentype// der Parameter ''webauthn_allowed_transports'' per Event gesetzt werden muss. Hierfür wird eine neue Datei //idp-webauthn-allowed-transports// erstellt, welche die Parameter des Events als Python-Dictionary enthält. Der Inhalt sollte so aussehen: { 'event': [ { 'action': 'set', 'active': True, 'conditions': { 'tokentype': 'webauthn' }, 'event': [ 'validate_triggerchallenge' ], 'handlermodule': 'RequestMangler', 'name': 'idp-webauthn-allowed-transports', 'options': { 'parameter': 'webauthn_allowed_transports', 'value': 'usb ble nfc internal' }, 'position': 'pre' } ] } Das Event kann unter Nutzung dieser Datei erstellt werden: pi-manage event e_import -f idp-webauthn-allowed-transports **Achtung:** Wenn per Policy der Wert ''webauthn_allowed_transports'' angepasst wird, dann sollte auch passend dazu das Event angepasst werden. \\ === Weitere Konfigurationsempfehlung === Damit möglichst viele WebAuthn-Token funktionieren und auch Passkey via QR-Code im Browser funktioniert, wird folgende weitere Richtlinie (Datei //webauthn-enrollment//) empfohlen: { 'policy': [ { 'action': { 'webauthn_authenticator_attestation_form': 'indirect', 'webauthn_authenticator_attestation_level': 'none' }, 'active': True, 'name': 'webauthn-enrollment', 'scope': 'enrollment', } ] } Die Policy kann unter Nutzung der Datei (//webauthn-enrollment//) erstellt werden: pi-manage policy p_import -f webauthn-enrollment Die die für WebAuthn notwendigen Enrollment Parameter ''webauthn_relying_party_id'' und ''webauthn_relying_party_name'' können mit dieser oder einer separaten Richtlinie definiert werden. Allgemein gilt, dass die Domain des Identity Providers entweder identisch mit ''webauthn_relying_party_id'' oder eine Subdomain von ''webauthn_relying_party_id'' sein muss. (Es findet keine Vorabfilterung statt, ob die Domain des Identity Providers mit der ''webauthn_relying_party_id'' des WebAuthn-Token verträglich ist.) === Konfigurationsoptionen für privacyIDEA === ^Option^Default-Wert^Beschreibung^ |''fudiscr.privacyidea.base_uri''|//leer//|Basis-URL der privacyIDEA-API, z.B.// https://localhost //. Mit der fudiscr-Version 1.3.0 können mehrere URLs durch Leerzeichen getrennt angegeben werden.| |''fudiscr.privacyidea.connection_strategy''|''ACTIVE_PASSIVE''|Erlaubt die fudiscr-Version in ''fudiscr.privacyidea.base_uri'' die Angabe mehrere privacyIDEA-Server, so kann mit dieser Option festgelegt werden, wie die Anfragen verteilt werden. Bei ''ACTIVE_PASSIVE'' (default) werden die URLs immer beginnend mit der ersten URL in Reihenfolge angefragt bis ein Server erfolgreich antwortet. Bei ''ROUND_ROBIN'' werden die URLs als zyklische Liste verwendet und bei jeder Anfrage wird die nächste URL aus der Liste benutzt.| |''fudiscr.privacyidea.authorization_token''|//leer//|Authorization-Token aus vorherigem Anleitungsschritt für die Zugriffssteuerung auf die privacyIDEA-API.| |''fudiscr.privacyidea.service_username''|//leer//|Username des Admin-Users; Alternative zu ''fudiscr.privacyidea.authorization_token'' oder zur Absicherung, falls Authorization-Token abläuft.| |''fudiscr.privacyidea.service_realm''|//leer//|Realm des Admin-Users; Alternative zu ''fudiscr.privacyidea.authorization_token'' oder zur Absicherung, falls Authorization-Token abläuft.| |''fudiscr.privacyidea.service_password''|//leer//|Passwort des Admin-Users; Alternative zu ''fudiscr.privacyidea.authorization_token'' oder zur Absicherung, falls Authorization-Token abläuft.| |''fudiscr.privacyidea.check_connection_certificate''|''true''|Falls das Serverzertifikat vom API-Endpunkt nicht geprüft werden soll, kann der Wert auf ''false'' gesetzt werden.| |''fudiscr.privacyidea.default_realm''|//leer//|Mit dieser Option kann festgelegt werden, ob ein Realm der API-Anfrage an privacyIDEA hinzugefügt wird, wenn in vorherigen Schritten kein Realm dem Nutzer zugeordnet ist. Der hier definierte Realm wird dem allgemeinen User-Objekt im fudiscr-Plugin nicht hinzugefügt!| |''fudiscr.privacyidea.preferred_parameter_name''|//leer//|Wird mit dieser Option ein Name angegeben, so wird nach diesem Namen in den Token-Infos in privacyIDEA gesucht und versucht, den zugehörigen Wert als Boolean zu interpretieren. Sollte der Wert //true// ergeben, so wird der Token auf der eventuellen Auswahlseite der Token vorselektiert.| |''fudiscr.privacyidea.relying_party_id_parameter_name''|//leer//|Wird mit dieser Option ein Name angegeben, so wird bei jeder Anfrage gegen die privacyIDEA-API die entityID des Service Providers als Parameter mit diesem Namen übergeben.| |''fudiscr.privacyidea.user_agent_ip_address_parameter_name''|//leer//|Wird mit dieser Option ein Name angegeben, so wird bei jeder Anfrage gegen die privacyIDEA-API die IP-Adresse des Users als Parameter mit diesem Namen übergeben.| |''fudiscr.privacyidea.singleton''|''true''|Gibt an, ob der vom fudiscr-Plugin verwendete //PrivacyIdeaChallengeResponseClient// nur einmal instanziiert wird. In manchen Anwendungsfällen kann es die Performance verbessern, wenn mehrere Instanzen zugelassen werden.| |''fudiscr.privacyidea.with_additional_pin_response''|''false''|In privacyIDEA ist es möglich, neben dem one time password/code noch eine PIN zu verlangen. Wenn dieser Konfigurationsparameter auf ''true'' gesetzt ist, dann ergänzt das fudiscr-Plugin auf der Eingabeseite für die Response ein PIN-Feld. Nur für die Tokentypen //hotp//, //indexed_tan//, //registration_code//, //tan//, //totp// und //yubikey_otp// wird diese Funktionalität unterstützt. (Bis fudiscr-Version 1.2.0 wurde diese Option unter dem Namen ''fudiscr.with_additional_pin_response'' geführt.)| |''fudiscr.privacyidea.single_trigger_challenges''|''true''|Dies Option existiert nur bis zur fudiscr-Version 1.2.0. Wird der Wert auf ''false'' gesetzt, wird über alle aktive Token der Nutzer*innen eine Challange ausgelöst und nicht (wie bei ''true'') eine separate Challenge pro Token. Wird WebAuthn mit mehreren aktiven WebAuthn-Token pro Nutzer in der fudiscr-Version 1.2.0 eingesetzt, so sollte der Wert auf ''false'' gesetzt werden.| **Hinweis**: In Abhängigkeit von der Konfigurationsweise des Shibboleth Identity Providers empfiehlt es sich, Token und Passwörter wie in ''fudiscr.privacyidea.authorization_token'' und ''fudiscr.privacyidea.service_password'' in geschützte/unversionierte Dateien wie ''%{idp.home}/credentials/secrets.properties'' auszulagern.