Hinweise zum Schreiben von Richtlinien für native Anwendungen
Richtlinien für native Anwendungen wenden Regeln für den ersten Faktor an, bevor sich der Benutzer authentifiziert. Nach der Benutzerauthentifizierung können konventionelle MFA-Regeln angewendet werden.
Regeln für den ersten Faktor schreiben
- Zugriff auf der Basis des bereitgestellten Kontextes verweigern
- Beispielsweise eine einfache Geoortungsregel, die Zugriff nur von einem bestimmten Standort erfordert.
- Vorgehensweise zum Ausführen der Authentifizierung eines Benutzers mit dem ersten Faktor ändern
- Wenn sich ein Benutzer beispielsweise nicht im Unternehmensnetz befindet (IP-Regel), muss FIDO2 als Alternative zur Kennwortauthentifizierung verwendet werden.
Regeln für den ersten Faktor werden nur in Abläufen verwendet, in denen der Erteilungstyp
policyauth verwendet wird. Wenn Erteilungen des Typs password oder nicht
angeforderte Erteilungen des Typs jwtBearer verwendet werden, werden Regeln für den zweiten Faktor
erst verwendet, nachdem der ursprüngliche authentifizierte Kontext validiert wurde.
Bedingungen für den ersten Faktor schreiben
- Kontextbedingungen
- Abhängig von dem in der Anforderung an
/tokenbereitgestellten Kontext - Kann zum Ändern der Richtlinie auf der Basis des Typs von OAuth-Ablauf, der ausgeführt wird, verwendet werden
- Abhängig von dem in der Anforderung an
- IP-Bedingungen
- Standortbedingungen
Regeln für den zweiten Faktor schreiben
Das Erstellen von Regeln für den zweiten Faktor bleibt für API-gesteuerte Erteilungstypen unverändert. Es unterscheidet sich jedoch von einem konventionellen Browser-SSO-Ablauf. In dem konventionellen Ablauf wird der Geltungsbereich des Kontextes, auf den die Zugriffsrichtlinie (das heißt die Sitzung) angewendet wird, der Sitzung des Browsers zugeordnet. Bei einem API-gesteuerten Erteilungstyp wird der Geltungsbereich des Kontextes der Lebensdauer der gesamten OAuth-Erteilung zugeordnet, die einen viel größeren Zeithorizont umfassen kann.