Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
user:hofmann_fu-berlin.de [2023/08/30 11:10] – [Konfiguration privacyIDEA] abalke@fu-berlin.de | user:hofmann_fu-berlin.de [2024/05/30 16:05] – [Unterstütze Tokenverfahren aus eduMFA und privacyIDEA] hofmann@fu-berlin.de |
---|
====== IdP-Authn-Plugin fudiscr ab Version 1.3.0 ====== | ====== IdP-Authn-Plugin fudiscr ====== |
| |
===== Allgemein ===== | ===== Allgemein ===== |
Es enthält auch selbst keine speziellen Algorithmen zur Validierung von Token. | Es enthält auch selbst keine speziellen Algorithmen zur Validierung von Token. |
Über ein generisches ChallengeResponseClientInterface kann ein Token-System angebunden werden. | Über ein generisches ChallengeResponseClientInterface kann ein Token-System angebunden werden. |
Das Plugin enthält bereits eine Implementierung dieses Interfaces für [[https://www.privacyidea.org/|privacyIDEA]]. | Das Plugin enthält bereits eine Implementierung dieses Interfaces für [[https://edumfa.io/|eduMFA]] und [[https://www.privacyidea.org/|privacyIDEA]]. |
Zudem ist eine Mockup-Implementierung für Tests enthalten. | Zudem ist eine rudimentäre Mockup-Implementierung für Tests enthalten. |
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. | |
| |
===== Versionen ===== | 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 Tokenvalidierung mit fudiscr kann eine alleinige Authentifizierung mit [[https://fidoalliance.org/passkeys/|Passkeys]] durchgeführt werden. |
^ Plugin-Version ^ IdP-Version ^ privacyIDEA-Version ^ Support-Level ^ | |
| 1.0.0 | min. 4.1.2 | min. 3.7 | nicht mehr verwenden | | |
| 1.1.0 | min. 4.1.2 | min. 3.7 | nicht mehr verwenden | | |
| 1.1.1 | min. 4.1.2 | min. 3.7 | nicht mehr verwenden | | |
| 1.2.0 | min. 4.1.2 | min. 3.7 | aktuell | | |
| 1.3.0 | min. 4.3.0 | min. 3.7 | für Tests freigegeben | | |
| |
| |
| ===== Versionen für den Shibboleth Identity Provider in der Version 4 ===== |
| ^ Plugin-Version ^ IdP-Version ^ eduMFA-Version ^ privacyIDEA-Version ^ Support-Level ^ |
| | 1.0.0 | min. 4.1.2 und < 4.3.0 | N/A | min. 3.7 | nicht mehr verwenden | |
| | 1.1.0 | min. 4.1.2 und < 4.3.0 | N/A | min. 3.7 | nicht mehr verwenden | |
| | 1.1.1 | min. 4.1.2 und < 4.3.0 | N/A | min. 3.7 | nicht mehr verwenden | |
| | 1.2.0 | min. 4.1.2 und < 4.3.0 | N/A | min. 3.7 | nicht mehr verwenden | |
| | 1.3.0 | min. 4.3.0 und < 5.0.0 | N/A | min. 3.7 | nicht mehr verwenden | |
| | 1.4.0 | min. 4.3.0 und < 5.0.0 | min. 2.0.0 | min. 3.9.2 | aktuell | |
| |
===== Unterstütze Tokenverfahren aus privacyIDEA ===== | ===== Versionen für den Shibboleth Identity Provider in der Version 5 ===== |
Aktuell werden die folgenden Tokenverfahren aus privacyIDEA ([[https://privacyidea.readthedocs.io/en/latest/tokens/tokentypes.html|Token types in privacyIDEA]]) unterstützt: | ^ Plugin-Version ^ IdP-Version ^ eduMFA-Version ^ privacyIDEA-Version ^ Support-Level ^ |
^ Tokenverfahren ^ Typbezeichnung im Plugin ^ min. Plugin-Version ^ Einschränkungen / Hinweise ^ | | 2.0.0 | min. 5.0.0 | min. 2.0.0 | min. 3.9.2 | aktuell | |
| Email | mail | 1.0.0 | | | ===== Unterstütze Tokenverfahren aus eduMFA und privacyIDEA ===== |
| HOTP Token | hotp | 1.0.0 | | | Aktuell werden die folgenden Tokenverfahren 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: |
| Indexed Secret Token | indexed_secret | 1.0.0 | | | ^ Tokenverfahren ^ Typbezeichnung im Plugin ^ min. Plugin-Version ^ Einschränkungen / Hinweise ^ |
| mOTP Token | motp | 1.0.0 | | | | Email | mail | 1.0.0 | | |
| Paper Token (PPR) | indexed_tan | 1.0.0 | | | | HOTP Token | hotp | 1.0.0 | | |
| Questionnaire Token | question | 1.0.0 | Es darf nur eine Antwort per Richtlinie verlangt werden. | | | Indexed Secret Token | indexed_secret | 1.0.0 | | |
| Registration | registration_code | 1.3.0 | | | | mOTP Token | motp | 1.0.0 | | |
| SMS Token | sms | 1.0.0 | | | | Paper Token (PPR) | indexed_tan | 1.0.0 | | |
| TAN Token | tan | 1.0.0 | | | | Questionnaire Token | question | 1.0.0 | Es darf nur eine Antwort per Richtlinie verlangt werden. | |
| TOTP | totp | 1.0.0 | | | | Registration | registration_code | 1.3.0 | | |
| WebAuthn | web_authn | 1.2.0 | bei Version 1.2.0 nur mit Konfigurationsoption ''fudiscr.privacyidea.single_trigger_challenges=false'', aber 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]] | | | 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. | |
| Yubikey | yubikey_otp | 1.3.0 | | | | SMS Token | sms | 1.0.0 | | |
| | Spass | simple_pass_token | 1.4.0/2.0.0 | | |
| | TAN Token | tan | 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 [[#zusaetzliche_richtlinie_ab_fudiscr-version_version_130|Richtlinie und Event ab Version 1.3.0]] | |
| | Yubico | yubico_otp | 1.3.0 | | |
| | Yubikey | yubikey_aes | 1.3.0 | | |
| |
===== Installation und Konfiguration ===== | ===== Installation und Konfiguration ===== |
Definiert man eine Policy im Scope 'admin', so gelten für alle Admins nur noch die den Policies eingetragenen Rechte. | 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. | Sollte es noch keine weitere Admin-Policy geben, sollte man daher darauf achten, sich nicht selbst aus dem Web-UI auszusperren. |
privacyIDEA weist daher darauf hin, falls man eine Admin-Policy definiert, jedoch in keiner (dieser oder) anderen Policy Rechte zum Bearbeiten von Policies vergeben wurden. | |
| |
Zunächst wird mit der Richtlinien-Vorlage //superuser// die funktionserhaltende Richtlinie für den Admin-Supernutzer erstellt, und der Nutzer //admin// zugewiesen. | Zunächst wird mit der Richtlinien-Vorlage //superuser// die funktionserhaltende Richtlinie für den Admin-Supernutzer erstellt, und der Nutzer //admin// zugewiesen. |
| |
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: |
| |
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: |
| |
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> |
| |
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: |
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 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.) |
| |
==== Aktivierung MFA-Module ==== | ==== Aktivierung MFA-Modul ==== |
Das fudiscr-Plugin benötigt das MFA-Module. Dieses sollte wie folgt aktiviert werden: | Das fudiscr-Plugin benötigt das MFA-Modul. Dieses sollte wie folgt aktiviert werden: |
<code> | <code> |
%{idp.home}/bin/module.sh -e idp.authn.MFA | %{idp.home}/bin/module.sh -e idp.authn.MFA |
</code> | </code> |
Mit dem MFA-Module wird auch die Konfigurationsdatei, ''%{idp.home}/conf/authn/mfa-authn-config.xml'' abgelegt. | Mit dem MFA-Modul wird auch die Konfigurationsdatei, ''%{idp.home}/conf/authn/mfa-authn-config.xml'' abgelegt. |
| |
| |
</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> |
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> |
| |
|''fudiscr.on_failed_restart_completely_mfa''|''shibboleth.Conditions.FALSE''|Dieses [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631700/PredefinedBeans|Predicate]] legt fest, ob bei einem Neustart der Authentifizieurung aus dem fudiscr-Plugin heraus nur der Faktor //fudiscr// im MFA-Flow (Default) oder die gesamte Authentifizierung neu gestartet wird. Gibt das [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631700/PredefinedBeans|Predicate]] ''TRUE'' zurück, werden also die Ergebnisse der vorherigen Faktoren zurückgesetzt. Es werden also Benutzername und Passwort u.a. erneut verlangt.| | |''fudiscr.on_failed_restart_completely_mfa''|''shibboleth.Conditions.FALSE''|Dieses [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631700/PredefinedBeans|Predicate]] legt fest, ob bei einem Neustart der Authentifizieurung aus dem fudiscr-Plugin heraus nur der Faktor //fudiscr// im MFA-Flow (Default) oder die gesamte Authentifizierung neu gestartet wird. Gibt das [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631700/PredefinedBeans|Predicate]] ''TRUE'' zurück, werden also die Ergebnisse der vorherigen Faktoren zurückgesetzt. Es werden also Benutzername und Passwort u.a. erneut verlangt.| |
|''fudiscr.result_with_username_principal''|''shibboleth.Conditions.TRUE''|Dieses [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631700/PredefinedBeans|Predicate]] legt fest, ob nach erfolgreicher Authentifizierung ein [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631602/AttributePostLoginC14NConfiguration|UsernamePrincipal]] dem Subject hinzugefügt wird. Per Default enthält das Authentifizierungsergebnis nach erfolgreicher Authentifizierung mit dem fudiscr-Plugin einen [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631602/AttributePostLoginC14NConfiguration|UsernamePrincipal]].| | |''fudiscr.result_with_username_principal''|''shibboleth.Conditions.TRUE''|Dieses [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631700/PredefinedBeans|Predicate]] legt fest, ob nach erfolgreicher Authentifizierung ein [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631602/AttributePostLoginC14NConfiguration|UsernamePrincipal]] dem Subject hinzugefügt wird. Per Default enthält das Authentifizierungsergebnis nach erfolgreicher Authentifizierung mit dem fudiscr-Plugin einen [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631602/AttributePostLoginC14NConfiguration|UsernamePrincipal]].| |
|''fudiscr.result_with_realm_in_username_principal''|''shibboleth.Conditions.TRUE''|Ab fudiscr-Version 1.3.0: Wenn mit ''fudiscr.result_with_username_principal'' ein [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631602/AttributePostLoginC14NConfiguration|UsernamePrincipal]] erzeugt wird, dann legt diese [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631700/PredefinedBeans|Predicate]] fest, ob der Realm enthalten ist. ''TRUE'' (default) erzeugt z.B. //dummy@fu-berlin.de//, ''FALSE'' nur //dummy// als Username.| | |''fudiscr.result_with_realm_in_username_principal''|''shibboleth.Conditions.TRUE''|Ab fudiscr-Version 1.3.0: Wenn mit ''fudiscr.result_with_username_principal'' ein [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631602/AttributePostLoginC14NConfiguration|UsernamePrincipal]] erzeugt wird, dann legt dieses [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631700/PredefinedBeans|Predicate]] fest, ob der Realm enthalten ist. ''TRUE'' (default) erzeugt z.B. //dummy@fu-berlin.de//, ''FALSE'' nur //dummy// als Username.| |
|''fudiscr.result_idp_attribute_principal_attribute_name''|//leer//|Wird mit dieser Option ein Attributname angeben, so wird ein [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631557/PrincipalNameAttributeDefinition|IdpAttributePrincipal]] mit diesem Attributnamen dem erfolgreichen Authentifizierungsergebnis des fudiscr-Plugins hinzugefügt. Der Attributwert enthält die ID/Seriennummer des Token, mit dem die Authentifizierung erfolgt ist.| | |''fudiscr.result_idp_attribute_principal_attribute_name''|//leer//|Wird mit dieser Option ein Attributname angeben, so wird ein [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631557/PrincipalNameAttributeDefinition|IdpAttributePrincipal]] mit diesem Attributnamen dem erfolgreichen Authentifizierungsergebnis des fudiscr-Plugins hinzugefügt. Der Attributwert enthält die ID/Seriennummer des Token, mit dem die Authentifizierung erfolgt ist.| |
|''fudiscr.result_idp_attribute_principal_attribute_name_for_token_type''|//leer//|Ab fudiscr-Version 1.3.0: Wird mit dieser Option ein Attributname angeben, so wird ein [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631557/PrincipalNameAttributeDefinition|IdpAttributePrincipal]] mit diesem Attributnamen dem erfolgreichen Authentifizierungsergebnis des fudiscr-Plugins hinzugefügt. Der Attributwert enthält den Tokentyp des Token, mit dem die Authentifizierung erfolgt ist.| | |''fudiscr.result_idp_attribute_principal_attribute_name_for_token_type''|//leer//|Ab fudiscr-Version 1.3.0: Wird mit dieser Option ein Attributname angeben, so wird ein [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631557/PrincipalNameAttributeDefinition|IdpAttributePrincipal]] mit diesem Attributnamen dem erfolgreichen Authentifizierungsergebnis des fudiscr-Plugins hinzugefügt. Der Attributwert enthält den Tokentyp des Token, mit dem die Authentifizierung erfolgt ist.| |
|''fudiscr.privacyidea.preferred_parameter_name''|//leer//|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.preferred_parameter_name''|//leer//|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.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.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.user_agent_ip_address_parameter_''|//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.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.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.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.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 Tokentypen //hotp//, //indexed_tan//, //registration_code//, //tan//, //totp// und //yubikey_otp// wird diese Funktionalität unterstützt. (Bis fudiscr-Version 1.2.0 wurde diese Option unter dem Namen ''fudiscr.with_additional_pin_response'' geführt.)| | |''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 Tokentypen //hotp//, //indexed_tan//, //registration_code//, //tan//, //totp// und //yubikey_otp// wird diese Funktionalität unterstützt. (Bis fudiscr-Version 1.2.0 wurde diese Option unter dem Namen ''fudiscr.with_additional_pin_response'' geführt.)| |
In diesem Beispiel werden Token anhand einer Tokeneigenschaft herausgefiltert. In 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 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 Tokeneigenschaft herausgefiltert. In 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 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. |
| |
(Mit dem Bean-Setter ''p:negateResult="true"'' kann das Ergbnis eines //ExcludeTokenPredicates// negiert werden.) | (Mit dem Konstruktor-Parameter ''c:negateResult="true"'' kann das Ergbnis eines //ExcludeTokenPredicates// negiert werden.) |
| |
=== Filterung von Token für die Funtkion fudiscr.UserHasTokenPredicate (ab Version 1.3.0) === | === Filterung von Token für die Funtkion fudiscr.UserHasTokenPredicate (ab Version 1.3.0) === |
<bean class="de.zedat.fudis.shibboleth.idp.plugin.authn.fudiscr.function.impl.RegexExcludeTokenPropertiesPredicate" | <bean class="de.zedat.fudis.shibboleth.idp.plugin.authn.fudiscr.function.impl.RegexExcludeTokenPropertiesPredicate" |
c:propertyName="info:fudis_preferred" | c:propertyName="info:fudis_preferred" |
c:excludePattern="^(?i)true$" | c:excludePattern="^(?i)false$" |
p:negateResult="true"/> | p:returnValueForNullInput="false"/> |
<bean class="de.zedat.fudis.shibboleth.idp.plugin.authn.fudiscr.function.impl.RegexExcludeTokenPropertiesPredicate" | <bean class="de.zedat.fudis.shibboleth.idp.plugin.authn.fudiscr.function.impl.RegexExcludeTokenPropertiesPredicate" |
c:propertyName="tokentype" | c:propertyName="type" |
c:excludePattern="^totp$" | c:excludePattern="^totp$" |
p:negateResult="true"/> | c:negateResult="true"/> |
</util:list> | </util:list> |
</file> | </file> |
Das Beispiel filtert alle Token heraus, die nicht das Token-Info-Attribut ''fudis_preferred'' mit dem Wert ''true'' (case-insensitive) und nicht vom Typ 'totp' sind. Bitte beachten Sie, dass durch ''p:negateResult="true"'' aus einem Exclude eine Include wird. In dem Beispiel werden im Gegensatz zu den vorherigen Filterbeispielen die Beans direkt in der Liste und nicht als Referenzen definiert. | Das Beispiel filtert alle Token heraus, die nicht das Token-Info-Attribut ''fudis_preferred'' mit dem Wert ''true'' (case-insensitive) und nicht vom Typ 'totp' sind. ''p:returnValueForNullInput="false"'' bewirkt, dass das //RegexExcludeTokenPropertiesPredicate// bei fehlendem Token-(Info-)Attribut //false// zurückgibt. Bitte beachten Sie, dass durch ''c:negateResult="true"'' aus einem Exclude eine Include wird. In dem Beispiel werden im Gegensatz zu den vorherigen Filterbeispielen die Beans direkt in der Liste und nicht als Referenzen definiert. |
| |
=== Realm-Transformation (ab Version 1.3.0) === | === Realm-Transformation (ab Version 1.3.0) === |
</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 === |
<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> |
| |
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]] |