Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp:plugin-fudiscr [2024/10/08 12:18] – abalke@fu-berlin.de
+++ de:shibidp:plugin-fudiscr [2024/10/08 12:35] (aktuell) – [Hinweis zu älteren IdP-Konfigurationen] abalke@fu-berlin.de
@@ Zeile 431: / Zeile 431: @@
 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>
 #idp.authn.fudiscr.order=1000
@@ Zeile 460: / Zeile 460: @@
 ==== 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>
 idp.searchForProperties=true
@@ Zeile 493: / Zeile 493: @@
 ^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.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.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.|
@@ Zeile 600: / Zeile 600: @@
       c:excludePattern="^clientwait$"/>
 </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.)

2fa mfa zwei-faktor-authentifizierung mehr-faktor-authentifizierung mehrfaktorauthentifizierung