Citrix ADC

nFactor Konzepte, Entitäten und Terminologie

In diesem Thema werden einige der wichtigsten Entitäten, die an der nFactor-Authentifizierung beteiligt sind, und ihre Bedeutung erfasst.

Login-Schema

nFactor entkoppelt die ‘Ansicht’, die Benutzeroberfläche, mit dem ‘Modell’, das die Laufzeitbehandlung ist. nFactor’s View ist durch Login-Schema definiert’. Anmeldeschema ist eine Entität, die definiert, was Benutzer sieht und angibt, wie die Daten aus dem Benutzer extrahiert werden.

Zum Definieren der Ansicht zeigt das Anmeldeschema auf eine Datei auf dem Datenträger, die das Anmeldeformular definiert. Diese Datei sollte der Spezifikation von 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 zu lesen. Diese Ausdrücke sind optional und können weggelassen werden, wenn Benutzername und Kennwort des Benutzers mit erwarteten Formularvariablennamen eintreffen.

Das Anmeldeschema definiert auch, ob der aktuelle Satz von Anmeldeinformationen als Standard-SingleSignon-Anmeldeinformationen verwendet werden soll.

Richtlinienbezeichnung

Ein Richtlinienlabel ist eine Sammlung von Richtlinien. Es handelt sich um 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 zu bestimmen, ob die Anmeldeinformationen des Benutzers erfüllt sind. Alle Richtlinien in einem Richtlinienlabel können als homogen betrachtet werden. Die Richtlinienbezeichnung für die Authentifizierung kann keine Richtlinien unterschiedlichen Typs annehmen, z. Um auf eine andere Weise zu setzen, validieren alle Richtlinien in einem Richtlinienlabel hauptsächlich dasselbe Kennwort/dieselben Anmeldeinformationen vom Benutzer. Das Ergebnis von Richtlinien in einem PolicyLabel folgt der logischen ODER-Bedingung. Wenn die von der ersten Richtlinie angegebene Authentifizierung erfolgreich ist, werden daher andere Richtlinien übersprungen.

Die Richtlinienbezeichnung kann durch Ausführen des folgenden CLI-Befehls erstellt werden:

add authentication policy label mylabel –loginSchema <>

Eine Richtlinienbezeichnung nimmt das Anmeldeschema als Eigenschaft an. Das Anmeldeschema definiert die Ansicht für diese Richtlinienbezeichnung. Wenn kein Anmeldeschema angegeben ist, wird dieser Richtlinienbezeichnung ein implizites Anmeldeschema LSCHEMA_INT zugeordnet. Das Anmeldeschema entscheidet, ob eine Richtlinienbezeichnung ein Passthrough wird oder nicht.

Bezeichnung für virtuelle Server

In der erweiterten Richtlinieninfrastruktur von Citrix ADC ist ein virtueller Server auch eine implizite Richtlinienbezeichnung. Das liegt daran, dass der virtuelle Server auch an mehrere Richtlinien gebunden werden kann. Ein virtueller Server ist jedoch besonders, da er der Einstiegspunkt für Clientdatenverkehr ist und Richtlinien eines anderen Typs übernehmen kann. Jede der Richtlinien, die es unter einem eigenen Label innerhalb des virtuellen Servers gesetzt hat. Daher ist virtueller Server eine Konglomeration von Labels.

Nächster Faktor

Wenn eine Richtlinie an einen virtuellen Server oder eine Richtlinienbezeichnung gebunden ist, kann sie mit dem nächsten Faktor angegeben werden. Der nächste Faktor bestimmt, was getan werden soll, wenn eine bestimmte Authentifizierung erfolgreich ist. Wenn es keinen nächsten Faktor gibt, wird der Authentifizierungsprozess für diesen Benutzer abgeschlossen.

Jede Richtlinie, die an einen virtuellen Server oder eine Richtlinienbezeichnung gebunden ist, kann einen anderen nächsten Faktor haben. Dies ermöglicht ultimative Flexibilität, bei der im 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.

No-Auth Richtlinie

nFactor führt eine spezielle Art integrierter Richtlinie namens NO_AUTHN ein. NO_AUTHN-Richtlinie gibt immer Erfolg als Authentifizierungsergebnis zurück. No-Auth-Richtlinie kann durch Ausführen des folgenden CLI-Befehls erstellt werden:

add authentication policy noauthpolicy –rule <> -action NO_AUTHN

Gemäß dem Befehl nimmt die Nicht-Authentifizierungsrichtlinie eine Regel an, die ein beliebiger erweiterter Richtlinienausdruck sein kann. Authentifizierungsergebnis ist immer erfolgreich von NO_AUTHN.

Eine No-Auth-Richtlinie an sich scheint keinen Mehrwert zu schaffen. Wenn sie jedoch zusammen mit Passthrough-Richtlinienbeschriftungen verwendet wird, bietet sie eine große Flexibilität, logische Entscheidungen zu treffen, um den Benutzerauthentifizierungsfluss zu steuern. NO_AUTHN Richtlinien und Passthroughfaktoren bieten eine neue Dimension für die Flexibilität von nFactor.

Hinweis: Überprüfen Sie die Beispiele, die die Verwendung von no-auth und Passthrough in den nachfolgenden Abschnitten darstellen. `

Durchgangsfaktor/Etikett

Sobald der Benutzer die Authentifizierung auf dem virtuellen Server (für den ersten Faktor) übergeben hat, werden nachfolgende Authentifizierungen bei Richtlinienbeschriftungen oder benutzerdefinierten (sekundären) Faktoren durchgeführt. Jede Richtlinienbeschriftung/-faktor ist einer Anmeldeschemaentität zugeordnet, um die Ansicht für diesen Faktor anzuzeigen. Dies ermöglicht das Anpassen von Ansichten basierend auf dem Pfad, den der Benutzer verwendet hätte, um zu einem bestimmten Faktor zu gelangen.

Es gibt spezielle Arten von Richtlinienbeschriftungen, die nicht explizit auf ein Anmeldeschema verweisen. Spezialisierte Richtlinienbeschriftungen verweisen auf ein Anmeldeschema, das nicht tatsächlich auf die XML-Datei für die Ansicht verweist. Diese Richtlinienbeschriftungen/-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

Beispiel 2:

add loginschema passthrough_schema –authenticationSchema noschema

add authentication policylabel example2 –loginschema passthrough_schema

Passthrough-Faktor impliziert, dass Authentifizierung, Autorisierung und Auditing Subsystem nicht zum Benutzer zurückgehen sollte, um Anmeldeinformationen für diesen Faktor festgelegt zu erhalten. Stattdessen ist es ein Hinweis für Authentifizierung, Autorisierung und Überwachung, um mit bereits erhaltenen Anmeldeinformationen fortzusetzen. Dies ist nützlich, wenn ein Benutzereingriff nicht erwünscht ist. Beispiel:

  • Wenn der Benutzer zwei Kennwortfelder angezeigt wird. Nach dem ersten Faktor benötigt der zweite Faktor keinen Benutzereingriff

  • Wenn die Authentifizierung eines Typs (z. B. Zertifikat) abgeschlossen ist und der Administrator Gruppen für diesen Benutzer extrahieren muss.

Passthrough-Faktor kann mit der NO_AUTH -Richtlinie verwendet werden, um bedingte Sprünge durchzuführen.

nFactor-Authentifizierungsfluss

Die Authentifizierung beginnt immer am 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 bereitgestellt. Das Anmeldeformular, das Benutzer sieht, kann auf dem virtuellen Server mithilfe von Anmeldeschema-Richtlinien angepasst werden. Wenn keine Login-Schema-Richtlinien vorhanden sind, werden dem Benutzer ein einzelnes Benutzernamen- und Kennwortfeld angezeigt.

Wenn dem Benutzer mehr als ein Kennwortfeld im angepassten Formular angezeigt werden müssen, müssen Anmeldeschema-Richtlinien 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 Benutzeranmeldeinformationen gebucht werden, beginnt die Authentifizierung bei der Authentifizierung virtueller Server, der erste Faktor. Da der virtuelle Authentifizierungsserver mit mehreren Richtlinien konfiguriert werden kann, wird jeder von ihnen in einer Sequenz ausgewertet. Wenn eine Authentifizierungsrichtlinie erfolgreich ist, wird zu einem bestimmten Zeitpunkt der nächste für sie angegebene Faktor verwendet. Wenn kein nächster Faktor vorhanden ist, endet der Authentifizierungsprozess. Wenn der nächste Faktor vorhanden ist, wird geprüft, ob dieser Faktor ein Passthrough-Faktor oder ein regulärer Faktor ist. Wenn es sich um Passthrough handelt, werden Authentifizierungsrichtlinien für diesen Faktor ohne Benutzereingriff ausgewertet. Andernfalls wird dem Benutzer das mit diesem Faktor verknüpfte Anmeldeschema angezeigt.

Beispiel für die Verwendung von Passthrough-Faktor- und No-Auth-Richtlinien, 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

nFactor Konzepte, Entitäten und Terminologie