nFactor Konzepte, Entitäten und Terminologie
In diesem Thema werden einige der wichtigsten an der nFactor-Authentifizierung beteiligten Entitäten und ihre Bedeutung beschrieben.
Login-Schema
nFactor entkoppelt die ‘Ansicht’, die Benutzeroberfläche, mit dem ‘Modell’, das die Laufzeitbehandlung darstellt. Die Ansicht von nFactor wird durch das Anmeldeschema definiert. Das Anmeldeschema ist eine Entität, die definiert, was der Benutzer sieht, und angibt, wie die Daten aus dem Benutzer extrahiert werden.
Zum Definieren einer Ansicht verweist das Anmeldeschema auf eine Datei auf dem Datenträger, der das Anmeldeformular definiert. Diese Datei muss der Spezifikation des “Citrix Common Forms Protocol” entsprechen. Diese Datei ist im Wesentlichen eine XML-Definition des Anmeldeformulars.
Zusätzlich zur XML-Datei enthält das Anmeldeschema erweiterte Richtlinienausdrücke, um Benutzernamen und Kennwort aus der Anmeldeanforderung des Benutzers abzurufen. Diese Ausdrücke sind optional und können weggelassen werden, wenn Benutzername und Kennwort des Benutzers mit den erwarteten Variablennamen in Form kommen.
Das Anmeldeschema definiert auch, ob der aktuelle Satz von Anmeldeinformationen als standardmäßige SingleSignOn-Anmeldeinformationen verwendet werden muss.
Das Anmeldeschema kann durch Ausführen des folgenden CLI-Befehls erstellt werden:
add authentication loginSchema <name> -authenticationSchema <string> [-userExpression <string>] [-passwdExpression <string>] [-userCredentialIndex <positive_integer>] [-passwordCredentialIndex <positive_integer>] [-authenticationStrength <positive_integer>] [-SSOCredentials ( YES | NO )]
<!--NeedCopy-->
Hinweis:
SSOCredentials geben an, ob die aktuellen Faktor-Anmeldeinformationen die standardmäßigen SSO-Anmeldeinformationen sind. Der Standardwert ist NEIN.
In der nFactor-Authentifizierungskonfiguration werden die letzten Faktor-Anmeldeinformationen standardmäßig für SSO verwendet. Mithilfe der Konfiguration “ ssoCredentials “ können Anmeldeinformationen für den aktuellen Faktor verwendet werden. Falls diese Konfiguration auf verschiedene Faktoren festgelegt ist, hat der letzte Faktor, für den diese Konfiguration festgelegt ist, die Priorität.
Einzelheiten zu den einzelnen Parametern finden Sie unter https://developer-docs.citrix.com/projects/citrix-adc-command-reference/en/13/authentication/authentication-loginSchema/#add-authentication-loginS.
Bezeichnung der Richtlinie
Ein Policy Label ist eine Sammlung von Richtlinien. Es ist ein Konstrukt, das der Richtlinieninfrastruktur von Citrix ADC nicht fremd ist. Die Richtlinienbezeichnung definiert einen Authentifizierungsfaktor. Das heißt, es enthält alle Richtlinien, die erforderlich sind, um festzustellen, ob die Anmeldeinformationen des Benutzers erfüllt sind. Alle Richtlinien in einem Policy Label können als homogen angenommen werden. Die Richtlinienbezeichnung für die Authentifizierung kann keine Richtlinien unterschiedlichen Typs annehmen, z. B. Um es anders auszudrücken, überprüfen alle Richtlinien in einem Policy Label meistens dasselbe Kennwort/dieselben Anmeldeinformationen des Benutzers. Das Ergebnis von Richtlinien in einem PolicyLabel folgt der logischen ODER-Bedingung. Wenn die in der ersten Richtlinie angegebene Authentifizierung erfolgreich ist, werden andere darauf folgende Richtlinien übersprungen.
Die Richtlinienbezeichnung kann durch Ausführen des folgenden CLI-Befehls erstellt werden:
add authentication policy label mylabel –loginSchema <>
<!--NeedCopy-->
Ein Policy Label verwendet das Anmeldeschema als Eigenschaft. Das Anmeldeschema definiert die Ansicht für dieses Policy Label. Wenn das Anmeldeschema nicht angegeben ist, wird ein implizites Anmeldeschema, LSCHEMA_INT, mit dieser Policy Label verknüpft. Das Anmeldeschema entscheidet, ob ein Policy Label zu einem Passthrough wird oder nicht.
Virtuelles Serverlabel
In der erweiterten Richtlinieninfrastruktur von Citrix ADC ist ein virtueller Server auch eine implizite Policy Label. Das liegt daran, dass der virtuelle Server auch mit mehr als einer Richtlinie gebunden werden kann. Ein virtueller Server ist jedoch etwas Besonderes, da er der Einstiegspunkt für den Clientverkehr ist und Richtlinien eines anderen Typs annehmen kann. Jede der Richtlinien, die es unter einem eigenen Label innerhalb des virtuellen Servers platziert hat. Daher ist der virtuelle Server ein Konglomerat von Labels.
Der nächste Faktor
Immer wenn eine Richtlinie an einen virtuellen Server oder eine Policy Label gebunden ist, kann sie mit dem nächsten Faktor angegeben werden. Der nächste Faktor bestimmt, was getan werden muss, wenn eine bestimmte Authentifizierung erfolgreich ist. Wenn es keinen nächsten Faktor gibt, ist damit der Authentifizierungsprozess für diesen Benutzer abgeschlossen.
Jede Richtlinie, die an einen virtuellen Server oder eine Policy Label gebunden ist, kann einen anderen nächsten Faktor haben. Dies ermöglicht ultimative Flexibilität, bei der der Erfolg jeder Richtlinie einen neuen Pfad für die Benutzerauthentifizierung definieren kann. Der Administrator kann diese Tatsache nutzen und clevere Fallback-Faktoren für Benutzer erstellen, die bestimmte Richtlinien nicht erfüllen.
Richtlinie ohne Authentifizierung
nFactor führt eine spezielle integrierte Richtlinie namens NO_AUTHN ein. Die Richtlinie NO_AUTHN gibt immer Erfolg als Authentifizierungsergebnis zurück. No-auth Policy kann erstellt werden, indem der folgende CLI-Befehl ausgeführt wird:
add authentication policy noauthpolicy –rule <> -action NO_AUTHN
<!--NeedCopy-->
Gemäß dem Befehl benötigt die no-authentication Richtlinie eine Regel, die ein beliebiger erweiterter Richtlinienausdruck sein kann. Das Authentifizierungsergebnis ist von NO_AUTHN immer erfolgreich.
Eine no-auth-Richtlinie an sich scheint keinen Mehrwert zu bieten. Wenn sie jedoch zusammen mit Passthrough-Richtlinienbezeichnungen verwendet wird, bietet es eine große Flexibilität, logische Entscheidungen zu treffen, um den Fluss der Benutzerauthentifizierung zu fördern. NO_AUTHN-Richtlinien und Passthrough-Faktoren bieten eine neue Dimension der Flexibilität von nFactor.
Hinweis: Sehen Sie sich die Beispiele für die Verwendung von no-auth und Passthrough in den nachfolgenden Abschnitten an.
Durchgangsfaktor/Etikett
Sobald der Benutzer die Authentifizierung auf dem virtuellen Server bestanden hat (für den ersten Faktor), erfolgen nachfolgende Authentifizierungen bei Richtlinienbezeichnungen oder benutzerdefinierten (sekundären) Faktoren. Jede Richtlinienbeschriftung/jeder Faktor ist mit einer Anmeldeschemaentität verknüpft, um die Ansicht für diesen Faktor anzuzeigen. Auf diese Weise können Ansichten basierend auf dem Pfad angepasst werden, den der Benutzer eingeschlagen hätte, um zu einem bestimmten Faktor zu gelangen.
Es gibt spezielle Arten von Richtlinienbezeichnungen, die nicht explizit auf ein Anmeldeschema verweisen. Spezialisierte Richtlinienbezeichnungen verweisen auf ein Anmeldeschema, das nicht wirklich auf die XML-Datei für die Ansicht verweist. Diese Richtlinienbezeichnungen/-faktoren werden als “Passthrough” -Faktoren bezeichnet.
Passthrough-Faktoren können durch Ausführen der folgenden CLI-Befehle erstellt werden:
Beispiel 1:
add authentication policylabel example1
<!--NeedCopy-->
Beispiel 2:
add loginschema passthrough_schema –authenticationSchema noschema
add authentication policylabel example2 –loginschema passthrough_schema
<!--NeedCopy-->
Der Passthrough-Faktor impliziert, dass das Authentifizierungs-, Autorisierungs- und Überwachungssubsystem nicht an den Benutzer zurückgehen darf, um die für diesen Faktor festgelegten Anmeldeinformationen abzurufen. Stattdessen ist es ein Hinweis für Authentifizierung, Autorisierung und Überwachung, um mit bereits erhaltenen Anmeldeinformationen fortzufahren. Dies ist nützlich in Fällen, in denen ein Benutzereingriff nicht erwünscht ist. Zum Beispiel:
-
Wenn dem Benutzer zwei Kennwortfelder angezeigt werden, benötigt der zweite Faktor nach dem ersten Faktor keinen Benutzereingriff.
-
Wenn die Authentifizierung eines Typs (z. B. eines Zertifikats) abgeschlossen ist und der Administrator Gruppen für diesen Benutzer extrahieren muss.
Der Passthrough-Faktor kann mit NO_AUTH Richtlinien verwendet werden, um bedingte Sprünge zu erstellen.
nFactor-Authentifizierungsablauf
Die Authentifizierung beginnt immer auf dem virtuellen Server in nFactor. Virtueller Server definiert den ersten Faktor für den Benutzer. Das erste Formular, das der Benutzer sieht, wird vom virtuellen Server bedient. Das Anmeldeformular, das der Benutzer sieht, kann auf dem virtuellen Server mithilfe von Anmeldeschemarichtlinien angepasst werden. Wenn es keine Richtlinien für Anmeldeschemas gibt, werden dem Benutzer ein einziger Benutzername und ein Kennwortfeld angezeigt.
Wenn dem Benutzer mehr als ein Kennwortfeld in einem angepassten Formular angezeigt werden muss, müssen Richtlinien für das Anmeldeschema verwendet werden. Sie ermöglichen die Anzeige verschiedener Formulare basierend auf den konfigurierten Regeln (z. B. Intranetbenutzer im Vergleich zu externen Benutzern, Dienstanbieter A im Vergleich zu Dienstanbieter B).
Sobald die Benutzeranmeldeinformationen veröffentlicht wurden, beginnt die Authentifizierung beim virtuellen Authentifizierungsserver, dem ersten Faktor. Da der virtuelle Authentifizierungsserver mit mehreren Richtlinien konfiguriert werden kann, wird jede von ihnen in einer Reihenfolge ausgewertet. Zu einem bestimmten Zeitpunkt, wenn eine Authentifizierungsrichtlinie erfolgreich ist, wird der nächste dafür angegebene Faktor verwendet. Wenn es keinen nächsten Faktor gibt, wird der Authentifizierungsvorgang beendet. Wenn der nächste Faktor existiert, wird geprüft, ob dieser Faktor ein Passthrough-Faktor oder ein regulärer Faktor ist. Wenn das Passthrough ist, werden Authentifizierungsrichtlinien für diesen Faktor ohne Benutzereingriff ausgewertet. Andernfalls wird das mit diesem Faktor verknüpfte Anmeldeschema dem Benutzer angezeigt.
Beispiel für die Verwendung von Passthrough-Faktor und Richtlinien ohne Authentifizierung, um logische Entscheidungen zu treffen
Der Administrator möchte NextFactor basierend auf Gruppen entscheiden.
add authentication policylabel group check
add authentication policy admin group –rule http.req.user.is_member_of("Administrators") –action NO_AUTHN
add authentication policy nonadmins –rule true –action NO_AUTHN
bind authentication policy label group check –policy admingroup –pri 1 –nextFactor factor-for-admin
bind authentication policy label groupcheck –policy nonadmins –pri 10 –nextfactor factor-for-others
add authentication policy first_factor_policy –rule <> -action <>
bind authentication vserver <> -policy first_factor_policy –priority 10 –nextFactor groupcheck
<!--NeedCopy-->