Conception de référence validée du module de trafic AAA

Récapitulatif de Citrix ADC

Citrix ADC est un contrôleur de mise à disposition d’applications tout-en-un qui permet d’exécuter les applications jusqu’à cinq fois mieux, réduit les coûts de propriété des applications, optimise l’expérience utilisateur et garantit que les applications sont toujours disponibles à l’aide de :

• Équilibrage de charge avancé L4-7 et gestion du trafic

• Accélération éprouvée des applications comme la compression HTTP et la mise en cache

• Un pare-feu intégré pour la sécurité des applications

• Déchargement des serveurs pour réduire considérablement les coûts et consolider les serveurs

En tant que leader incontesté de la fourniture de services et d’applications, Citrix ADC est déployé sur des milliers de réseaux à travers le monde pour optimiser, sécuriser et contrôler la fourniture de tous les services d’entreprise et de cloud. Déployé directement devant les serveurs Web et de base de données, Citrix ADC combine l’équilibrage de charge et la commutation de contenu à grande vitesse, la compression http, la mise en cache du contenu, l’accélération SSL, la visibilité du flux d’applications et un pare-feu d’application puissant dans une plate-forme intégrée et facile à utiliser. Il est beaucoup plus simple de respecter les SLA grâce à une surveillance de bout en bout qui transforme les données réseau en Business Intelligence exploitable. Citrix ADC permet de définir et de gérer les stratégies à l’aide d’un moteur de stratégie déclarative simple sans expertise en programmation requise.

Module AAA-TM de Citrix ADC

Gestion du trafic

AAA assure la sécurité d’un environnement Internet distribué en permettant à tout client disposant des informations d’identification appropriées de se connecter en toute sécurité à des serveurs d’applications protégés depuis n’importe où sur Internet. Cette fonctionnalité intègre les trois fonctionnalités de sécurité que sont l’authentification, l’autorisation et l’audit. L’authentification permet au Citrix ADC de vérifier les informations d’identification du client, soit localement, soit avec un serveur d’authentification tiers. Il permet uniquement aux utilisateurs approuvés d’accéder aux serveurs protégés. L’autorisation permet à l’ADC de vérifier le contenu sur un serveur protégé auquel il doit permettre à chaque utilisateur d’accéder. L’audit permet à l’ADC de conserver un enregistrement de l’activité de chaque utilisateur sur un serveur protégé.

Citrix Gateway

Les entreprises peuvent désormais réaliser une fédération et une authentification unique à travers les applications et postes de travail virtuels d’entreprise, Web, SaaS et locaux via Citrix Gateway. Citrix Gateway exploite ses fonctionnalités d’authentification, d’autorisation et d’audit (AAA) avec le changement de contenu pour permettre aux utilisateurs d’accéder à toutes leurs applications d’entreprise autorisées via une seule passerelle et une seule URL. Les organisations qui déploient aujourd’hui Citrix ADC pour leur infrastructure d’applications et de postes de travail virtuels peuvent facilement étendre leurs fonctionnalités pour l’authentification unique dans les applications cloud héritées, Web, virtuelles et publiques, privées et hybrides d’entreprise. Les clients qui utilisent des solutions et passerelles d’authentification unique et d’application tierces peuvent déployer une solution unique pour tous leurs besoins d’authentification unique en consolidant sur Citrix Gateway.

Les mécanismes d’authentification incluent LDAP, RADIUS, SAML, Kerberos, l’authentification basée sur les certificats, et bien plus encore.

Quel que soit le mécanisme d’authentification configuré sur un serveur virtuel Citrix Gateway avant l’utilisation automatique de la mise à niveau lorsque le serveur virtuel Citrix Gateway est placé derrière le serveur virtuel Unified Gateway.

Aucune étape de configuration supplémentaire n’est impliquée, autre que l’attribution d’une adresse IP non adressable (0.0.0.0) au serveur virtuel Citrix Gateway.

Vue d’ensemble de l’authentification

Pour comprendre comment AAA fonctionne dans un environnement distribué, considérez une organisation avec un intranet que ses employés accèdent au bureau, à la maison et lors des déplacements. Le contenu de l’intranet est confidentiel et nécessite un accès sécurisé. Tout utilisateur qui souhaite accéder à l’intranet doit avoir un nom d’utilisateur et un mot de passe valides. Pour répondre à ces exigences, l’ADC effectue les opérations suivantes :

• Redirige l’utilisateur vers la page de connexion si l’utilisateur accède à l’intranet sans s’être connecté.

• Collecte les informations d’identification de l’utilisateur, les transmet au serveur d’authentification et les met en cache dans un répertoire accessible via LDAP.

• Vérifie que l’utilisateur est autorisé à accéder au contenu intranet spécifique avant de remettre la demande de l’utilisateur au serveur d’applications.

• Maintient un délai d’expiration de session après lequel les utilisateurs doivent s’authentifier à nouveau pour retrouver l’accès à l’intranet. (Vous pouvez configurer le délai d’expiration.)

• Consigne l’accès de l’utilisateur, y compris les tentatives de connexion non valides, dans un journal d’audit.

L’authentification nécessite que plusieurs entités : le client, l’appliance Citrix ADC, le serveur d’authentification externe, le cas échéant, et le serveur d’applications, répondent l’une à l’autre lorsque vous y êtes invité en effectuant une série complexe de tâches dans l’ordre correct.

Lorsqu’un client authentifié demande une ressource, l’ADC, avant d’envoyer la demande au serveur d’applications, vérifie les stratégies d’utilisateur et de groupe associées au compte client, pour vérifier que le client est autorisé à accéder à cette ressource. L’ADC gère toutes les autorisations sur les serveurs d’applications protégés. Vous n’avez pas besoin d’effectuer une configuration spéciale de vos serveurs d’applications protégés.

Changements de mot de passe

AAA-TM gère les modifications de mot de passe pour les utilisateurs à l’aide de la méthode spécifique au protocole pour le serveur d’authentification. Pour la plupart des protocoles, ni l’utilisateur ni l’administrateur n’ont besoin de faire quoi que ce soit différent de ce qu’ils feraient sans AAA-TM. Même lorsqu’un serveur d’authentification LDAP est utilisé et que ce serveur fait partie d’un réseau distribué de serveurs LDAP avec un seul serveur d’administration de domaine désigné, les modifications de mot de passe sont généralement gérées de manière transparente. Lorsqu’un client authentifié d’un serveur LDAP change son mot de passe, le client envoie une demande de modification d’informations d’identification à AAA-TM, qui le transmet au serveur LDAP. Si le serveur LDAP de l’utilisateur est également le serveur d’administration de domaine, ce serveur répond de manière appropriée et AAA-TM effectue ensuite le changement de mot de passe demandé. Sinon, le serveur LDAP envoie AAA-TM une réponse LDAP_REFERRAL au serveur d’administration de domaine. AAA-TM suit la référence au serveur d’administration de domaine indiqué, s’authentifie auprès de ce serveur et effectue le changement de mot de passe sur ce serveur.

Remarque :

Lors de la configuration d’AAA-TM avec un serveur d’authentification LDAP, l’administrateur système doit garder à l’esprit les conditions et limitations suivantes :

• AAA-TM suppose que le serveur d’administration de domaine dans la référence accepte les mêmes informations d’identification de liaison que le serveur d’origine.
• AAA-TM suit uniquement les références LDAP pour les opérations de changement de mot de passe. Dans d’autres cas, AAA-TM refuse de suivre le renvoi.
• AAA-TM ne suit qu’un seul niveau de références LDAP. Si le deuxième serveur LDAP renvoie également une référence, AAA- TM refuse de suivre la deuxième référence.

Prise en charge de l’audit et de la journalisation

L’ADC prend en charge l’audit de tous les états et informations d’état, de sorte que vous pouvez voir les détails de ce que chaque utilisateur a fait lors de sa connexion, dans l’ordre chronologique. Pour fournir ces informations, la solution matérielle-logicielle enregistre chaque événement, au fur et à mesure qu’il se produit, soit dans un fichier journal d’audit désigné sur la solution matérielle-logicielle, soit dans un serveur syslog. L’audit nécessite la configuration de l’appliance et de tout serveur syslog que vous utilisez.

Limitations et directives d’utilisation

Matrice d’authentification :

Une adresse IP publique pour les déploiements AAA-TM sur Citrix ADC

Citrix ADC prend en charge le framework AAA pour les serveurs virtuels de gestion du trafic (TM) (désormais appelés vserver) en exploitant diverses fonctionnalités AAA prises en charge par le sous-système d’authentification. Le serveur utilisé pour l’authentification est appelé’authentication vserver’ou AAA vserver.

Citrix ADC peut consolider l’image ci-dessus sur un point de terminaison public en ayant une diapositive vserver d’authentification adjacente à TM vserver afin qu’il y ait un point d’extrémité public, et à son tour un certificat. Ceci est représenté dans le diagramme suivant :

Applications hébergées par Windows par Citrix Virtual Apps and Desktops

Vous pouvez déployer Citrix Gateway sur le périmètre du réseau interne (ou intranet) de votre organisation afin de fournir un point d’accès unique sécurisé aux serveurs, applications et autres ressources réseau qui résident dans le réseau interne. Tous les utilisateurs distants doivent se connecter à Citrix Gateway avant de pouvoir accéder aux ressources du réseau interne.

Citrix Gateway est le plus souvent installé dans les emplacements suivants d’un réseau :

• Dans le réseau DMZ

• Dans un réseau sécurisé qui n’a pas de zone démilitarisée

Vous pouvez également déployer Citrix Gateway avec Citrix Virtual Apps, Virtual Desktops, StoreFront et Endpoint Management Server aux utilisateurs pour accéder à leurs applications Windows, Web, mobiles et SaaS.

Si votre déploiement inclut Citrix Virtual Apps, StoreFront ou Virtual Desktops, vous pouvez déployer Citrix Gateway dans une configuration DMZ à saut unique ou à double saut. Un déploiement à double saut n’est pas pris en charge avec les versions antérieures de Virtual Desktops ou Virtual Apps.

Applications SaaS SAML 2.0

SAML (Security Assertion Markup Language) est un mécanisme d’authentification XML qui fournit une fonctionnalité d’authentification unique et est défini par le comité technique des services de sécurité OASIS.

Pourquoi SAML ? Considérez un scénario dans lequel un fournisseur de services (LargeProvider) héberge un certain nombre d’applications pour un client (BigCompany). BigCompany a des utilisateurs qui doivent accéder de façon transparente à ces applications. Dans une configuration traditionnelle, LargeProvider devrait gérer une base de données des utilisateurs de BigCompany. Cela soulève certaines préoccupations pour chacun des intervenants suivants :

• LargeProvider doit assurer la sécurité des données utilisateur.

• BigCompany doit valider les utilisateurs et tenir les données utilisateur à jour, non seulement dans sa propre base de données, mais aussi dans la base de données utilisateur gérée par LargeProvider. Par exemple, un utilisateur supprimé de la base de données BigCompany doit également être supprimé de la base de données LargeProvider.

• Un utilisateur doit se connecter individuellement à chacune des applications hébergées.

Le mécanisme d’authentification SAML offre une approche alternative. Le diagramme de déploiement suivant illustre le fonctionnement de SAML :

Les préoccupations soulevées par les mécanismes traditionnels d’authentification sont résolues comme suit :

• LargeProvider n’a pas besoin de gérer une base de données pour les utilisateurs de BigCompany. Libéré de la gestion des identités, Large Provider peut se concentrer sur la fourniture de meilleurs services.

• BigCompany ne supporte pas le fardeau de s’assurer que la base de données utilisateur LargeProvider est synchronisée avec sa propre base de données utilisateur.

• Un utilisateur peut ouvrir une session une fois sur une application hébergée sur LargeProvider et être automatiquement connecté aux autres applications qui y sont hébergées.

L’appliance Citrix ADC peut être déployée en tant que fournisseur de services SAML (SP) et fournisseur d’identité SAML (IdP). Lisez les rubriques pertinentes pour comprendre les configurations qui doivent être effectuées sur le dispositif Citrix ADC.

Intégration du cloud hybride ADFS

AD FS est un service basé sur des normes qui permet le partage sécurisé d’informations d’identité entre partenaires commerciaux de confiance (connus sous le nom de fédération) sur un extranet. Lorsqu’un utilisateur doit accéder à une application Web à partir d’un de ses partenaires de fédération, l’organisation de l’utilisateur est responsable de l’authentification de l’utilisateur et de fournir des informations d’identité sous forme de « réclamations » au partenaire qui héberge l’application Web. Le partenaire d’hébergement utilise sa stratégie d’approbation pour mapper les revendications entrantes aux revendications comprises par son application Web, qui utilise les revendications pour prendre des décisions d’autorisation.

Les services AD FS (Active Directory Federation Services) permettent aux utilisateurs locaux et aux utilisateurs fédérés d’utiliser l’authentification unique (SSO) basée sur les revendications sur des sites et services Web. Vous pouvez utiliser AD FS pour permettre à votre organisation de collaborer en toute sécurité sur des domaines Active Directory avec d’autres organisations externes à l’aide de la fédération d’identité. Cela réduit le besoin de comptes en double, la gestion de plusieurs ouvertures de session et d’autres problèmes de gestion des informations d’identification qui peuvent se produire lorsque vous établissez des approbations interorganisations.

Mode proxy ADFS

Le proxy AD FS 2.0 est un service qui négocie une connexion entre des utilisateurs externes et votre serveur AD FS 2.0 interne. Il agit comme un proxy inverse et réside généralement dans le réseau de périmètre de votre organisation (alias DMZ). En ce qui concerne les utilisateurs, ils ne savent pas qu’ils parlent à un serveur proxy AD FS, car les services de fédération sont accessibles par les mêmes URL. Le serveur proxy gère trois fonctions principales.

• Fournisseur d’assertion : le proxy accepte les demandes de jeton des utilisateurs et transmet les informations via SSL (port par défaut 443) au serveur AD FS interne. Il reçoit le jeton du serveur AD FS interne et le transmet à l’utilisateur.

• Consumer assertion : le proxy accepte les jetons des utilisateurs et les transmet via SSL (port par défaut 443) au serveur AD FS interne pour traitement.

• Fournisseur de métadonnées : le proxy répondra également aux demandes de métadonnées de fédération.

Le proxy AD FS 2.0 n’est pas requis pour l’utilisation d’AD FS. C’est une fonctionnalité supplémentaire. La raison pour laquelle vous installez un proxy AD FS 2.0 est que vous ne souhaitez pas exposer le serveur AD FS 2.0 réel à Internet. Les serveurs AD FS 2.0 sont des ressources jointes à un domaine, alors que le proxy AD FS 2.0 n’a pas cette exigence. Si tous vos utilisateurs et applications sont internes à votre réseau, vous n’avez pas besoin d’utiliser un proxy AD FS 2.0. S’il est nécessaire d’exposer votre service de fédération à Internet, il est recommandé d’utiliser un proxy AD FS 2.0.

Consultez le lien suivant pour plus d’informations surPrésentation du proxy AD FS 2.0.

Mode IDP ADFS

Le fournisseur d’identité (IP) du partenaire fédéré envoie des revendications qui reflètent l’identité, les groupes et les données attributaires de ses utilisateurs. Par conséquent, votre organisation n’a plus besoin de révoquer, de modifier ou de réinitialiser les informations d’identification des utilisateurs du partenaire, car les informations d’identification sont gérées par l’organisation partenaire. En outre, si une société de personnes doit être résiliée, elle peut être effectuée avec une seule modification de stratégie de confiance. Sans AD FS, les comptes individuels de chaque utilisateur partenaire devront être désactivés. La configuration en tant que fournisseur d’identité permet de réutiliser les comptes existants gérés par des objets Active Directory existants pour l’authentification. Il élimine la nécessité de créer des mécanismes complexes de synchronisation des comptes ou de développer du code personnalisé qui effectue les tâches d’acceptation des informations d’identification de l’utilisateur final, de les valider par rapport au magasin d’informations d’identification et de gestion des identités.

Authentification Citrix ADC nFactor (Multifactor)

nFactor donne une nouvelle perspective à l’authentification, rationalise le flux d’authentification et offre une grande flexibilité lors de l’authentification.

L’authentification multifacteur améliore la sécurité d’une application en exigeant des utilisateurs qu’ils fournissent plusieurs preuves d’identification pour y accéder. L’appliance Citrix ADC offre une approche flexible et extensible de configuration de l’authentification multi-facteurs. Cette approche est appelée authentification nFactor.

Avec l’authentification nFactor, vous pouvez :

• Configurez n’importe quel nombre de facteurs d’authentification.

• Baser la sélection du facteur suivant sur le résultat de l’exécution du facteur précédent.

• Personnalisez l’interface de connexion. Par exemple, vous pouvez personnaliser les noms des étiquettes, les messages d’erreur et le texte d’aide. o Extraire les informations du groupe d’utilisateurs sans effectuer d’authentification.

• Configurer la transmission pour un facteur d’authentification. Cela signifie qu’aucune interaction explicite de connexion n’est requise pour ce facteur.

• Configurez l’ordre dans lequel les différents types d’authentification sont appliqués. Tous les mécanismes d’authentification pris en charge sur l’appliance Citrix ADC peuvent être configurés comme n’importe quel facteur de configuration de l’authentification nFactor.

Ces facteurs sont exécutés dans l’ordre dans lequel ils sont configurés.

• Configurez le Citrix ADC pour qu’il passe à un facteur d’authentification qui doit être exécuté en cas d’échec de l’authentification.

Pour ce faire, vous configurez une autre stratégie d’authentification avec exactement la même condition, mais avec la priorité la plus élevée suivante et avec l’action définie sur « NO_AUTH ».

Vous devez également configurer le facteur suivant, qui doit spécifier le mécanisme d’authentification alternatif à appliquer.

Applications d’entreprise client

Adaptive Multi-Factor Authentication (MFA) pour une sécurité plus stricte

Les entreprises ont plusieurs parties prenantes qui utilisent leurs applications et leurs données. Les employés partenaires, fournisseurs et plusieurs autres personnes qui ont besoin d’accéder à des applications et des données à partir de différents emplacements et à l’aide de divers appareils. Les entreprises avaient besoin d’un moyen d’authentifier différents groupes d’utilisateurs de différentes manières. Bien que différentes passerelles puissent être utilisées pour différents groupes d’utilisateurs, cette approche aura des répercussions sur la maintenance et la cohérence de l’expérience.

• SSO : Citrix ADC prend en charge tous les protocoles SSO — SAML, Kerberos, KCD, basé sur des formulaires, 401/NTLM. Citrix ADC prend en charge le protocole SAML et peut jouer le rôle IDP SAML (cas d’utilisation 1. ci-dessus) ainsi que le rôle SP SAML (cas d’utilisation 2. ci-dessus).

• Profilage d’hôte : Citrix ADC prend en charge la fonctionnalité d’analyse de point de terminaison (EPA) qui est utilisée pour les vérifications de profil d’hôte. EPA peut être utilisé pour accorder un accès en quarantaine dans le cas où l’utilisateur ne répond pas aux contrôles de sécurité nécessaires pour un accès complet.

• Audit de conformité : Citrix ADC prend en charge un large éventail de mécanismes d’audit tels que Appflow, Syslog et la journalisation définie par l’utilisateur.

Étapes de configuration

Citrix Gateway pour les applications Windows hébergées

Architectures réseau

Lorsque vous déployez Citrix Gateway dans la zone DMZ, les connexions utilisateur doivent traverser le premier pare-feu pour se connecter à Citrix Gateway. Par défaut, les connexions utilisateur utilisent SSL sur le port 443 pour établir cette connexion. Pour permettre aux connexions utilisateur d’atteindre le réseau interne, vous devez autoriser SSL sur le port 443 via le premier pare-feu.

Citrix Gateway décrypte les connexions SSL de la machine utilisateur et établit une connexion pour le compte de l’utilisateur aux ressources réseau derrière le deuxième pare-feu. Les ports qui doivent être ouverts via le deuxième pare-feu dépendent des ressources réseau auxquelles vous autorisez les utilisateurs externes à accéder.

Par exemple, si vous autorisez des utilisateurs externes à accéder à un serveur Web dans le réseau interne et que ce serveur écoute les connexions HTTP sur le port 80, vous devez autoriser HTTP sur le port 80 via le deuxième pare-feu. Citrix Gateway établit la connexion via le deuxième pare-feu au serveur HTTP sur le réseau interne au nom des machines utilisateur externes.

Citrix Gateway déployé dans le réseau sécurisé

Lorsque vous déployez Citrix Gateway dans le réseau sécurisé, connectez une interface de Citrix Gateway à Internet et l’autre interface aux serveurs s’exécutant dans le réseau sécurisé. La mise en place de Citrix Gateway dans le réseau sécurisé fournit un accès aux utilisateurs locaux et distants. Cette configuration n’a qu’un seul pare-feu. Toutefois, il rend le déploiement moins sécurisé pour les utilisateurs qui se connectent à partir d’un emplacement distant. Bien que Citrix Gateway intercepte le trafic depuis Internet, le trafic entre dans le réseau sécurisé avant que les utilisateurs ne soient authentifiés. Lorsque Citrix Gateway est déployé dans une zone DMZ, les utilisateurs sont authentifiés avant que le trafic réseau atteigne le réseau sécurisé.

Lorsque Citrix Gateway est déployé dans le réseau sécurisé, les connexions Citrix Gateway Plug-in doivent traverser le pare-feu pour se connecter à Citrix Gateway. Par défaut, les connexions utilisateur utilisent le protocole SSL sur le port 443 pour établir cette connexion. Pour prendre en charge cette connectivité, vous devez ouvrir le port 443 sur le pare-feu.

Mode fournisseur d’identité SAML (IdP)

L’IdP SAML (Identity Provider) est une entité SAML déployée sur le réseau client. L’IdP reçoit des demandes du SP SAML et redirige les utilisateurs vers une page d’ouverture de session, où ils doivent entrer leurs informations d’identification. L’IdP authentifie ces informations d’identification avec le répertoire utilisateur (serveur d’authentification externe, tel que LDAP), puis génère une assertion SAML envoyée au SP.

Le SP valide le jeton, et l’utilisateur est ensuite autorisé à accéder à l’application protégée demandée.

Lorsque l’appliance Citrix ADC est configurée en tant qu’IdP, toutes les demandes sont reçues par un serveur virtuel d’authentification associé au profil IdP SAML approprié

Remarque : un dispositif Citrix ADC peut être utilisé en tant qu’IdP dans un déploiement où le SP SAML est configuré soit sur l’appliance, soit sur n’importe quel SAML externe

Lorsqu’il est utilisé en tant qu’IdP SAML, une appliance Citrix ADC :

• Prend en charge toutes les méthodes d’authentification qu’il prend en charge pour les ouvertures de session traditionnelles.

• Signature numérique des assertions. La prise en charge de l’algorithme SHA256 est introduite dans Citrix ADC 11.0 Build 55.x.

• Prend en charge l’authentification à un facteur et à deux facteurs. SAML ne doit pas être configuré comme mécanisme d’authentification secondaire.

• Peut chiffrer les assertions à l’aide de la clé publique du SP SAML. Ceci est recommandé lorsque l’assertion inclut des informations sensibles. Prise en charge introduite dans Citrix ADC 11.0 Build 55.x.

• Peut être configuré pour accepter uniquement les demandes signées numériquement à partir du SP SAML. Prise en charge introduite dans Citrix ADC 11.0 Build 55.x

• Vous pouvez vous connecter à l’IdP SAML à l’aide des mécanismes d’authentification basés sur 401 suivants : Negotiate, NTLM et Certificate. Prise en charge introduite dans Citrix ADC 11.0 Build 55.x.

• Peut être configuré pour envoyer 16 attributs en plus de l’attribut NameID. Les attributs doivent être extraits du serveur d’authentification approprié. Pour chacun d’eux, vous pouvez spécifier le nom, l’expression, le format et un nom convivial dans le profil IdP SAML. Prise en charge introduite dans Citrix ADC 11.0 Build 55.x.

• Si l’appliance Citrix ADC est configurée en tant qu’IdP SAML pour plusieurs SP SAML, un utilisateur peut accéder aux applications sur les différents SP sans s’authentifier explicitement à chaque fois. L’appliance Citrix ADC crée un cookie de session pour la première authentification, et chaque requête ultérieure utilise ce cookie pour l’authentification. Prise en charge introduite dans Citrix ADC 11.0 Build 55.x.

• Peut envoyer des attributs à plusieurs valeurs dans une assertion SAML. Prise en charge introduite dans Citrix ADC 11.0 Build 64.x.

• Prend en charge les liaisons de poste et de redirection. La prise en charge des liaisons de redirection est introduite dans Citrix ADC 11.0 Build 64.x. o

Si l’heure système sur Citrix ADC SAML IdP et le SP SAML homologue n’est pas synchronisé, les messages peuvent être invalidés par l’une ou l’autre partie. Pour éviter de tels cas, vous pouvez maintenant configurer la durée pendant laquelle les assertions seront valides.

Cette durée, appelée « temps d’inclinaison », spécifie le nombre de minutes pendant lesquelles le message doit être accepté.

Le temps d’inclinaison peut être configuré sur le SP SAML et l’IdP SAML.

Remarque :

prise en charge introduite dans Citrix ADC 11.0 Build 64.x.

• Peut être configuré pour servir des assertions uniquement aux SP SAML préconfigurés ou approuvés par l’IdP. Pour cette configuration, l’IdP SAML doit avoir l’ID du fournisseur de services (ou le nom de l’émetteur) des SP SAML concernés. Prise en charge introduite dans Citrix ADC 11.0 Build 64.x.

Configuration du mode proxy ADFS

Configuration

Pour configurer Citrix ADC en tant que proxy ADFS, les fonctionnalités suivantes doivent être activées dans votre système Citrix ADC : équilibrage de charge, déchargement SSL de commutation de contenu. La configuration du Citrix ADC en tant que proxy ADFS implique les étapes suivantes :

1. Configurez un serveur virtuel de commutation de contenu. Il s’agit du proxy ADFS VIP, l’adresse IP de ce serveur virtuel est l’adresse IP qui sera utilisée comme remplacement de l’adresse IP du serveur ADFS.
2. Créez quatre serveurs virtuels d’équilibrage de charge : un pour l’authentification active et passive, un pour l’accès aux métadonnées et un pour la réécriture de l’URL de la requête.
3. Créez et liez les stratégies de commutation de contenu requises au serveur CS vserver. Celles-ci seront les suivantes :
   • Deux stratégies pour analyser les demandes d’authentification actives et passives, avec pré-authentification activée/désactivée (désactivée si l’authentification est préférable sur le serveur ADFS)
   • Une stratégie d’analyse des demandes de métadonnées, qui ne sont pas authentifiées et dont la pré-authentification est désactivée.
   • Une stratégie pour réécrire l’URL de la requête de /adfs/services/trust vers /adfs/services/trust/proxymex.
4. Créez un vserver AAA, une authentification LDAP et des stratégies de négociation et de session pour l’authentification des demandes sur Nets-Caler et l’exécution de Kerberos Impersonation/KCD (Kerberos Constrained Délégation) sur le serveur ADFS principal.

Pour plus d’informations, reportez-vous au guide de déploiement pour le proxy ADFS Citrix ADC.

Flux de paquets

Flux de paquets pour Citrix ADC en tant que proxy ADFS avec accès interne/externe des utilisateurs :

1. L’accès des utilisateurs internes/externes à Office 365 est activé par ADFS.

2. L’utilisateur est redirigé vers le service de fédération applicable pour l’authentification.

3. L’utilisateur est redirigé vers le service de fédération interne de l’entreprise.

4. L’utilisateur interne est équilibré par rapport à la batterie ADFS.

5. L’utilisateur externe se connecte à la page d’ouverture de session Citrix ADC AAA-TM.

6. L’utilisateur est authentifié auprès d’Active Directory ou d’un service d’authentification similaire.

7. Après l’authentification, Citrix ADC effectue l’authentification unique (Kerberos/NTLM) à la batterie ADFS.

8. Le serveur ADFS valide les informations d’identification SSO et renvoie le jeton STS.

9. L’utilisateur externe se connecte au service de fédération où le jeton et les revendications sont vérifiés.

10. Sur la base de la validation, le service de fédération fournit à l’utilisateur un nouveau jeton de sécurité.

11. L’utilisateur externe fournit un cookie d’autorisation avec un jeton de sécurité à la ressource pour l’accès.

Avantages de l’utilisation de Citrix ADC en tant que proxy ADFS

1. Répond aux besoins d’équilibrage de charge et de proxy ADFS

2. Fonctionne avec des scénarios d’accès utilisateur internes et externes

3. Prend en charge plusieurs méthodes de pré-authentification et active l’authentification multi-facteurs

4. Offre une expérience SSO pour les utilisateurs finaux

5. Prend en charge les protocoles actifs et passifs
   • Exemples d’applications de protocole actif — Outlook, Lync

6. Exemples d’applications de protocole passif — application Web Outlook, navigateurs

7. Citrix ADC est un périphérique renforcé pour le déploiement DMZ

8. Ajoute de la valeur grâce aux fonctionnalités de base ADC supplémentaires
   • Changement de contenu
   • Déchargement SSL
   • Réécrire
   • Répondeur
   • Limite de taux
   • Sécurité (AAA-TM, passerelle, pare-feu d’application)