Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
de:shibidp:plugin-fudiscr [2023/08/31 08:37] – [Unterstütze Tokenverfahren aus privacyIDEA] hofmann@fu-berlin.dede:shibidp:plugin-fudiscr [2024/03/05 13:38] (aktuell) – jhoffman@fu-berlin.de
Zeile 14: Zeile 14:
 Eine externe Implementierung für Fortinet existiert auch bereits. Eine externe Implementierung für Fortinet existiert auch bereits.
  
-Die bisherigen Entwicklungsarbeiten wurden von Steffen Hofmann von der [[https://www.fu-berlin.de|Freien Universität Berlin]] durchgeführt.+Die primären Entwicklungsarbeiten wurden von Steffen Hofmann von der [[https://www.fu-berlin.de|Freien Universität Berlin]] durchgeführt.
 Er ist Mitarbeiter des Rechenzentrums [[https://www.zedat.fu-berlin.de|(FUB-IT Infrastruktur)]] 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 Infrastruktur)]] 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.
-Die zukünftige Pflege des Plugins erfolgt durch die [[https://www.fu-berlin.de|Freien Universität Berlin]]. + 
-Sollte dies durch die Hochschule nicht mehr sichergestellt werden können, so stellen Partnerorganisationen und -unternehmen dies sicher.+Mit der Version 1.4.0 erfolgt eine Zusammenarbeit im Bereich FIDO2/WebAuthn mit der Hochschule München. Die Pflege des Plugins erfolgt mit dieser Version in Kooperation der [[https://www.fu-berlin.de|Freien Universität Berlin]] und der [[https://www.hm.edu|Hochschule München]].
  
 ===== Versionen ===== ===== Versionen =====
-^ Plugin-Version ^ IdP-Version   ^ privacyIDEA-Version ^ Support-Level         ^ +^ Plugin-Version ^ IdP-Version            ^ privacyIDEA-Version ^ Support-Level               ^ 
-| 1.0.0          | min. 4.1.2    | min. 3.7            | nicht mehr verwenden  | +| 1.0.0          | min. 4.1.2 und < 4.3.0 | min. 3.7            | nicht mehr verwenden        | 
-| 1.1.0          | min. 4.1.2    | min. 3.7            | nicht mehr verwenden  | +| 1.1.0          | min. 4.1.2 und < 4.3.0 | min. 3.7            | nicht mehr verwenden        | 
-| 1.1.1          | min. 4.1.2    | min. 3.7            | nicht mehr verwenden  | +| 1.1.1          | min. 4.1.2 und < 4.3.0 | min. 3.7            | nicht mehr verwenden        | 
-| 1.2.0          | min. 4.1.2    | min. 3.7            | aktuell               |  +| 1.2.0          | min. 4.1.2 und < 4.3.0 | min. 3.7            | aktuell                     |  
-| 1.3.0          | min. 4.3.0    | min. 3.7            | für Tests freigegeben | +| 1.3.0          | min. 4.3.0 und < 5.0.0 | min. 3.7            | aktuell                     | 
- +| 1.4.0          | min. 4.3.0 und < 5.0.0 | min. 3.8.1          | für Tests freigegeben       | 
 +| 2.0.0          | min. 5.0.0             | min. 3.8.1          | für Tests freigegeben       |
  
 ===== Unterstütze Tokenverfahren aus privacyIDEA ===== ===== Unterstütze Tokenverfahren aus privacyIDEA =====
 Aktuell werden die folgenden Tokenverfahren aus privacyIDEA ([[https://privacyidea.readthedocs.io/en/latest/tokens/tokentypes.html|Token types in privacyIDEA]]) unterstützt: Aktuell werden die folgenden Tokenverfahren aus privacyIDEA ([[https://privacyidea.readthedocs.io/en/latest/tokens/tokentypes.html|Token types in privacyIDEA]]) unterstützt:
-^ Tokenverfahren       ^ Typbezeichnung im Plugin ^ min. Plugin-Version ^ Einschränkungen / Hinweise                               ^ +^ Tokenverfahren       ^ Typbezeichnung im Plugin    ^ min. Plugin-Version ^ Einschränkungen / Hinweise                               ^ 
-| Email                | mail                     | 1.0.0                |                                                          | +| Email                | mail                        | 1.0.0                |                                                          | 
-| HOTP Token           | hotp                     | 1.0.0                |                                                          | +| HOTP Token           | hotp                        | 1.0.0                |                                                          | 
-| Indexed Secret Token | indexed_secret           | 1.0.0                |                                                          | +| Indexed Secret Token | indexed_secret              | 1.0.0                |                                                          | 
-| mOTP Token           | motp                     | 1.0.0                |                                                          | +| mOTP Token           | motp                        | 1.0.0                |                                                          | 
-| Paper Token (PPR)    | indexed_tan              | 1.0.0                |                                                          | +| Paper Token (PPR)    | indexed_tan                 | 1.0.0                |                                                          | 
-| Questionnaire Token  | question                 | 1.0.0                | Es darf nur eine Antwort per Richtlinie verlangt werden. | +| Questionnaire Token  | question                    | 1.0.0                | Es darf nur eine Antwort per Richtlinie verlangt werden. | 
-| Registration         | registration_code        | 1.3.0                |                                                          | +| Registration         | registration_code           | 1.3.0                |                                                          | 
-| SMS Token            | sms                      | 1.0.0                |                                                          | +| Remote               | //referenzierter Tokentyp// | 1.3.0                | Nur referenzierte Token vom Typ //Email//, //HOTP Token//, //mOTP Token//, //Paper Token (PPR)//, //Registration//, //SMS Token//, //TAN Token, TOTP//, //Yubico// und //Yubikey// werden unterstützt. | 
-| TAN Token            | tan                      | 1.0.0                |                                                          | +| SMS Token            | sms                         | 1.0.0                |                                                          | 
-| TOTP                 | totp                     | 1.0.0                |                                                          | +| TAN Token            | tan                         | 1.0.0                |                                                          | 
-| WebAuthn             | web_authn                | 1.2.0                | bei Version 1.2.0 nur mit Konfigurationsoption ''fudiscr.privacyidea.single_trigger_challenges=false'', ab Version 1.3.0 siehe [[user:hofmann_fu-berlin.de#zusaetzliche_richtlinie_ab_fudiscr-version_version_130|Richtlinie und Event ab Version 1.3.0]]                                        | +| TOTP                 | totp                        | 1.0.0                |                                                          | 
-| Yubico               | yubico_otp               | 1.3.0                |                                                          | +| WebAuthn             | web_authn                   | 1.2.0                | bei Version 1.2.0 nur mit Konfigurationsoption ''fudiscr.privacyidea.single_trigger_challenges=false'', ab Version 1.3.0 siehe [[#zusaetzliche_richtlinie_ab_fudiscr-version_version_130|Richtlinie und Event ab Version 1.3.0]]                                        | 
-| Yubikey              | yubikey_aes              | 1.3.0                |                                                          |+| Yubico               | yubico_otp                  | 1.3.0                |                                                          | 
 +| Yubikey              | yubikey_aes                 | 1.3.0                |                                                          |
  
 ===== Installation und Konfiguration ===== ===== Installation und Konfiguration =====
Zeile 96: Zeile 97:
  
 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: 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:
-<code> +<file python idp-admin-policy> 
-{ +{   'policy': [    
-  'action': {'tokenlist':True, 'triggerchallenge':True}, +      { 
-  'active': True, +        'action': {'tokenlist':True, 'triggerchallenge':True}, 
-  'adminuser': ['idp-admin'], +        'active': True, 
-  'name': 'idp-admin-policy', +        'adminuser': ['idp-admin'], 
-  'scope': 'admin'+        'name': 'idp-admin-policy', 
 +        'scope': 'admin' 
 +      } 
 +   ]
 } }
-</code>+</file>
  
 Die Policy kann unter Nutzung dieser Datei erstellt werden: Die Policy kann unter Nutzung dieser Datei erstellt werden:
Zeile 115: Zeile 119:
  
 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: 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:
-<code> +<file python idp-application-tokentype> 
-{ +{   'policy': [ 
-  'action': { +      { 
-    'application_tokentype': True +        'action': { 
-  }, +          'application_tokentype': True 
-  'active': True, +        }, 
-  'name': 'idp-application-tokentype', +        'active': True, 
-  'scope': 'authorization'+        'name': 'idp-application-tokentype', 
 +        'scope': 'authorization' 
 +      } 
 +   ]
 } }
-</code>+</file>
  
 Die Policy kann unter Nutzung dieser Datei erstellt werden: Die Policy kann unter Nutzung dieser Datei erstellt werden:
Zeile 135: Zeile 142:
  
 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: 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:
-<code> +<file python idp-webauthn-allowed-transports> 
-{ +{   'event': [ 
-  'action': 'set', +      { 
-  'active': True, +        'action': 'set', 
-  'conditions': { +        'active': True, 
-    'tokentype': 'webauthn' +        'conditions': { 
-  }, +          'tokentype': 'webauthn' 
-  'event': [ +        }, 
-    'validate_triggerchallenge' +        'event': [ 
-  ], +          'validate_triggerchallenge' 
-  'handlermodule': 'RequestMangler', +        ], 
-  'name': 'idp-webauthn-allowed-transports', +        'handlermodule': 'RequestMangler', 
-  'options': { +        'name': 'idp-webauthn-allowed-transports', 
-    'parameter': 'webauthn_allowed_transports', +        'options': { 
-    'value': 'usb ble nfc internal' +          'parameter': 'webauthn_allowed_transports', 
-  }, +          'value': 'usb ble nfc internal' 
-  'position': 'pre'+        }, 
 +        'position': 'pre' 
 +      } 
 +   ]
 } }
-</code>+</file>
  
 Das Event kann unter Nutzung dieser Datei erstellt werden: Das Event kann unter Nutzung dieser Datei erstellt werden:
 <code> <code>
-pi-manage event e_import -f idp-webauthn-allowed-transports name scope action+pi-manage event e_import -f idp-webauthn-allowed-transports
 </code> </code>
  
Zeile 165: Zeile 175:
 Damit möglichst viele WebAuthn-Token funktionieren und auch Passkey via QR-Code im Browser funktioniert, wird folgende weitere Richtlinie (Datei //webauthn-enrollment//) empfohlen: Damit möglichst viele WebAuthn-Token funktionieren und auch Passkey via QR-Code im Browser funktioniert, wird folgende weitere Richtlinie (Datei //webauthn-enrollment//) empfohlen:
  
-<code> +<file python webauthn-enrollment> 
-{ +{   'policy': [ 
-  'action': { +      { 
-    'webauthn_authenticator_attestation_form': 'indirect', +        'action': { 
-    'webauthn_authenticator_attestation_level': 'none', +          'webauthn_authenticator_attestation_form': 'indirect', 
-    'webauthn_avoid_double_registration': True +          'webauthn_authenticator_attestation_level': 'none' 
-  }, +        }, 
-  'active': True, +        'active': True, 
-  'name': 'webauthn-enrollment', +        'name': 'webauthn-enrollment', 
-  'scope': 'enrollment',+        'scope': 'enrollment', 
 +      } 
 +   ]
 } }
-</code>+</file>
  
 Die Policy kann unter Nutzung der Datei (//webauthn-enrollment//) erstellt werden: Die Policy kann unter Nutzung der Datei (//webauthn-enrollment//) erstellt werden:
Zeile 216: Zeile 228:
 </code> </code>
 \\ \\
-=== Installation der Testversion 1.3.0 ===+=== Installation der Testversion 1.4.0 ===
 Mit dem folgenden Aufruf kann die aktuelle Testversion des Plugins installiert und aktiviert werden: Mit dem folgenden Aufruf kann die aktuelle Testversion des Plugins installiert und aktiviert werden:
 <code> <code>
Zeile 224: Zeile 236:
 Für ein Update auf die aktuelle Testversion ist folgender Aufruf zu verwenden: Für ein Update auf die aktuelle Testversion ist folgender Aufruf zu verwenden:
 <code> <code>
-%{idp.home}/bin/plugin.sh -u de.zedat.fudis.shibboleth.idp.plugin.authn.fudiscr -fu 1.3.0+%{idp.home}/bin/plugin.sh -u de.zedat.fudis.shibboleth.idp.plugin.authn.fudiscr -fu 1.4.0
 </code> </code>
  
Zeile 681: Zeile 693:
 </beans> </beans>
 </file> </file>
 +
 +\\
 +
 +**Beispiel 5**: Wahlweise authn/Password und authn/SPNEGO als ersten Faktor -> [[de:aai:mfa_mit_passwd_spnego_first|hier]]. 
 +
 +\\
  
 === Reuse Condition === === Reuse Condition ===
Zeile 702: Zeile 720:
 <alert type="warning">Es wird empfohlen, ''idp.authn.MFA.reuseCondition=shibboleth.Conditions.FALSE'' zu setzen, damit bei jeder Authentifizierungsanfrage die Logik in ''./conf/authn/mfa-authn-config.xml'' durchlaufen wird. Im Reuse-Fall wird z.B. bei bestehender SSO-Session nicht geprüft, ob ein/e Benutzer*in einer bestimmten Affiliation angehört.</alert> <alert type="warning">Es wird empfohlen, ''idp.authn.MFA.reuseCondition=shibboleth.Conditions.FALSE'' zu setzen, damit bei jeder Authentifizierungsanfrage die Logik in ''./conf/authn/mfa-authn-config.xml'' durchlaufen wird. Im Reuse-Fall wird z.B. bei bestehender SSO-Session nicht geprüft, ob ein/e Benutzer*in einer bestimmten Affiliation angehört.</alert>
  
 +<alert type="warning">
 +Bei der Verwendung von ''mfaCtx.isAcceptable()'' ist im Zusammenhang mit den Reuse Conditions besondere Vorsicht geboten. Bei dieser Funktion werden nämlich Reuse Conditions nicht beachtet. Wurde bereits eine angefragte [[https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf|AuthenticationContextClass]] zuvor erfüllt, so liefert die Funktion ''true'' zurück.
 +<file xml>
 +<?xml version="1.0" encoding="UTF-8"?>
 +<beans ...>
 +    ... 
 +    <!-- 
 +        Wird z.B. mit 'urn:de:zedat:fudis:SAML:2.0:ac:classes:CR' ein zweiter Faktor angefordert,
 +        so wird dieser beim ersten Service Provider auch abgefragt.
 +        Wenn 'idp.authn.MFA.reuseCondition=shibboleth.Conditions.FALSE' gesetzt ist, wird auch immer 'checkSecondFactor' bei weiteren Service Providern durchlaufen.
 +        Die Funktion 'mfaCtx.isAcceptable()' gibt aber bei den weiteren Service Providern 'true' zurück und der zweite Faktor wird nicht mehr angefragt.
 +        'idp.authn.fudiscr.reuseCondition' ist an dieser Stelle also wirkungslos.
 +    -->
 +    <bean id="checkSecondFactor" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript">
 +        <constructor-arg>
 +            <value>
 +                <![CDATA[
 +            nextFlow = "authn/fudiscr";
 +
 +            authCtx = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
 +            mfaCtx = authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");
 +            if (mfaCtx.isAcceptable()) {
 +                nextFlow = null;
 +            }
 +
 +            nextFlow;
 +        ]]>
 +            </value>
 +        </constructor-arg>
 +    </bean>
 +    ...
 +</beans>
 +</file>
 +
 +Nachfolgendes Beispiel erweitert das vorherige Beispiel und erzwingt den Aufruf vom zweiten Faktor mit fudiscr, wenn dieser per [[https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf|AuthenticationContextClass]] 'urn:de:zedat:fudis:SAML:2.0:ac:classes:CR' angefordert wird.
 +<file xml>
 +<?xml version="1.0" encoding="UTF-8"?>
 +<beans ...>
 +    ... 
 +    <!-- 
 +        (Die nachfolgende erweiterte Logik kann auch anders dargestellt werden.)
 +        Wenn 'urn:de:zedat:fudis:SAML:2.0:ac:classes:CR' angefragt wird, dann wird auch 'fudiscr' immer durchlaufen
 +        und die Reuse Condition 'idp.authn.fudiscr.reuseCondition' ausgewertet.
 +        Mit 'idp.authn.fudiscr.reuseCondition=shibboleth.Conditions.FALSE' wird dann bei jedem Service Provider,
 +        der einen zweiten Faktor verlangt, ein Token abgefragt. Mit 'idp.authn.fudiscr.reuseCondition=shibboleth.Conditions.TRUE'
 +        gibt es für Nutzende kein Unterschied im Verhalten des Login-Vorgangs zum vorherigen Beispiel.
 +    -->    
 +    <bean id="checkSecondFactor" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript">
 +        <constructor-arg>
 +            <value>
 +                <![CDATA[
 +            nextFlow = "authn/fudiscr";
 +
 +            authCtx = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
 +            mfaCtx = authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");
 +            if (mfaCtx.isAcceptable()) {
 +                AuthnContextClassRefPrincipal = Java.type("net.shibboleth.idp.saml.authn.principal.AuthnContextClassRefPrincipal");
 +                refPrincipal = new AuthnContextClassRefPrincipal("urn:de:zedat:fudis:SAML:2.0:ac:classes:CR");
 +                rpCtx = authCtx.getSubcontext("net.shibboleth.idp.authn.context.RequestedPrincipalContext");
 +
 +                if (rpCtx == null || !rpCtx.getRequestedPrincipals().contains(refPrincipal)) {
 +                    nextFlow = null;
 +                }
 +            }
 +
 +            nextFlow;
 +        ]]>
 +            </value>
 +        </constructor-arg>
 +    </bean>
 +    ...
 +</beans>
 +</file>
 +</alert>
 +Wenn 'ForceAuthn' via SAML angefragt wird, dann gibt die Funktion ''mfaCtx.isAcceptable()'' immer ''false'' zurück.
 ==== Logging ==== ==== Logging ====
 Um detaillierte Logging-Informationen vom fudiscr-Plugin zu erhalten, kann die folgende Zeile in ''%{idp.home}/conf/logback.xml'' ergänzt werden: Um detaillierte Logging-Informationen vom fudiscr-Plugin zu erhalten, kann die folgende Zeile in ''%{idp.home}/conf/logback.xml'' ergänzt werden:
 <file xml> <file xml>
-<logger name="de.zedat.fudis" level="DEBUG/>+<logger name="de.zedat.fudis" level="DEBUG"/>
 </file> </file>
  
Zeile 741: Zeile 834:
 idp.c14n.fudiscr.trim=true idp.c14n.fudiscr.trim=true
 </file> </file>
 +===== FIDO2 Userless =====
 +Mit der aktuellen Testversion 1.4.0 wurde in Zusammenarbeit mit der Hochschule München ein neues Authentifizierungsverfahren eingeführt. Weitere Details folgen in Kürze.
 +
 ===== Weitere Materialien ===== ===== Weitere Materialien =====
   * Flow: [[https://identity.fu-berlin.de/downloads/shibboleth/idp/plugins/authn/fudiscr/doc/ChallengeResponseFlow.pdf|ChallengeResponseFlow.pdf]]   * Flow: [[https://identity.fu-berlin.de/downloads/shibboleth/idp/plugins/authn/fudiscr/doc/ChallengeResponseFlow.pdf|ChallengeResponseFlow.pdf]]
  • Zuletzt geändert: vor 8 Monaten