AAA-Datenverkehrsmodul validiertes Referenzdesign

Citrix ADC-Zusammenfassung

Citrix ADC ist ein All-in-One-Application Delivery Controller, mit dem Anwendungen bis zu fünf Mal besser ausgeführt werden, die Betriebskosten für Anwendungen reduziert, die Benutzerfreundlichkeit optimiert und sichergestellt wird, dass Anwendungen immer verfügbar sind:

• Erweiterter L4-7 Lastausgleich und Verkehrsmanagement

• Bewährte Anwendungsbeschleunigung wie HTTP-Komprimierung und Caching

• Integrierte Anwendungsfirewall für Anwendungssicherheit

• Serveroffloading zur deutlichen Kostensenkung und Konsolidierung von Servern

Als unbestrittener Marktführer bei der Bereitstellung von Diensten und Anwendungen wird Citrix ADC in Tausenden von Netzwerken auf der ganzen Welt eingesetzt, um die Bereitstellung aller Unternehmens- und Cloud-Services zu optimieren, zu sichern und zu steuern. Citrix ADC wird direkt vor Web- und Datenbankservern bereitgestellt und kombiniert High-Speed-Lastausgleich und Content-Switching, HTTP-Komprimierung, Content-Caching, SSL-Beschleunigung, Transparenz des Anwendungsflusses und eine leistungsstarke Anwendungsfirewall zu einer integrierten, benutzerfreundlichen Plattform. Die Erfüllung von SLAs wird durch eine durchgängige Überwachung erheblich vereinfacht, die Netzwerkdaten in umsetzbare Business Intelligence umwandelt. Citrix ADC ermöglicht die Definition und Verwaltung von Richtlinien mithilfe einer einfachen deklarativen Policy-Engine ohne Programmierkenntnisse.

Citrix ADC AAA-TM-Modul

Verkehrsmanagement

AAA bietet Sicherheit für eine verteilte Internetumgebung, da jeder Client mit den richtigen Anmeldeinformationen eine sichere Verbindung zu geschützten Anwendungsservern von überall im Internet ermöglicht. Diese Funktion enthält die drei Sicherheitsfunktionen Authentifizierung, Autorisierung und Überwachung. Mithilfe der Authentifizierung kann Citrix ADC die Anmeldeinformationen des Clients entweder lokal oder mit einem Authentifizierungsserver eines Drittanbieters überprüfen. Es erlaubt nur genehmigten Benutzern, auf geschützte Server zuzugreifen. Mit der Autorisierung kann der ADC überprüfen, auf welche Inhalte auf einem geschützten Server jeder Benutzer zugreifen darf. Die Überwachung ermöglicht es dem ADC, die Aktivitäten jedes Benutzers auf einem geschützten Server aufzuzeichnen.

Citrix Gateway

Unternehmen können jetzt Verbund- und Single Sign-On für Unternehmen, Web, SaaS und lokale virtuelle Anwendungen und Desktops über Citrix Gateway erreichen. Citrix Gateway nutzt seine Authentifizierungs-, Autorisierungs- und Auditing-Funktionen (AAA) mit Content Switching, damit Benutzer über ein einziges Gateway und eine einzige URL auf alle ihre autorisierten Unternehmensanwendungen zugreifen können. Unternehmen, die Citrix ADC heute für ihre Infrastruktur für virtuelle Apps und Desktops bereitstellen, können ihre Funktionalität für einmaliges Anmelden auf einfache Weise auf Enterprise-Legacy-, Web-, Virtual und Public, Private und Hybrid Cloud-Anwendungen erweitern. Kunden, die Single-Sign-On- und Anwendungsbereitstellungslösungen und Gateways von Drittanbietern verwenden, können eine einzige Lösung für alle ihre Single Sign-On-Anforderungen bereitstellen, indem sie auf Citrix Gateway konsolidieren.

Zu den Authentifizierungsmechanismen gehören LDAP, RADIUS, SAML, Kerberos, zertifikatbasierte Authentifizierung und mehr.

Der Authentifizierungsmechanismus, der auf einem virtuellen Citrix Gateway-Server konfiguriert wird, bevor das Upgrade verwendet wird, wird automatisch verwendet, wenn der virtuelle Citrix Gateway-Server hinter dem virtuellen Unified Gateway-Server platziert wird.

Es sind keine weiteren Konfigurationsschritte erforderlich, außer dem Zuweisen einer nicht adressierbaren IP-Adresse (0.0.0.0) zum virtuellen Citrix Gateway-Server.

Authentifizierungsübersicht

Um zu verstehen, wie AAA in einer verteilten Umgebung funktioniert, sollten Sie eine Organisation mit einem Intranet betrachten, auf das ihre Mitarbeiter im Büro, zu Hause und unterwegs zugreifen können. Der Inhalt im Intranet ist vertraulich und erfordert einen sicheren Zugriff. Jeder Benutzer, der auf das Intranet zugreifen möchte, muss über einen gültigen Benutzernamen und ein gültiges Kennwort verfügen. Um diese Anforderungen zu erfüllen, führt der ADC folgende Schritte aus:

• Leitet den Benutzer auf die Anmeldeseite um, wenn der Benutzer auf das Intranet zugreift, ohne sich angemeldet zu haben.

• Sammelt die Anmeldeinformationen des Benutzers, übermittelt sie an den Authentifizierungsserver und speichert sie in einem Verzeichnis, auf das über LDAP zugegriffen werden kann.

• Überprüft, ob der Benutzer berechtigt ist, auf bestimmte Intranetinhalte zuzugreifen, bevor er die Anforderung des Benutzers an den Anwendungsserver übermittelt.

• Behält ein Sitzungszeitlimit bei, nach dem sich Benutzer erneut authentifizieren müssen, um den Zugriff auf das Intranet wiederherzustellen. (Sie können das Timeout konfigurieren.)

• Protokolliert die Zugriffsberechtigung des Benutzers, einschließlich ungültiger Anmeldeversuche, in einem Überwachungsprotokoll.

Die Authentifizierung erfordert, dass mehrere Entitäten: der Client, die Citrix ADC-Appliance, der externe Authentifizierungsserver, falls einer verwendet wird, und der Anwendungsserver, einander reagieren, wenn Sie dazu aufgefordert werden, indem Sie eine komplexe Reihe von Aufgaben in der richtigen Reihenfolge ausführen.

Wenn ein authentifizierter Client eine Ressource anfordert, überprüft der ADC vor dem Senden der Anforderung an den Anwendungsserver die dem Clientkonto zugeordneten Benutzer- und Gruppenrichtlinien, um zu überprüfen, ob der Client für den Zugriff auf diese Ressource berechtigt ist. Der ADC übernimmt die gesamte Autorisierung auf geschützten Anwendungsservern. Sie müssen keine spezielle Konfiguration Ihrer geschützten Anwendungsserver vornehmen.

Kennwortänderungen

AAA-TM verarbeitet Kennwortänderungen für Benutzer mithilfe der protokollspezifischen Methode für den Authentifizierungsserver. Bei den meisten Protokollen müssen weder der Benutzer noch der Administrator etwas anderes tun als ohne AAA-TM. Selbst wenn ein LDAP-Authentifizierungsserver verwendet wird und dieser Server Teil eines verteilten Netzwerks von LDAP-Servern mit einem einzelnen ausgewiesenen Domänenverwaltungsserver ist, werden Kennwortänderungen normalerweise nahtlos verarbeitet. Wenn ein authentifizierter Client eines LDAP-Servers sein Kennwort ändert, sendet der Client eine Anforderung zur Änderung der Anmeldeinformationen an AAA-TM, die sie an den LDAP-Server weiterleitet. Wenn der LDAP-Server des Benutzers auch der Domänenverwaltungsserver ist, antwortet dieser Server entsprechend, und AAA-TM führt dann die angeforderte Kennwortänderung durch. Andernfalls sendet der LDAP-Server AAA-TM eine LDAP_REFERRAL-Antwort an den Domänenverwaltungsserver. AAA-TM folgt der Verweisung auf den angegebenen Domänenverwaltungsserver, authentifiziert sich bei diesem Server und führt die Kennwortänderung auf diesem Server durch.

Hinweis:

Bei der Konfiguration von AAA-TM mit einem LDAP-Authentifizierungsserver muss der Systemadministrator die folgenden Bedingungen und Einschränkungen beachten:

• AAA-TM geht davon aus, dass der Domänenverwaltungsserver in der Verweisung dieselben Bindungsanmeldeinformationen akzeptiert wie der ursprüngliche Server.
• AAA-TM folgt nur LDAP-Empfehlungen für Kennwortänderungsvorgänge. In anderen Fällen weigert sich AAA-TM, der Empfehlung zu folgen.
• AAA-TM folgt nur einer Ebene von LDAP-Empfehlungen. Wenn der zweite LDAP-Server auch eine Empfehlung zurückgibt, weigert sich AAA-TM, der zweiten Empfehlung zu folgen.

Unterstützung für Audit-/Protokollierung

Der ADC unterstützt die Überwachung aller Zustände und Statusinformationen, so dass Sie die Details der einzelnen Benutzer während der Anmeldung in chronologischer Reihenfolge sehen können. Um diese Informationen bereitzustellen, protokolliert die Appliance jedes Ereignis bei Auftreten entweder in einer bestimmten Überwachungsprotokolldatei auf der Appliance oder auf einem Syslog-Server. Die Überwachung erfordert die Konfiguration der Appliance und aller verwendeten Syslog-Server.

Einschränkungen und Nutzungsrichtlinien

Authentifizierungsmatrix:

Eine öffentliche IP für AAA-TM-Bereitstellungen auf Citrix ADC

Citrix ADC unterstützt AAA-Framework für virtuelle Server (Traffic Management) (fortan vserver genannt), indem verschiedene vom Authentifizierungssubsystem unterstützte AAA-Funktionen genutzt werden. Der Server, der für die Authentifizierung verwendet wird, heißt “authentication vserver” oder AAA vserver.

Citrix ADC kann das obige Bild zu einem öffentlichen Endpunkt konsolidieren, indem die Authentifizierung vserver neben TM vserver verschoben wird, sodass ein öffentlicher Endpunkt und ein Zertifikat vorhanden ist. Dies ist in der folgenden Abbildung dargestellt:

Windows gehostete Anwendungen von Citrix Virtual Apps and Desktops

Sie können Citrix Gateway am Umfang des internen Netzwerks (oder Intranets) Ihrer Organisation bereitstellen, um einen sicheren zentralen Zugriffspunkt für die Server, Anwendungen und andere Netzwerkressourcen bereitzustellen, die sich im internen Netzwerk befinden. Alle Remotebenutzer müssen eine Verbindung zu Citrix Gateway herstellen, bevor sie auf Ressourcen im internen Netzwerk zugreifen können.

Citrix Gateway wird am häufigsten an den folgenden Speicherorten in einem Netzwerk installiert:

• Im Netzwerk DMZ

• In einem sicheren Netzwerk ohne DMZ

Sie können Citrix Gateway auch mit Citrix Virtual Apps, Virtual Desktops, StoreFront und Endpoint Management Server für Benutzer bereitstellen, um auf ihre Windows-, Web-, Mobil- und SaaS-Anwendungen zuzugreifen.

Wenn Ihre Bereitstellung Citrix Virtual Apps, StoreFront oder Virtual Desktops umfasst, können Sie Citrix Gateway in einer Single-Hop- oder Double-Hop-DMZ-Konfiguration bereitstellen. Eine Double-Hop-Bereitstellung wird in früheren Versionen von Virtual Desktops oder Virtual Apps nicht unterstützt.

SAML 2.0 SaaS-Anwendungen

Security Assertion Markup Language (SAML) ist ein XML-basierter Authentifizierungsmechanismus, der Single Sign-On-Funktionen bietet und vom OASIS Security Services Technical Committee definiert wird.

Warum SAML? Betrachten Sie ein Szenario, in dem ein Dienstanbieter (LargeProvider) eine Reihe von Anwendungen für einen Kunden (BigCompany) hostet. BigCompany hat Benutzer, die nahtlos auf diese Anwendungen zugreifen müssen. In einem traditionellen Setup müsste LargeProvider eine Datenbank mit Benutzern von BigCompany pflegen. Dies wirft Bedenken für jeden der folgenden Interessengruppen auf:

• LargeProvider muss die Sicherheit der Benutzerdaten gewährleisten.

• BigCompany muss die Benutzer validieren und die Benutzerdaten auf dem neuesten Stand halten, nicht nur in der eigenen Datenbank, sondern auch in der von LargeProvider verwalteten Benutzerdatenbank. Beispielsweise muss ein Benutzer, der aus der BigCompany-Datenbank entfernt wurde, ebenfalls aus der LargeProvider-Datenbank entfernt werden.

• Ein Benutzer muss sich bei jeder der gehosteten Anwendungen einzeln anmelden.

Der SAML-Authentifizierungsmechanismus bietet einen alternativen Ansatz. Das folgende Bereitstellungsdiagramm zeigt, wie SAML funktioniert:

Die durch traditionelle Authentifizierungsmechanismen aufgeworfenen Bedenken werden wie folgt gelöst:

• LargeProvider muss keine Datenbank für BigCompany Benutzer pflegen. Von Identitätsmanagement befreit, kann sich Large Provider auf bessere Dienste konzentrieren.

• BigCompany trägt nicht die Last, sicherzustellen, dass die LargeProvider-Benutzerdatenbank mit ihrer eigenen Benutzerdatenbank synchronisiert ist.

• Ein Benutzer kann sich einmal bei einer Anwendung anmelden, die auf LargeProvider gehostet wird, und automatisch bei den anderen dort gehosteten Anwendungen angemeldet werden.

Die Citrix ADC-Appliance kann als SAML Service Provider (SP) und SAML Identity Provider (IdP) bereitgestellt werden. Lesen Sie die relevanten Themen, um die Konfigurationen zu verstehen, die auf der Citrix ADC-Appliance ausgeführt werden müssen.

Integration von ADFS Hybrid Cloud

AD FS ist ein standardbasierter Dienst, der die sichere Freigabe von Identitätsinformationen zwischen vertrauenswürdigen Geschäftspartnern (bekannt als Verbund) über ein Extranet ermöglicht. Wenn ein Benutzer von einem seiner Verbundpartner auf eine Webanwendung zugreifen muss, ist die eigene Organisation des Benutzers verantwortlich für die Authentifizierung des Benutzers und die Bereitstellung von Identitätsinformationen in Form von “Claims” für den Partner, der die Webanwendung hostet. Der Hosting-Partner verwendet seine Vertrauensrichtlinie, um die eingehenden Ansprüche den Ansprüchen zuordnen, die von seiner Webanwendung verstanden werden, die die Ansprüche verwendet, um Autorisierungsentscheidungen zu treffen.

Active Directory-Verbunddienste (Active Directory-Verbunddienste, AD FS) ermöglicht es lokalen Benutzern und Verbundbenutzern, anspruchsbasierte Single Sign-On (SSO) für Websites und Dienste zu verwenden. Mit AD FS können Sie Ihre Organisation mithilfe des Identitätsverbunds sicher über Active Directory-Domänen hinweg mit anderen externen Organisationen zusammenarbeiten. Dies reduziert die Notwendigkeit für doppelte Konten, die Verwaltung mehrerer Anmeldungen und andere Probleme bei der Verwaltung von Anmeldeinformationen, die auftreten können, wenn Sie organisationsübergreifende Vertrauensstellungen einrichten.

ADFS-Proxymodus

Der AD FS 2.0-Proxy ist ein Dienst, der eine Verbindung zwischen externen Benutzern und Ihrem internen AD FS 2.0-Server vermittelt. Es fungiert als Reverse-Proxy und befindet sich in der Regel im Umkreisnetzwerk Ihrer Organisation (auch bekannt als DMZ). Was die Benutzer betrifft, wissen sie nicht, dass sie mit einem AD FS-Proxyserver sprechen, da die Verbunddienste über dieselben URLs zugegriffen werden. Der Proxy-Server verarbeitet drei primäre Funktionen.

• Assertion-Provider: Der Proxy akzeptiert Tokenanforderungen von Benutzern und übergibt die Informationen über SSL (Standardport 443) an den internen AD FS-Server. Es empfängt das Token vom internen AD FS-Server und gibt es an den Benutzer zurück.

• Assertion Consumer: Der Proxy akzeptiert Token von Benutzern und übergibt sie zur Verarbeitung über SSL (Standardport 443) an den internen AD FS-Server.

• Metadatenanbieter: Der Proxy reagiert auch auf Anforderungen für Verbundmetadaten.

Der AD FS 2.0-Proxy ist für die Verwendung von AD FS nicht erforderlich. Es ist eine zusätzliche Funktion. Der Grund, warum Sie einen AD FS 2.0-Proxy installieren, ist, dass Sie den tatsächlichen AD FS 2.0-Server nicht dem Internet zur Verfügung stellen möchten. AD FS 2.0-Server sind domänenverbundene Ressourcen, während der AD FS 2.0-Proxy diese Anforderung nicht hat. Wenn alle Benutzer und Anwendungen im Netzwerk intern sind, müssen Sie keinen AD FS 2.0-Proxy verwenden. Wenn der Verbunddienst im Internet verfügbar gemacht werden muss, empfiehlt es sich, einen AD FS 2.0-Proxy zu verwenden.

Weitere Informationen finden Sie unter dem folgenden LinkGrundlegendes zum AD FS 2.0-Proxy.

ADFS-IDP-Modus

Der Identity Provider (IP) des Verbundpartners sendet Ansprüche, die Identität, Gruppen und Attributdaten seiner Benutzer widerspiegeln. Daher muss Ihre Organisation die Anmeldeinformationen für die Benutzer des Partners nicht mehr widerrufen, ändern oder zurücksetzen, da die Anmeldeinformationen von der Partnerorganisation verwaltet werden. Wenn eine Partnerschaft beendet werden muss, kann sie außerdem mit einer einzigen Änderung der Vertrauensrichtlinie durchgeführt werden. Ohne AD FS müssten einzelne Konten für jeden Partnerbenutzer deaktiviert werden. Die Konfiguration als Identitätsanbieter ermöglicht die Wiederverwendung vorhandener Konten, die von vorhandenen Active Directory-Objekten verwaltet werden, zur Authentifizierung. Es entfällt die Notwendigkeit, entweder komplexe Kontosynchronisierungsmechanismen zu erstellen oder benutzerdefinierten Code zu entwickeln, der die Aufgaben erfüllt, die Anmeldeinformationen des Endbenutzers zu akzeptieren, sie anhand des Anmeldeinformationen zu validieren und die Identitäten zu verwalten.

Citrix ADC nFactor (Multifactor) -Authentifizierung

nFactor gibt eine neue Perspektive für die Authentifizierung, optimiert den Authentifizierungsablauf und bietet eine große Flexibilität bei der Authentifizierung.

Multi-Faktor-Authentifizierung erhöht die Sicherheit einer Anwendung, da Benutzer mehrere Identifikationsnachweise bereitstellen müssen, um Zugriff zu erhalten. Die Citrix ADC-Appliance bietet einen erweiterbaren und flexiblen Ansatz zur Konfiguration der Multi-Faktor-Authentifizierung. Dieser Ansatz wird nFactor-Authentifizierung genannt.

Mit der nFactor-Authentifizierung können Sie:

• Konfigurieren Sie eine beliebige Anzahl von Authentifizierungsfaktoren.

• Basieren Sie die Auswahl des nächsten Faktors auf das Ergebnis der Ausführung des vorherigen Faktors.

• Passen Sie die Anmeldeschnittstelle an. Beispielsweise können Sie die Beschriftungsnamen, Fehlermeldungen und Hilfetext anpassen. o Benutzergruppeninformationen ohne Authentifizierung extrahieren.

• Konfigurieren Sie Pass-Through für einen Authentifizierungsfaktor. Dies bedeutet, dass für diesen Faktor keine explizite Anmeldeinteraktion erforderlich ist.

• Konfigurieren Sie die Reihenfolge, in der verschiedene Authentifizierungstypen angewendet werden. Alle Authentifizierungsmechanismen, die von der Citrix ADC-Appliance unterstützt werden, können als beliebiger Faktor des nFactor-Authentifizierungs-Setups konfiguriert werden.

Diese Faktoren werden in der Reihenfolge ausgeführt, in der sie konfiguriert sind.

• Konfigurieren Sie den Citrix ADC so, dass er mit einem Authentifizierungsfaktor fortfährt, der ausgeführt werden muss, wenn die Authentifizierung fehlschlägt.

Dazu konfigurieren Sie eine andere Authentifizierungsrichtlinie mit der exakt gleichen Bedingung, jedoch mit der nächsthöchsten Priorität und mit der Aktion “NO_AUTH”.

Sie müssen auch den nächsten Faktor konfigurieren, der den anzuwendenden alternativen Authentifizierungsmechanismus angeben muss.

Unternehmensanwendungen für Kunden

Adaptive Multi-Factor Authentication (MFA) für mehr Sicherheit

Unternehmen haben mehrere Interessengruppen, die ihre Anwendungen und Daten verwenden. Mitarbeiter Partner, Anbieter und mehrere andere, die auf Apps und Daten von verschiedenen Standorten und über verschiedene Geräte zugreifen müssen. Unternehmen brauchten eine Möglichkeit, verschiedene Benutzergruppen auf unterschiedliche Weise zu authentifizieren. Während verschiedene Gateways für verschiedene Benutzergruppen verwendet werden können, werden die Wartung und Konsistenz der Erfahrung durch diesen Ansatz beeinflusst.

• SSO: Citrix ADC unterstützt alle SSO-Protokolle — SAML, Kerberos, KCD, formbasiert, 401/NTLM. Citrix ADC unterstützt SAML-Protokoll und kann die SAML-IDP-Rolle (Anwendungsfall 1. oben) sowie die SAML-SP-Rolle (Anwendungsfall 2. oben) spielen.

• Hostprofilerstellung: Citrix ADC unterstützt die EPA-Funktion (Endpoint Analysis), die für Hostprofilprüfungen verwendet wird. EPA kann verwendet werden, um den Quarantäne-Zugriff zu gewähren, falls der Benutzer die Sicherheitsüberprüfungen nicht erfüllt, die für den vollständigen Zugriff erforderlich sind.

• Compliance-Auditing: Citrix ADC unterstützt eine breite Palette von Auditing-Mechanismen wie Appflow, Syslog und benutzerdefinierte Protokollierung.

Konfigurationsschritte

Citrix Gateway für gehostete Windows-Anwendungen

Netzwerkarchitekturen

Wenn Sie Citrix Gateway in der DMZ bereitstellen, müssen Benutzerverbindungen die erste Firewall durchlaufen, um eine Verbindung mit Citrix Gateway herzustellen. Standardmäßig verwenden Benutzerverbindungen SSL auf Port 443, um diese Verbindung herzustellen. Damit Benutzerverbindungen das interne Netzwerk erreichen können, müssen Sie SSL auf Port 443 über die erste Firewall zulassen.

Citrix Gateway entschlüsselt die SSL-Verbindungen vom Benutzergerät und stellt im Auftrag des Benutzers eine Verbindung zu den Netzwerkressourcen hinter der zweiten Firewall her. Die Ports, die über die zweite Firewall geöffnet werden müssen, hängen von den Netzwerkressourcen ab, auf die Sie externe Benutzer zugreifen dürfen.

Wenn Sie beispielsweise externe Benutzer autorisieren, auf einen Webserver im internen Netzwerk zuzugreifen und dieser Server auf HTTP-Verbindungen an Port 80 wartet, müssen Sie HTTP auf Port 80 über die zweite Firewall zulassen. Citrix Gateway stellt die Verbindung über die zweite Firewall mit dem HTTP-Server im internen Netzwerk im Auftrag der externen Benutzergeräte her.

Citrix Gateway im sicheren Netzwerk bereitgestellt

Wenn Sie Citrix Gateway im sicheren Netzwerk bereitstellen, verbinden Sie eine Schnittstelle von Citrix Gateway mit dem Internet und die andere Schnittstelle mit Servern, die im sicheren Netzwerk ausgeführt werden. Das Setzen von Citrix Gateway in das sichere Netzwerk ermöglicht lokalen und Remote-Benutzern Zugriff. Diese Konfiguration verfügt nur über eine Firewall. Sie macht die Bereitstellung jedoch weniger sicher für Benutzer, die eine Verbindung von einem Remotestandort herstellen. Obwohl Citrix Gateway Datenverkehr aus dem Internet abfängt, tritt der Datenverkehr in das sichere Netzwerk ein, bevor Benutzer authentifiziert werden. Wenn Citrix Gateway in einer DMZ bereitgestellt wird, werden Benutzer authentifiziert, bevor der Netzwerkverkehr das sichere Netzwerk erreicht.

Wenn Citrix Gateway im sicheren Netzwerk bereitgestellt wird, müssen die Citrix Gateway-Plug-in-Verbindungen die Firewall durchlaufen, um eine Verbindung mit Citrix Gateway herzustellen. Standardmäßig verwenden Benutzerverbindungen das SSL-Protokoll auf Port 443, um diese Verbindung herzustellen. Um diese Konnektivität zu unterstützen, müssen Sie Port 443 in der Firewall öffnen.

SAML-Identitätsanbieter (IdP) -Modus

Der SAML-IdP (Identity Provider) ist eine SAML-Entität, die im Kundennetzwerk bereitgestellt wird. Der IdP empfängt Anforderungen vom SAML-SP und leitet Benutzer auf eine Anmeldeseite um, auf der sie ihre Anmeldeinformationen eingeben müssen. Der IdP authentifiziert diese Anmeldeinformationen mit dem Benutzerverzeichnis (externer Authentifizierungsserver, z. B. LDAP) und generiert dann eine SAML-Assertion, die an den SP gesendet wird.

Der SP überprüft das Token, und dem Benutzer wird dann Zugriff auf die angeforderte geschützte Anwendung gewährt.

Wenn die Citrix ADC-Appliance als IdP konfiguriert ist, werden alle Anforderungen von einem virtuellen Authentifizierungsserver empfangen, der dem relevanten SAML-IdP-Profil zugeordnet ist

Hinweis: Eine Citrix ADC-Appliance kann als IdP in einer Bereitstellung verwendet werden, bei der der SAML-SP entweder auf der Appliance oder auf einem externen SAML konfiguriert ist.

Bei Verwendung als SAML-IdP gilt eine Citrix ADC-Appliance:

• Unterstützt alle Authentifizierungsmethoden, die für herkömmliche Anmeldungen unterstützt werden.

• Signiert Behauptungen digital. Unterstützung für den SHA256-Algorithmus wird in Citrix ADC 11.0 Build 55.x eingeführt.

• Unterstützt Ein-Faktor- und Zwei-Faktor-Authentifizierung. SAML darf nicht als sekundärer Authentifizierungsmechanismus konfiguriert werden.

• Kann Assertionen mit dem öffentlichen Schlüssels des SAML-SP verschlüsseln. Dies wird empfohlen, wenn die Assertion vertrauliche Informationen enthält. Unterstützung in Citrix ADC 11.0 Build 55.x eingeführt.

• Kann so konfiguriert werden, dass nur digital signierte Anforderungen vom SAML-SP akzeptiert werden. Unterstützung eingeführt in Citrix ADC 11.0 Build 55.x

• Kann sich mit den folgenden 401-basierten Authentifizierungsmechanismen beim SAML-IdP anmelden: Negotiate, NTLM und Certificate. Unterstützung in Citrix ADC 11.0 Build 55.x eingeführt.

• Kann so konfiguriert werden, dass zusätzlich zum NameID-Attribut 16 Attribute gesendet werden. Die Attribute müssen vom entsprechenden Authentifizierungsserver extrahiert werden. Für jeden von ihnen können Sie den Namen, den Ausdruck, das Format und einen Anzeigenamen im SAML-IdP-Profil angeben. Unterstützung in Citrix ADC 11.0 Build 55.x eingeführt.

• Wenn die Citrix ADC-Appliance als SAML-IdP für mehrere SAML-SP konfiguriert ist, kann ein Benutzer Zugriff auf Anwendungen auf den verschiedenen SPs erhalten, ohne sich jedes Mal explizit zu authentifizieren. Die Citrix ADC-Appliance erstellt ein Sitzungscookie für die erste Authentifizierung, und jede weitere Anforderung verwendet dieses Cookie zur Authentifizierung. Unterstützung in Citrix ADC 11.0 Build 55.x eingeführt.

• Kann mehrwertige Attribute in einer SAML-Assertion senden. Unterstützung in Citrix ADC 11.0 Build 64.x eingeführt.

• Unterstützt Post- und Umleitungsbindungen. Unterstützung für Umleitungsbindungen wird in Citrix ADC 11.0 Build 64.x eingeführt. o

Wenn die Systemzeit für Citrix ADC-SAML-IdP und der Peer-SAML-SP nicht synchron ist, werden die Nachrichten möglicherweise von beiden Parteien ungültig. Um solche Fälle zu vermeiden, können Sie nun die Zeitdauer konfigurieren, für die die Assertionen gültig sind.

Diese Dauer, die als “Verzerrungszeit” bezeichnet wird, gibt die Anzahl der Minuten an, für die die Nachricht akzeptiert werden soll.

Die Verzerrungszeit kann auf dem SAML-SP und dem SAML-IdP konfiguriert werden.

Hinweis:

Unterstützung wurde in Citrix ADC 11.0 Build 64.x eingeführt.

• Kann so konfiguriert werden, dass Assertionen nur für SAML-SPs bereitgestellt werden, die für den IdP vorkonfiguriert sind oder vom IdP vertrauenswürdig sind. Für diese Konfiguration muss der SAML-IdP die Dienstanbieter-ID (oder Name des Ausstellers) der relevanten SAML-SPs haben. Unterstützung in Citrix ADC 11.0 Build 64.x eingeführt.

Konfiguration des ADFS-Proxymodus

Konfiguration

Um Citrix ADC als ADFS-Proxy einzurichten, müssen die folgenden Funktionen in Ihrem Citrix ADC-System aktiviert sein: Load Balancing, Content Switching SSL Offloading. Die Konfiguration des Citrix ADC als ADFS-Proxy umfasst die folgenden Schritte:

1. Richten Sie einen virtuellen Server für Content Switching ein. Dies ist der ADFS-Proxy VIP, die IP-Adresse für diesen virtuellen Server ist die IP-Adresse, die als Ersatz für die ADFS-Server-IP verwendet wird.
2. Erstellen Sie vier virtuelle Lastausgleichsserver: jeweils einen für die aktive und passive Authentifizierung, einen für den Metadatenzugriff und einen für das Umschreiben der Anforderungs-URL.
3. Erstellen und binden Sie die erforderlichen Richtlinien für den Content Switching an den CS vserver. Diese bestehen aus folgenden Komponenten:
   • Zwei Richtlinien zum Analysieren aktiver und passiver Authentifizierungsanforderungen, wobei die Vorauthentifizierung aktiviert/deaktiviert ist (deaktiviert, wenn die Authentifizierung am ADFS-Server bevorzugt wird)
   • Eine Richtlinie zum Analysieren von Metadatenanforderungen, die nicht authentifiziert sind und die Vorauthentifizierung deaktiviert ist.
   • Eine Richtlinie zum Umschreiben der Anforderungs-URL von /adfs/services/trust in /adfs/services/trust/proxymex.
4. Erstellen Sie einen AAA vserver, LDAP-Authentifizierung und Verhandeln und Sitzungsrichtlinien für die Authentifizierung von Anforderungen bei NetScaler und Durchführen von Kerberos-Impersonation/KCD (Kerberos Constrained Delegation) an den Backend-ADFS-Server.

Weitere Informationen finden Sie unter Bereitstellungshandbuch für den Citrix ADC ADFS-Proxy.

Paketfluss

Paketfluss für Citrix ADC als ADFS-Proxy mit interne/externem Benutzerzugriff:

1. Interne/externer Benutzerzugriff auf Office 365 wird von ADFS aktiviert.

2. Der Benutzer wird zur Authentifizierung an den entsprechenden Verbunddienst umgeleitet.

3. Der Benutzer wird zum internen Verbunddienst des Unternehmens umgeleitet.

4. Interner Benutzer ist Lastenausgleich auf die ADFS-Farm.

5. Externer Benutzer stellt eine Verbindung zur Citrix ADC AAA-TM-Anmeldeseite her.

6. Der Benutzer wird mit Active Directory oder einem ähnlichen Authentifizierungsdienst authentifiziert.

7. Nach der Authentifizierung führt Citrix ADC SSO (Kerberos/NTLM) in die ADFS-Farm durch.

8. Der ADFS-Server überprüft SSO-Anmeldeinformationen und gibt STS-Token zurück.

9. Externer Benutzer stellt eine Verbindung mit dem Verbunddienst her, bei dem das Token und die Ansprüche überprüft werden.

10. Basierend auf der Validierung stellt der Verbunddienst dem Benutzer ein neues Sicherheitstoken zur Verfügung.

11. Externer Benutzer stellt Autorisierungs-Cookie mit Sicherheitstoken für die Ressource für den Zugriff bereit.

Vorteile der Verwendung von Citrix ADC als ADFS-Proxy

1. Erfolgt sowohl Lastausgleich als auch ADFS-Proxy-Anforderungen

2. Funktioniert sowohl mit internen als auch externen Benutzerzugriffsszenarien

3. Unterstützt mehrere Methoden zur Vorauthentifizierung und ermöglicht Multi-Faktor-Authentifizierung

4. Bietet eine SSO-Erfahrung für Endbenutzer

5. Unterstützt sowohl aktive als auch passive Protokolle
   • Beispiele für aktive Protokollanwendungen — Outlook, Lync

6. Beispiele für passive Protokollanwendungen — Outlook Web App, Browser

7. Citrix ADC ist ein gehärtetes Gerät für die DMZ-basierte Bereitstellung

8. Mehrwert durch zusätzliche ADC-Kernfunktionen
   • Content Switching
   • SSL-Abladung
   • Neuschreiben
   • Responder
   • Ratenbegrenzung
   • Sicherheit (AAA-TM, Gateway, Anwendungsfirewall)