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/09/13 16:00] – hofmann@fu-berlin.dede:shibidp:plugin-fudiscr [2024/03/05 13:38] (aktuell) – jhoffman@fu-berlin.de
Zeile 27: Zeile 27:
 | 1.3.0          | min. 4.3.0 und < 5.0.0 | min. 3.7            | aktuell                     | | 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       | | 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 =====
Zeile 43: Zeile 43:
 | TAN Token            | tan                         | 1.0.0                |                                                          | | TAN Token            | tan                         | 1.0.0                |                                                          |
 | TOTP                 | totp                        | 1.0.0                |                                                          | | TOTP                 | totp                        | 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]]                                        |+| 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]]                                        |
 | Yubico               | yubico_otp                  | 1.3.0                |                                                          | | Yubico               | yubico_otp                  | 1.3.0                |                                                          |
 | Yubikey              | yubikey_aes                 | 1.3.0                |                                                          | | Yubikey              | yubikey_aes                 | 1.3.0                |                                                          |
Zeile 98: Zeile 98:
 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:
 <file python idp-admin-policy> <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' 
 +      } 
 +   ]
 } }
 </file> </file>
Zeile 117: Zeile 120:
 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:
 <file python idp-application-tokentype> <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' 
 +      } 
 +   ]
 } }
 </file> </file>
Zeile 136: 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:
-<file python validate_triggerchallenge> +<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' 
 +      } 
 +   ]
 } }
 </file> </file>
Zeile 158: Zeile 167:
 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 167: Zeile 176:
  
 <file python webauthn-enrollment> <file python webauthn-enrollment>
-{ +{   'policy': [ 
-  'action': { +      { 
-    'webauthn_authenticator_attestation_form': 'indirect', +        'action': { 
-    'webauthn_authenticator_attestation_level': 'none' +          'webauthn_authenticator_attestation_form': 'indirect', 
-  }, +          'webauthn_authenticator_attestation_level': 'none' 
-  'active': True, +        }, 
-  'name': 'webauthn-enrollment', +        'active': True, 
-  'scope': 'enrollment',+        'name': 'webauthn-enrollment', 
 +        'scope': 'enrollment', 
 +      } 
 +   ]
 } }
 </file> </file>
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:
  • Zuletzt geändert: vor 8 Monaten