| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| de:shibidp:plugin-fudiscr [2024/10/08 11:43] – [privacyIDEA] hofmann@fu-berlin.de | de:shibidp:plugin-fudiscr [2024/10/08 12:35] (aktuell) – [Hinweis zu älteren IdP-Konfigurationen] abalke@fu-berlin.de |
|---|
| Er ist Mitarbeiter des Rechenzentrums [[https://www.zedat.fu-berlin.de|(FUB-IT)]] und zuständig für den Bereich Identity Management. Das Identity Management System der Freien Universität Berlin trägt den Namen FUDIS (FU Directory and Identity Service). Aus diesem Grund wird für das **C**hallenge-**R**esponse-Plugin in Konfigurationsparametern u.a. das Kürzel fudiscr verwendet. | Er ist Mitarbeiter des Rechenzentrums [[https://www.zedat.fu-berlin.de|(FUB-IT)]] und zuständig für den Bereich Identity Management. Das Identity Management System der Freien Universität Berlin trägt den Namen FUDIS (FU Directory and Identity Service). Aus diesem Grund wird für das **C**hallenge-**R**esponse-Plugin in Konfigurationsparametern u.a. das Kürzel fudiscr verwendet. |
| |
| Mit den Versionen 1.4.0 und 2.0.0 erfolgt eine Zusammenarbeit im Bereich [[https://fidoalliance.org/passkeys/|Passkeys]] mit der [[https://www.hm.edu|Hochschule München]]. Das Plugin enthält ab diesen Versionen ein weiteres Authentifizierungsverfahren mit dem Namen fudispasskeys. Anstelle einer zweistufigen Authentifizierung aus z.B. Benutzernamen/Passwort und Token-Validierung mit fudiscr kann eine alleinige Authentifizierung mit [[https://fidoalliance.org/passkeys/|Passkeys]] durchgeführt werden. | Mit den Versionen 1.4.0/2.0.0 erfolgt eine Zusammenarbeit im Bereich [[https://fidoalliance.org/passkeys/|Passkeys]] mit der [[https://www.hm.edu|Hochschule München]]. Das Plugin enthält ab diesen Versionen ein weiteres Authentifizierungsverfahren mit dem Namen fudispasskeys. Anstelle einer zweistufigen Authentifizierung aus z.B. Benutzernamen/Passwort und Token-Validierung mit fudiscr kann eine alleinige Authentifizierung mit [[https://fidoalliance.org/passkeys/|Passkeys]] durchgeführt werden. |
| |
| |
| ^ Plugin-Version ^ IdP-Version ^ eduMFA-Version ^ privacyIDEA-Version ^ Support-Level ^ | ^ Plugin-Version ^ IdP-Version ^ eduMFA-Version ^ privacyIDEA-Version ^ Support-Level ^ |
| | 2.0.0 | min. 5.0.0 | min. 2.0.0 | min. 3.9.2 | nicht mehr verwenden | | | 2.0.0 | min. 5.0.0 | min. 2.0.0 | min. 3.9.2 | nicht mehr verwenden | |
| | 2.1.0 | min. 5.1.0 | min. 2.0.0 | min. 3.9.2 | nicht mehr verwenden | | | **2.1.0** | **min. 5.1.0** | **min. 2.0.0** | **min. 3.9.2** | **aktuell** | |
| ===== Unterstütze Token-Verfahren aus eduMFA und privacyIDEA ===== | ===== Unterstütze Token-Verfahren aus eduMFA und privacyIDEA ===== |
| Aktuell werden die folgenden Token-Verfahren aus eduMFA ([[https://edumfa.readthedocs.io/en/latest/tokens/tokentypes.html|Token types in eduMFA]]) und privacyIDEA ([[https://privacyidea.readthedocs.io/en/latest/tokens/tokentypes.html|Token types in privacyIDEA]]) unterstützt: | Aktuell werden die folgenden Token-Verfahren aus eduMFA ([[https://edumfa.readthedocs.io/en/latest/tokens/tokentypes.html|Token types in eduMFA]]) und privacyIDEA ([[https://privacyidea.readthedocs.io/en/latest/tokens/tokentypes.html|Token types in privacyIDEA]]) unterstützt: |
| siehe [[de:shibidp:plugin-fudiscr:edumfa_setup|Installation und Konfiguration von eduMFA]] | siehe [[de:shibidp:plugin-fudiscr:edumfa_setup|Installation und Konfiguration von eduMFA]] |
| |
| ===== Installation privacyIDEA ===== | ==== privacyIDEA ==== |
| | siehe [[de:shibidp:plugin-fudiscr:privacyidea_setup|Installation und Konfiguration von privayIDEA]] |
| siehe [[https://gitlab.daasi.de/training/privacyidea|Installationsanleitung privacyIDEA von der DAASI GmbH]] | |
| | |
| ===== Konfiguration privacyIDEA ===== | |
| | |
| ==== Einrichtung eines Funktionsnutzers ==== | |
| 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. | |
| | |
| <code> | |
| pi-manage admin add idp-admin | |
| </code> | |
| | |
| **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: | |
| | |
| <code> | |
| pi-manage api createtoken -r admin -u idp-admin -d 3650 | |
| </code> | |
| \\ | |
| | |
| === 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: | |
| <file python idp-admin-policy> | |
| { 'policy': [ | |
| { | |
| 'action': {'tokenlist':True, 'triggerchallenge':True}, | |
| 'active': True, | |
| 'adminuser': ['idp-admin'], | |
| 'name': 'idp-admin-policy', | |
| 'scope': 'admin' | |
| } | |
| ] | |
| } | |
| </file> | |
| | |
| Die Policy kann unter Nutzung dieser Datei erstellt werden: | |
| <code> | |
| pi-manage policy p_import -f idp-admin-policy | |
| </code> | |
| \\ | |
| | |
| ==== Notwendige Richtlinie ==== | |
| 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: | |
| <file python idp-application-tokentype> | |
| { 'policy': [ | |
| { | |
| 'action': { | |
| 'application_tokentype': True | |
| }, | |
| 'active': True, | |
| 'name': 'idp-application-tokentype', | |
| 'scope': 'authorization' | |
| } | |
| ] | |
| } | |
| </file> | |
| | |
| Die Policy kann unter Nutzung dieser Datei erstellt werden: | |
| <code> | |
| pi-manage policy p_import -f idp-application-tokentype | |
| </code> | |
| \\ | |
| ==== Notwendiges Event für WebAuthn ==== | |
| 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: | |
| <file python 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' | |
| } | |
| ] | |
| } | |
| </file> | |
| | |
| Das Event kann unter Nutzung dieser Datei erstellt werden: | |
| <code> | |
| pi-manage event e_import -f idp-webauthn-allowed-transports | |
| </code> | |
| | |
| **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 Passkeys via QR-Code im Browser funktioniert, wird folgende weitere Richtlinie (Datei //webauthn-enrollment//) empfohlen: | |
| | |
| <file python webauthn-enrollment> | |
| { 'policy': [ | |
| { | |
| 'action': { | |
| 'webauthn_authenticator_attestation_form': 'indirect', | |
| 'webauthn_authenticator_attestation_level': 'none' | |
| }, | |
| 'active': True, | |
| 'name': 'webauthn-enrollment', | |
| 'scope': 'enrollment', | |
| } | |
| ] | |
| } | |
| </file> | |
| | |
| Die Policy kann unter Nutzung der Datei (//webauthn-enrollment//) erstellt werden: | |
| <code> | |
| pi-manage policy p_import -f webauthn-enrollment | |
| </code> | |
| | |
| 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.) | |
| | |
| ==== Allgemeine Konfigurationsoptionen ==== | |
| Die zwei **fett** markierten Optionen sollten mindestens gesetzt werden. | |
| | |
| ^Option^Default-Wert^Beschreibung^ | |
| |**''fudiscr.privacyidea.authorization_token''**|//leer//|Authorization-Token aus vorherigem Anleitungsschritt für die Zugriffssteuerung auf die privacyIDEA-API.| | |
| |**''fudiscr.privacyidea.base_uri''**|''https://localhost''|Basis-URLs der privacyIDEA-API, z.B.// https://localhost //. Mehrere URLs können durch Leerzeichen getrennt angegeben werden.| | |
| |''fudiscr.privacyidea.connection_strategy''|''ACTIVE_PASSIVE''|Werden 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_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''|''fudis_preferred''|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.reduce_trigger_challenge_requests''|''false''|Wenn 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_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.replace_all_token_types_with_custom_map''|''false''|Wenn 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_password''|//leer//|Passwort 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_username''|//leer//|Username des Admin-Users; Alternative zu ''fudiscr.privacyidea.authorization_token'' oder zur Absicherung, falls Authorization-Token abläuft.| | |
| |''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.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.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 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. | |
| | |
| ===== Custom Token Types ===== | |
| 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: | |
| <file xml> | |
| <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> | |
| </file> | |
| 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''). | |
| |
| ===== Installation ===== | ===== Installation ===== |
| |
| **Beispiel 4**: | **Beispiel 4**: |
| <alert type="warning">Nachfolgendes Beispiel funktioniert erst ab der fudiscr-Version 1.1.0. Für Versionen 1.1.0 bis <1.3.0 kann //fudiscr.UserHasAnyTokenPredicate// anstelle von //fudiscr.UserHasTokenPredicate// verwendet werden.</alert> | |
| Nach der Authentifizierung mit Benutzername und Passwort erfolgt dann eine Token basierte Authentifizierung, wenn die AuthenticationContextClass, die der ServiceProvider benötigt, nicht ausreicht oder wenn der/die Benutzer*in bereits mindestens einen Token besitzt. Bei den Tokens wird der Zustand nicht geprüft. Ein gesperrter Token würde z.B. dafür sorgen, dass das ''fudiscr.UserHasTokenPredicate'' den Wert ''true'' zurückgibt. Dieses Predicate wurde insbesondere für Rollout-Szenarien eingeführt. | Nach der Authentifizierung mit Benutzername und Passwort erfolgt dann eine Token basierte Authentifizierung, wenn die AuthenticationContextClass, die der ServiceProvider benötigt, nicht ausreicht oder wenn der/die Benutzer*in bereits mindestens einen Token besitzt. Bei den Tokens wird der Zustand nicht geprüft. Ein gesperrter Token würde z.B. dafür sorgen, dass das ''fudiscr.UserHasTokenPredicate'' den Wert ''true'' zurückgibt. Dieses Predicate wurde insbesondere für Rollout-Szenarien eingeführt. |
| <file xml ./conf/authn/mfa-authn-config.xml> | <file xml ./conf/authn/mfa-authn-config.xml> |
| Jedes Authentifizierungsverfahren im Shibboleth Identity Provider basiert auf einem abstrakten Flow mit einem AuthenticationFlowDescriptor, siehe hierzu [[https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505085/AuthenticationConfiguration|AuthenticationConfiguration]]. | Jedes Authentifizierungsverfahren im Shibboleth Identity Provider basiert auf einem abstrakten Flow mit einem AuthenticationFlowDescriptor, siehe hierzu [[https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505085/AuthenticationConfiguration|AuthenticationConfiguration]]. |
| |
| Die Eigenschaften des AuthenticationFlowDescriptor werden in der Regel für alle Flows in ''%{idp.home}/conf/authn/authn.properties''. Als Vorlage sind diese auskommentiert in ''%{idp.home}/conf/authn/fudiscr.properties'' enthalten, um sie nach der Plugin-Installation bereitszustellen: | Die Eigenschaften des AuthenticationFlowDescriptor werden in der Regel für alle Flows in ''%{idp.home}/conf/authn/authn.properties'' festgelegt. Als Vorlage sind diese auskommentiert in ''%{idp.home}/conf/authn/fudiscr.properties'' enthalten, um sie nach der Plugin-Installation bereitzustellen: |
| <file properties> | <file properties> |
| #idp.authn.fudiscr.order=1000 | #idp.authn.fudiscr.order=1000 |
| |
| ==== Hinweis zu älteren IdP-Konfigurationen ==== | ==== Hinweis zu älteren IdP-Konfigurationen ==== |
| Wenn Sie eine IdP-Konfiguration von vor Version 4.1.0 weiterpflegen, achten Sie bitte darauf, dass die Datei ''%{idp.home}/conf/idp.properties'' zu Beginn die folgende Zeile enthält, damit automatisch alle ''.properties''-Dateien unterhalb des ''%{idp.home}/conf''-Ordners (wie z.B. ''%{idp.home}/conf/fudiscr.properties'') eingelesen werden. | Wenn Sie eine IdP-Konfiguration von vor Version 4.1.0 weiter pflegen, achten Sie bitte darauf, dass die Datei ''%{idp.home}/conf/idp.properties'' zu Beginn die folgende Zeile enthält, damit automatisch alle ''.properties''-Dateien unterhalb des ''%{idp.home}/conf''-Ordners (wie z.B. ''%{idp.home}/conf/fudiscr.properties'') eingelesen werden. |
| <file properties> | <file properties> |
| idp.searchForProperties=true | idp.searchForProperties=true |
| ^Option^Default-Wert^Beschreibung^ | ^Option^Default-Wert^Beschreibung^ |
| |**''fudiscr.challengeResponseClient''**|''EduMfaChallengeResponseClient''|Diese Option legt fest, welches Token-Backend angesprochen werden soll. Seit Version 2.1.0 ist der Default-Wert ''EduMfaChallengeResponseClient'', zuvor ''PrivacyIdeaChallengeResponseClient''. Es gibt auch die Möglichkeit, einen ''PrivacyIdeaChallengeResponseClient'' zu verwenden, der ohne Backend funktioniert und sämtliche Informationen als DEBUG-Meldungen beim Starten des IdP in die Logfiles schreibt.| | |**''fudiscr.challengeResponseClient''**|''EduMfaChallengeResponseClient''|Diese Option legt fest, welches Token-Backend angesprochen werden soll. Seit Version 2.1.0 ist der Default-Wert ''EduMfaChallengeResponseClient'', zuvor ''PrivacyIdeaChallengeResponseClient''. Es gibt auch die Möglichkeit, einen ''PrivacyIdeaChallengeResponseClient'' zu verwenden, der ohne Backend funktioniert und sämtliche Informationen als DEBUG-Meldungen beim Starten des IdP in die Logfiles schreibt.| |
| |''fudiscr.default_users_realm''|//leer//|Sollte sich kein Realm aus dem Benutzernamen ergeben, so kann mit dieser Option ein Realm festegelegt werden, der bei Fehlen im fudiscr-Plugin ergänzt wird. In den meisten Fällen wird kein Realm benötigt, so dass per Default kein Realm ergänzt wird. | |''fudiscr.default_users_realm''|//leer//|Sollte sich kein Realm aus dem Benutzernamen ergeben, so kann mit dieser Option ein Realm festgelegt werden, der bei Fehlen im fudiscr-Plugin ergänzt wird. In den meisten Fällen wird kein Realm benötigt, so dass per Default kein Realm ergänzt wird. |
| |''fudiscr.filter_tokens.id_exclude_regex''|//leer//|Mit dieser Option können Token anhand ihrer ID/Seriennummer für die Verwendung im fudiscr-Plugin ausgeschlossen werden. Z.B. werden mit //^HOTP.*$// alle HOTP-Token ignoriert, die als Softwaretoken in privacyIDEA angelegt wurden und eine Seriennummer beginnend mit HOTP erhalten. Per Default wird der Filter nicht verwendet. Die Regular Expression ist nicht definiert.| | |''fudiscr.filter_tokens.id_exclude_regex''|//leer//|Mit dieser Option können Token anhand ihrer ID/Seriennummer für die Verwendung im fudiscr-Plugin ausgeschlossen werden. Z.B. werden mit //^HOTP.*$// alle HOTP-Token ignoriert, die als Softwaretoken in privacyIDEA angelegt wurden und eine Seriennummer beginnend mit HOTP erhalten. Per Default wird der Filter nicht verwendet. Die Regular Expression ist nicht definiert.| |
| |''fudiscr.filter_tokens.type_exclude_regex''|//leer//|Mit dieser Option können Token-Typen für die Verwendung im fudiscr-Plugin ausgeschlossen werden. Z.B. werden mit //^totp$// alle TOTP-Token ignoriert. Per Default wird der Filter nicht verwendet. Die Regular Expression ist nicht definiert.| | |''fudiscr.filter_tokens.type_exclude_regex''|//leer//|Mit dieser Option können Token-Typen für die Verwendung im fudiscr-Plugin ausgeschlossen werden. Z.B. werden mit //^totp$// alle TOTP-Token ignoriert. Per Default wird der Filter nicht verwendet. Die Regular Expression ist nicht definiert.| |
| c:excludePattern="^clientwait$"/> | c:excludePattern="^clientwait$"/> |
| </file> | </file> |
| In diesem Beispiel werden Token anhand einer Token-Eigenschaft herausgefiltert. In eduMFA und privacyIDEA können aktive Token existieren, die eine erste Validierung erfordern, bevor sie effektiv verwendet werden können. So soll z.B. erzwungen werden, dass Nutzer*innen bei der Einrichtung eines TOTP-Token den QR-Code mit dem Authenticator einscannen und diesen Vorgang mit einem OTP bestätigen. Die Token besitzen bis zur Bestätigung die Eigenschaft //rollout_state// mit den Werten //verify// oder //clientwait//. Die in dem Beispiel verwendeten zwei Predicates lassen sich auch mit einem Predicate und der Regular Expression //^(clientwait|verify)$// abbilden. Es soll in dem Bespiel nur die Listeneigenschaft von ''fudiscr.ExcludeTokenPredicates'' verdeutlicht werden. | In diesem Beispiel werden Token anhand einer Token-Eigenschaft herausgefiltert. In eduMFA und privacyIDEA können aktive Token existieren, die eine erste Validierung erfordern, bevor sie effektiv verwendet werden können. So soll z.B. erzwungen werden, dass Nutzer*innen bei der Einrichtung eines TOTP-Token den QR-Code mit dem Authenticator einscannen und diesen Vorgang mit einem OTP bestätigen. Die Token besitzen bis zur Bestätigung die Eigenschaft //rollout_state// mit den Werten //verify// oder //clientwait//. Die in dem Beispiel verwendeten zwei Predicates lassen sich auch mit einem Predicate und der Regular Expression //^(clientwait|verify)$// abbilden. Es soll in dem Beispiel nur die Listeneigenschaft von ''fudiscr.ExcludeTokenPredicates'' verdeutlicht werden. |
| |
| (Mit dem Konstruktor-Parameter ''c:negateResult="true"'' kann das Ergbnis eines //ExcludeTokenPredicates// negiert werden.) | (Mit dem Konstruktor-Parameter ''c:negateResult="true"'' kann das Ergbnis eines //ExcludeTokenPredicates// negiert werden.) |
| \\ | \\ |
| |
| | ===== Erweiterung für Fortinet (FortiAuthenticator) ==== |
| | Die Erweiterung für Fortinet unterstützt aktuell die Token-Typen //FortiToken (Mobile und Hardware)//, //SMS// und //E-Mail//. //FIDO2 (WebAuthn)// wird aktuell von der FortiAuthenticator API nicht unterstützt. |
| | |
| | Die Erweiterung steht unter der Apache 2.0 Lizenz und wird von der DAASI International GmbH [[https://gitlab.daasi.de/shibboleth-identity-provider/shibboleth-idp-plugin-authn-fudiscr-fortinetclient|hier]] bereitgestellt. DAASI bietet für die Erweiterung auch Softwarepflegeverträge an. Anfragen sind bitte an [[info@daasi.de|info@daasi.de]] zu senden. |
| | \\ |
| |
| ===== Weitere Materialien ===== | ===== Weitere Materialien ===== |
| |
| ===== Quellcode ===== | ===== Quellcode ===== |
| Hochschulen und andere öffentliche Einrichtungen erhalten auf Anfrage Zugriff auf den Quellcode. Bitte senden Sie hierfür eine E-Mail an [[fudis@zedat.fu-berlin.de|fudis@zedat.fu-berlin.de]]. Es wird daran gearbeitet, sämtliche Komponenten des fudiscr-Plugins unter der Apache 2.0 Lizenz zu veröffentlichen. Wir bitten (weiterhin) um Geduld. | Hochschulen und andere öffentliche Einrichtungen erhalten auf Anfrage Zugriff auf den Quellcode. Bitte senden Sie hierfür eine E-Mail an [[fudis@fu-berlin.de|fudis@fu-berlin.de]]. Es wird daran gearbeitet, sämtliche Komponenten des fudiscr-Plugins unter der Apache 2.0 Lizenz zu veröffentlichen. Wir bitten (weiterhin) um Geduld. |
| ===== Kontakt ===== | ===== Kontakt ===== |
| Fehler, Fragen, Anregungen etc. bitte per E-Mail an [[fudis@zedat.fu-berlin.de|fudis@zedat.fu-berlin.de]] senden. | Fehler, Fragen, Anregungen etc. bitte per E-Mail an [[fudis@fu-berlin.de|fudis@fu-berlin.de]] senden. |