Das fudiscr-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:

idp-admin-policy
{   '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


Das fudiscr-Plugin benötigt für bestimmte Token-Verfahren wie WebAuthn und zur Reduzierung von API-Anfragen das Recht, für /validate/triggerchallenge auf Token-Typen 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:

idp-application-tokentype
{   '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


In Verbindung mit der zuvor genannten Policy idp-application-tokentype muss der Parameter webauthn_allowed_transports per Event gesetzt werden.

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:

idp-webauthn-allowed-transports
{   '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.

Damit möglichst viele WebAuthn-Token funktionieren und auch Passkeys via QR-Code im Browser funktioniert, wird folgende weitere Richtlinie (Datei webauthn-enrollment) empfohlen:

webauthn-enrollment
{   '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.)

Die zwei fett markierten Optionen sollten mindestens gesetzt werden.

OptionDefault-WertBeschreibung
fudiscr.privacyidea.authorization_tokenleerAuthorization-Token aus vorherigem Anleitungsschritt für die Zugriffssteuerung auf die privacyIDEA-API.
fudiscr.privacyidea.base_urihttps://localhostBasis-URLs der privacyIDEA-API, z.B. https://localhost . Mehrere URLs können durch Leerzeichen getrennt angegeben werden.
fudiscr.privacyidea.connection_strategyACTIVE_PASSIVEWerden in fudiscr.privacyidea.base_uri mehrere privacyIDEA-Server angegeben, 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.check_connection_certificatetrueFalls das Serverzertifikat vom API-Endpunkt nicht geprüft werden soll, kann der Wert auf false gesetzt werden.
fudiscr.privacyidea.default_realmleerMit 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_namefudis_preferredWird 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.reduce_trigger_challenge_requestsfalseWenn diese Option auf true gesetzt ist, dann wird kein /validate/challenge für die Token-Typen motp, registration, spass, tan, totp, yubico, yubikey in privacyIDEA angefordert, aber eine Pseudo-Transaktion wird erzeugt. Bei false werden nur Pseudo-Transaktionen für den Token-Typ spass erzeugt. Bei Pseudotransaktionen wird nur ein /validate/check mit der jeweiligen Seriennummer des einzelnen Tokens angefordert.
fudiscr.privacyidea.relying_party_id_parameter_nameleerWird 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.replace_all_token_types_with_custom_mapfalseWenn benutzerdefinierte Typen mit fudiscr.edumfa.CustomTokenTypesMap definiert werden, kann mit dieser Option festgelegt werden, ob die Standardtypen vollständig ersetzt (true) oder ergänzt (false) werden.
fudiscr.privacyidea.service_passwordleerPasswort des Admin-Users; Alternative zu fudiscr.privacyidea.authorization_token oder zur Absicherung, falls Authorization-Token abläuft.
fudiscr.privacyidea.service_realmleerRealm des Admin-Users; Alternative zu fudiscr.privacyidea.authorization_token oder zur Absicherung, falls Authorization-Token abläuft.
fudiscr.privacyidea.service_usernameleerUsername des Admin-Users; Alternative zu fudiscr.privacyidea.authorization_token oder zur Absicherung, falls Authorization-Token abläuft.
fudiscr.privacyidea.singletontrueGibt 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.user_agent_ip_address_parameter_nameleerWird 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.with_additional_pin_responsefalseIn 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 Token-Typen hotp, indexed_tan, registration_code, tan, totp und yubikey_otp wird diese Funktionalität unterstützt.

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.

Für den Sonderfall, dass in privacyIDEA eigene Token-Typen implementiert werden, gibt es die Möglichkeit, diese auch über das fudiscr-Plugin zur Verfügung zu stellen. Dies ist aber nur möglich, wenn dieser neue Token-Typ keine Challenge erzeugt, die an Nutzer*innen zurückgegeben werden muss und wenn nur ein einfaches one time password verlangt wird. Der Token muss sich in der Nutzer-Interaktion also vergleichbar zu TOTP verhalten.

In %{idp.home}/conf/global.xml kann hierfür die Bean fudiscr.privacyidea.CustomTokenTypesMap definiert werden:

<util:map id="fudiscr.privacyidea.CustomTokenTypesMap" map-class="java.util.HashMap" key-type="java.lang.String" value-type="java.lang.String">
   <entry key="custom_token_type_name_in_privacyidea" value="custom_token_type_name_in_fudiscr"/>
</util:map>

Die Map fudiscr.privacyidea.CustomTokenTypesMap kann auch dafür verwendet werden, das Mapping der Token-Typen auf die Bezeichnung in fudiscr anzupassen. Erlaubt sind nur 1:1-Beziehungen.

Ergänzend entscheidet die Option fudiscr.privacyidea.replace_all_token_types_with_custom_map darüber, ob die Mappings aus fudiscr.privacyidea.CustomTokenTypesMap das Standardmapping ergänzen (false default) oder vollständig ersetzen (true).

  • Zuletzt geändert: vor 4 Wochen