Introduction à Sign&go Guide d architecture

Transcription

1 Introduction à Sign&go Guide d architecture

2

3 Contact ILEX 51, boulevard Voltaire Asnières-sur-Seine Tél. : (33) Fax : (33) Mél. : [email protected] Site Web : Informations légales Sign&go TM est une marque déposée de la société ILEX. Toutes les autres marques citées dans ce document sont la propriété de leurs sociétés respectives. Ce document est fourni uniquement à titre d information. En aucun cas, le contenu du document, sous quelque forme que ce soit, ne peut engager la responsabilité de la société ILEX. Toutes spécifications ou données peuvent être modifiées sans préavis. En vertu de l article L du Code de la Propriété Intellectuelle, toute représentation totale ou partielle de ce document, par quelque procédé que ce soit, sans l autorisation expresse de la société ILEX, est interdite et constituerait une contrefaçon sanctionnée par les articles L et suivants du Code de la Propriété Intellectuelle. Copyright ILEX Tous droits réservés. Sign&go 3

4

5 Table des matières Apports du SSO pour l entreprise... 7 Définition du Single Sign-On (SSO)... 9 Différents types de SSO SSO Web : la problématique du portail Architecture SSO Web Reverse-Proxy Architecture SSO Web Proxy Architecture SSO Web à base de filtres Sign&go : une solution SSO adaptée Personnalisation des habilitations Gestion centralisée de la sécurité Interopérabilité Architecture globale de Sign&go Sign&go : schéma général d architecture Principe général de Sign&go Architecture haute disponibilité Comment accéder à une ressource protégée? Comment authentifier un utilisateur? Phase d authentification : le serveur de sécurité Principe de l authentification Agents d authentification Exploitation des annuaires existants Schémas d authentification Jeton de session Phase d habilitation : la politique de sécurité. 43 Principe de la politique de sécurité Règle d accès Configurer la phase d authentification Etapes initiales Gérer les jetons, l annuaire principal Sign&go et les accréditations secondaires Configurer la phase d habilitation Créer une politique de sécurité Créer une règle d accès Sign&go 5

6

7 Chapitre 1 Apports du SSO pour l entreprise Définition du Single Sign-On (SSO)... 9 Différents types de SSO SSO Web : la problématique du portail Architecture SSO Web Reverse-Proxy Architecture SSO Web Proxy Architecture SSO Web à base de filtres

8

9 Apports du SSO pour l entreprise Définition du Single Sign-On (SSO) Principe Mise en oeuvre Fondements de la sécurité Le Single Sign-On (SSO), appelé Signature Unique, est un mécanisme par lequel l utilisateur n a besoin de s authentifier qu une seule fois pour accéder à plusieurs ressources hétérogènes. Toute contrainte des authentifications à répétition est ainsi éliminée; le SSO constitue un point d entrée unique au système d information. Sur un portail d entreprise par exemple, l utilisateur s authentifie une seule et unique fois et l architecture technique s occupe ensuite de diffuser la validité de cette authentification et les habilitations associées aux applications concernées. L utilisateur s authentifie une première fois; il s agit d une authentification primaire. Puis la technologie SSO récupère le nécessaire pour les authentifications secondaires. Ce mécanisme évite ainsi à l utilisateur de devoir lui-même s authentifier de multiples fois. Selon le schéma d authentification, les authentifications primaires et secondaires peuvent correspondre à la saisie d un identifiant et d un mot de passe, à l insertion d une carte à puce... Le SSO est donc une extension de deux fondements de la sécurité : l authentification et l habilitation. Sign&go 9

10 Apports du SSO pour l entreprise Différents types de SSO Classification Une différenciation faible Avantage du SSO Web Dans le cadre des solutions orientées entreprise (intranet, extranet), on distingue trois grands types de SSO : SSO Poste Local Il correspond aux premières solutions de SSO. Il donne principalement accès à des applications traditionnelles du domaine de l entreprise (connexion réseau, messagerie...). SSO Site Central Il s agit d une sous-catégorie de SSO Poste Local qui donne accès aux applications des sites centraux des entreprises. SSO Web A partir du navigateur Web, il donne un point d entrée unique et personnalisé aux portails d entreprises et aux intranets. Avec le développement des portails d entreprise, le SSO Web représente aujourd hui une solution phare pour «l e-business». La problématique du portail et les architectures SSO Web sont détaillées dans ce chapitre. La classification précédente ne doit pas être prise au sens strict. En effet, un SSO Poste Local peut très bien assurer sa fonction pour des applicatifs traditionnels et pour des applications Web, en interceptant et remplissant automatiquement les formulaires d authentification demandés dans le navigateur. De même, un SSO Web peut avoir accès à des applications non-web. Pour assurer une authentification sur des applications Web, le SSO Poste Local simule la saisie d informations dans le navigateur et ne peut éviter la circulation de données sensibles en clair sur le réseau. Ce problème de sécurité ne se pose pas dans le cas du SSO Web qui s intercale, sur la chaîne de liaison, entre le navigateur et le serveur Web. Le poste client est ainsi véritablement sécurisé. 10 Sign&go

11 Apports du SSO pour l entreprise SSO Web : la problématique du portail Principe du portail Utilisation du portail Apports du SSO Web Le portail est un agrégateur de contenu qui facilite le travail de l utilisateur en lui fournissant un accès unique à ses applicatifs et à ses données. L environnement de travail se réduit ainsi à un navigateur qui permet l accès au portail; les postes utilisateurs deviennent banalisés. L utilisation du portail permet de réduire significativement le coût total d un système (TCO: Total Cost of Ownership) car les postes utilisateur ne nécessitent plus aucune installation. L utilisateur ouvre son navigateur et se connecte à une URL d accès au portail d entreprise. Il s authentifie alors sur ce portail. Après l authentification, un menu de démarrage est automatiquement affiché. Il s agit d un menu personnalisé qui présente à l utilisateur les liens de tous les applicatifs dont il a besoin (intranet, sites html, serveurs dans l entreprise...). Dans le cas d un portail classique, l authentification primaire de l utilisateur au portail est suivie de nombreuses authentifications secondaires aux différents applicatifs que l utilisateur sélectionne. Le SSO Web va permettre de véhiculer l authentification primaire du portail vers les serveurs distants pour éviter les authentifications secondaires multiples. L utilisateur s authentifie uniquement au portail. Architecture SSO Web Reverse-Proxy Principe Cette architecture repose sur un module placé entre l utilisateur et le serveur d application Web. Ce module, le Reverse-Proxy Web accepte les requêtes et route les informations vers les applications destinatrices. Le processus de SSO est effectué par le Reverse-Proxy. En effet, il ne se contente pas de router la requête du client vers la bonne machine, mais il altère les requêtes afin de simuler une authentification du client auprès de l application Web (authentification secondaire). Sign&go 11

12 Apports du SSO pour l entreprise Le schéma suivant présente une architecture SSO Web Reverse-Proxy. Utilisation L utilisateur n a qu un seul interlocuteur : le Reverse-Proxy. Il est donc nécessaire de modifier la configuration DNS de l entreprise : le Reverse-Proxy demeure le serveur final. Ainsi, l utilisateur s authentifie auprès de ce serveur Reverse- Proxy à l aide des méthodes d authentification standard. Puis, le Reverse-Proxy autorise ou non l accès vers les URL finales en utilisant une table de mapping afin de récupérer les données sur le serveur. Avantages Les principaux avantages de l architecture SSO Web Reverse- Proxy reposent sur l installation et l architecture. Installation Le Reverse-Proxy de sécurité s intercale sur la chaîne de liaison entre le client et les serveurs. Il n y a donc aucune modification à apporter ni aux serveurs, ni aux clients (Non intrusif sur le système cible). Architecture Les opérations effectuées restent au niveau du protocole HTTP, c est pourquoi ce système de SSO demeure indépendant de l architecture physique (SE, machines). 12 Sign&go

13 Apports du SSO pour l entreprise De plus, ce système masque la topologie réseau. En effet, le portail de sécurité est la seule machine accessible par le client, ce qui permet la mise en place d une zone démilitarisée (DMZ), région dotée d une sécurisation intermédiaire entre l extérieur et l intérieur de l entreprise. Un seul Reverse-Proxy est ainsi capable de protéger un ensemble de serveurs Web. Inconvénients Les principaux inconvénients de l architecture SSO Web Reverse-Proxy reposent sur la sécurité, la montée en charge et la PKI. Sécurité Entre le Reverse-Proxy et le serveur intranet, la sécurité n est pas assurée du fait de la rupture de la chaîne de liaison. Pour contrer ce problème, il faut que les serveurs finaux soient très proches du Reverse-Proxy. Cette contrainte est forte en environnement Intranet. Montée en charge/haute disponibilité Le portail est le point de passage obligatoire vers les applications. Par conséquent, des problématiques de charge du Reverse-Proxy peuvent survenir. Il convient donc de reproduire, au niveau du Reverse-Proxy, l architecture haute disponibilité mise en place sur le serveur Web, afin de conserver le coefficient global de haute disponibilité. PKI Ce système de SSO est partiellement compatible avec les PKI. Quand l utilisateur s authentifie par certificat au Reverse- Proxy Web, celui-ci ne pourra pas rejouer l authentification jusqu au serveur. Les informations de l utilisateur transitent ainsi sous la forme d informations applicatives entre le Reverse-Proxy et le serveur (le plus souvent sous la forme d en-têtes HTTP). En effet, d une manière intrinsèque, l authentification par certificats se fait en point à point si bien qu elle nécessite une communication directe, sans rupture de chaîne. Bilan Ce type d architecture est recommandé dans les problématiques de type extranet ou lorsqu il s avère impossible d ajouter des composants sur les serveurs cibles. En effet, tout Reverse-Proxy peut s installer en DMZ et contrôler systématiquement les accès extérieurs, ce qui protège efficacement les données de l entreprise. Sign&go 13

14 Apports du SSO pour l entreprise Architecture SSO Web Proxy Principe Cette architecture suppose la modification de la configuration des navigateurs clients pour transmettre les connexions à un Proxy. Le Proxy intercepte les requêtes et route les informations vers les applications destinatrices. Le processus de SSO est effectué par le Proxy. En effet, il ne se contente pas de router la requête du client vers la bonne machine, mais il altère les requêtes afin de simuler une authentification du client auprès de l application Web (authentification secondaire). Le schéma suivant présente une architecture SSO Web Proxy. Utilisation Avantages Après configuration du navigateur de l utilisateur, toutes les requêtes transitent systématiquement par le Proxy, et ceci même si le client souhaite atteindre un site Web extérieur à l entreprise. Une fois l utilisateur authentifié, le Proxy autorise ou non l accès vers les URL finales. Les principaux avantages de l architecture SSO Web Proxy reposent sur l installation, l architecture et la montée en charge. 14 Sign&go

15 Apports du SSO pour l entreprise Installation Après configuration des postes clients, le passage par le Proxy est géré directement par le protocole HTTP; nul besoin de modifier les configurations DNS des serveurs (cas du Reverse- Proxy). Tout comme les architectures Reverse-Proxy, ce système n est pas intrusif sur les serveurs. Architecture L ensemble des opérations se situe au niveau du protocole HTTP, ce système de SSO demeure donc indépendant de l architecture. Après configuration des postes clients, tous les serveurs Web sont potentiellement éligibles. Montée en charge/haute disponibilité Pour gérer au mieux les montées en charge, il est possible de chaîner les proxys. Afin de tenir compte des contraintes de haute disponibilité, il est possible aussi de configurer plusieurs proxys au niveau du poste utilisateur. Inconvénients Les principaux inconvénients de l architecture SSO Web Proxy reposent sur la sécurité, la configuration et la PKI. Sécurité Entre le Proxy et le serveur Web, la sécurité n est pas assurée du fait de la rupture de la chaîne de liaison. Pour contrer ce problème, il faut que les serveurs finaux soient très proches du Proxy, ce qui est difficilement réalisable en pratique. Lors de la mise en place du SSO, le protocole HTTPS en mode proxy impose au Proxy le déchiffrage du flux avant toute connexion au serveur final. Le Proxy est donc installé en «man-in-the-middle-proxy». En cas d attaque du proxy, l entreprise risque alors de perdre la confidentialité des échanges. Configuration Ce système impose la modification de la configuration des postes utilisateur. C est pourquoi, il ne peut être installé dans les cas d accès distants au système d information ou, plus généralement, de non-maîtrise du poste utilisateur. PKI Ce système de SSO est partiellement compatible avec les PKI. Sign&go 15

16 Apports du SSO pour l entreprise Quand l utilisateur s authentifie par certificat au Proxy Web, celui-ci ne pourra pas rejouer l authentification jusqu au serveur. En effet, d une manière intrinsèque, l authentification par certificats se fait en point à point et nécessite donc une communication directe, sans rupture de chaîne. Bilan Ce type d architecture est recommandé dans les problématiques de type intranet quand la fonctionnalité de SSO prime par rapport à la sécurité. L avantage majeur de cette architecture est sa facilité et sa rapidité de mise en oeuvre dans de vastes environnements. Architecture SSO Web à base de filtres Principe Cette architecture consiste à déployer un serveur de sécurité qui prend en charge la gestion des utilisateurs et des filtres (agents) sur les serveurs Web et les différentes applications. La sécurité des différents serveurs est donc surchargée par des agents. Ces filtres se chargent d obtenir les informations d authentification sur le serveur. Le schéma suivant présente une architecture SSO Web à base de filtres : 16 Sign&go

17 Apports du SSO pour l entreprise Utilisation L utilisateur cherche à accéder à un site du portail d accès. Après vérification de l authentification sur le portail, le serveur de sécurité renvoie à l agent les droits de l utilisateur pour le site en question. Un jeton d authentification est stocké sur le poste utilisateur; il est récupéré à chaque connexion du client vers un serveur et permet de vérifier son authentification. Si l utilisateur tente d accéder à un autre site, l agent de ce site va consulter le serveur de sécurité. L utilisateur étant déjà authentifié (jeton d authentification), l agent renvoie directement les droits de l utilisateur sur le nouveau site. Avantages Les principaux avantages de l architecture SSO Web à base de filtres reposent sur la sécurité, la montée en charge et la PKI. Sécurité La sécurité des flux est assurée de bout en bout. Montée en charge/haute disponibilité La montée en charge est naturellement répartie entre les différents serveurs et peut se gérer plus facilement du fait de l absence de goulot d étranglement. PKI Il n existe pas d intermédiaire entre le navigateur et le serveur Web, si bien qu une authentification forte de bout en bout est possible (Projet PKI/certificats X509). Inconvénients Les principaux inconvénients de l architecture SSO Web à base de filtres reposent sur l installation et l architecture. Installation L architecture des serveurs à sécuriser doit être modifiée afin d ajouter les composants de sécurité «agents filtres» (Intrusif sur le système cible). Architecture Ce système SSO dépend de l architecture car des filtres spécifiques sont requis pour les plates-formes et les serveurs Web. Les serveurs Web Internet Information Server (IIS), Netscape iplanet, Apache, Domino proposent leur propre technologie filtre. Cependant certains serveurs ne sont pas compatibles avec les architectures filtre. Sign&go 17

18 Apports du SSO pour l entreprise Bilan Ce type d architecture est recommandé dans les problématiques de connexion intranet décentralisées, c est-àdire quand les serveurs cibles sont répartis dans l entreprise ou quand la contrainte de sécurité est très forte (PKI). 18 Sign&go

19 Chapitre 2 Sign&go : une solution SSO adaptée Personnalisation des habilitations Gestion centralisée de la sécurité Interopérabilité

20

21 Sign&go : une solution SSO adaptée Personnalisation des habilitations Problématique du portail d entreprise Intégration aux annuaires existants Gestion du contenu des annuaires existants Un portail d entreprise est un agrégateur de contenu qui offre à chaque utilisateur (employés, clients, partenaires) un accès simplifié à l ensemble des ressources de l entreprise qui lui sont nécessaires. Ces informations, disponibles sur une interface Web, sont personnalisées en fonction des profils de chaque utilisateur. L accès aux ressources est donc précédé d une authentification. Cependant, la gestion traditionnelle des multiples mots de passe diminue la productivité des administrateurs et des utilisateurs et fragilise la stratégie sécuritaire de l entreprise. La mise en place de Sign&go, outil de SSO, sur le portail d entreprise, permet de contrer ces problèmes tout en adaptant les habilitations aux besoins de l entreprise. L utilisateur s authentifie une fois lors de sa connexion au portail et bénéficie ensuite d un accès transparent à toutes les ressources auxquelles il a droit. Les groupes d utilisateurs pour les habilitations existantes sont stockés dans l annuaire de l entreprise. Sign&go se branche directement dans l annuaire de l entreprise et n impose pas de structure d annuaire de sécurité. Il s adapte à l existant (tous les annuaires LDAP et toutes les bases SQL) et applique le contenu défini dans l annuaire. L alliance de Sign&go, outil de SSO, et de Meibo 1, outil de gestion de contenu d annuaires, rend possible l installation d une solution de SSO sur mesure, adaptée aux spécificités fonctionnelles de l entreprise. En effet, grâce à Meibo, ILEX met à la disposition des entreprises un outil capable de bâtir des vues métiers sur des annuaires LDAP existants. Il est ainsi possible de mettre en place rapidement des interfaces Web personnalisées de gestion de contenu d annuaire. Ces interfaces peuvent, par exemple, associer la liste des utilisateurs et leurs groupes, les profils métiers et les applications présentes dans l entreprise. L approche WYSIWYG unique de Meibo Studio permet une mise en place aisée et sans programmation d interfaces utilisateurs Web personnalisées par profils métiers. 1. Meibo est un produit de gestion de contenu d annuaires LDAP, créé par ILEX. Sign&go 21

22 Sign&go : une solution SSO adaptée En définitive, Meibo, outil de gestion de contenu, se charge d alimenter les référentiels de sécurité, tandis que Sign&go, outil de SSO, applique ce qui a été défini dans ces référentiels. De plus, ces deux outils s adaptent, sans aucune modification, aux référentiels existants. Création de règles d accès spécifiques Dans Sign&go, la configuration de la sécurité repose sur les règles d accès. Une règle d accès se compose de critères et de comportements. Dans un premier temps, les critères sont testés, puis les comportements, déterminés par le résultat des critères, sont renvoyés à l agent d habilitation. L administration Sign&go présente différents types de critères tels que la validité du jeton, l appartenance de l utilisateur à un groupe et différents types de comportements tels que l accès autorisé, l accès refusé, la redirection vers une URL. L administrateur a également la possibilité de créer des critères et des comportements spécifiques pour personnaliser leurs règles d accès en fonction des besoins de l entreprise. Gestion centralisée de la sécurité Serveur d administration Annuaire Sign&go Interface administrateur Sign&go Grâce au serveur d administration Sign&go, l administrateur gère, de manière centralisée, l ensemble des paramètres de Sign&go. L interface administrateur facilite la gestion de ces données. L ensemble des données Sign&go (schémas d authentification, règles d accès...) est stocké, par défaut, dans un annuaire OpenLDAP. Sign&go peut aussi fonctionner dans tous les annuaires LDAP v3 du marché. L interface administrateur Sign&go présente cinq onglets : Configuration, Annuaire, Authentification, PKI, Domaine. Pour obtenir la description de l ensemble des paramètres, il suffit de cliquer sur le bouton Aide. L aide en ligne HTML s affiche alors. 22 Sign&go

23 Sign&go : une solution SSO adaptée En cliquant sur l onglet Configuration, puis sur le sous-menu Configuration générale, on obtient l image suivante : Chaque onglet dispose d un menu qui s affiche dans la partie gauche de l écran. Quand on sélectionne l item d un menu, les paramètres de configuration correspondants s affichent dans la partie droite. Un bouton Enregistrer apparaît sous les paramètres. Après la création ou la modification de paramètres, il suffit de cliquer sur le bouton Enregistrer. Ces nouveaux paramètres sont ainsi pris en compte par Sign&go. Note En cas de problèmes, n hésitez pas à envoyer un mail à l équipe support ILEX en cliquant sur le bouton Mail. Configuration Annuaire Le menu Configuration permet de définir la configuration générale de Sign&go et de créer/modifier/supprimer les agents Sign&go. Veuillez vous référer à Gérer les jetons, l annuaire principal Sign&go et les accréditations secondaires, page 54 et Configurer un agent, page 51. Le menu Annuaire permet de créer/modifier/supprimer la configuration des annuaires utilisateurs existants et les mappings d annuaires. Veuillez vous référer à Configurer un annuaire, page 51. Sign&go 23

24 Sign&go : une solution SSO adaptée Authentification PKI Domaine Le menu Authentification permet de créer/modifier/ supprimer la configuration des schémas d authentification et les listes d authentification. Veuillez vous référer à Configurer un schéma d authentification, page 52 et Créer une liste d authentification, page 53. Le menu PKI permet de créer/modifier/supprimer les mappings de certificats. Le menu Domaine permet de créer/modifier/supprimer les domaines, les politiques de sécurité, les règles d accès et la configuration des critères et des comportements. Veuillez vous référer à Créer une politique de sécurité, page 59 et Créer une règle d accès, page 60. Interopérabilité Plates-formes compatibles Serveurs Web compatibles Les agents filtres Web Sign&go sont compatibles avec les principales plates-formes du marché. Les agents Proxy/Reverse-Proxy Sign&go sont compatibles avec la plate-forme Windows. Le serveur de sécurité Sign&go 100% Java est multi platesformes. Les agents filtres Web Sign&go sont disponibles sur différents serveurs Web et plates-formes du marché : Microsoft IIS version 3.0 et supérieure (Windows NT/ 2000/XP), Apache version 1.3 et 2.0 (Linux), Netscape Enterprise Server (Windows NT/2000/XP, Solaris, AIX), iplanet (Windows NT/2000/XP, Solaris, AIX), Sun One (Windows NT/2000/XP, Solaris, AIX), Lotus Domino Application Server version 5 et supérieure (Windows NT/2000/XP). 24 Sign&go

25 Chapitre 3 Architecture globale de Sign&go Sign&go : schéma général d architecture Principe général de Sign&go Architecture haute disponibilité Comment accéder à une ressource protégée? Comment authentifier un utilisateur?

26

27 Architecture globale de Sign&go Sign&go : schéma général d architecture Présentation L architecture générale de Sign&go est présentée dans le schéma suivant : Composants Sign&go Sign&go présente différents composants : Agents (Filtres Web, Proxy/Reverse-Proxy, API) Il s agit d agents d authentification et/ou d agents d habilitation qui jouent le rôle d intermédiaires entre le poste utilisateur et le serveur de sécurité. Serveur de sécurité Il intervient lors des phases d authentification et d habilitation de l utilisateur. Serveur d administration Il permet la gestion centralisée de Sign&go. Principe général de Sign&go Principe du SSO Jeton de session crypté Sign&go, outil de SSO, met en oeuvre un mécanisme par lequel l utilisateur n a besoin de s authentifier qu une seule fois pour accéder à plusieurs ressources hétérogènes. Ainsi, Sign&go mémorise l identité de l utilisateur, sur une authentification primaire, dans un jeton de session crypté, stocké sous forme d un cookie mémoire. Ce cookie va gérer ensuite les authentifications secondaires de l utilisateur de manière transparente. Sign&go 27

28 Architecture globale de Sign&go Authentification/ Habilitation Les phases d authentification et d habilitation sont contrôlées par le serveur de sécurité Sign&go. Prenons l exemple d un utilisateur qui cherche à accéder à une ressource protégée. En cas d authentification positive, le serveur de sécurité crée un jeton de session qu il envoie à l utilisateur. Ce jeton de session est stocké, dans le navigateur de l utilisateur, sous forme de cookie mémoire. Chaque jeton de session sert de passeport à l utilisateur pour les requêtes suivantes. Architecture haute disponibilité Combinaison des serveurs de sécurité Indépendance des serveurs de sécurité Montée en charge L architecture modulaire de Sign&go permet une mise en place aisée dans des architectures de type haute disponibilité. Chaque agent Sign&go est capable de se connecter avec un ensemble de serveurs de sécurité. La connexion peut s effectuer en : Fail-Over L agent se connecte sur un premier serveur, puis se connecte sur un second serveur si le premier ne répond plus. Round-Robin L agent se connecte successivement sur chaque serveur de sécurité afin de procéder à un équilibrage de charge entre les différents serveurs. L architecture Sign&go, basée autour de la notion de jeton de session sécurisé, rend les serveurs de sécurité indépendants. Un individu peut venir s authentifier auprès d un premier couple agent/serveur de sécurité, puis présenter son jeton de session auprès d un deuxième couple agent/serveur de sécurité; les serveurs de sécurité n auront pas besoin de communiquer mutuellement. En effet, les serveurs de sécurité partagent un même secret qui sert de base au calcul des clés de chiffrement des jetons de sessions. Ils utilisent donc les mêmes clés de chiffrement du jeton de session et forment une zone de confiance (serveurs interopérables). Il existe une mécanique complexe de cache multiniveau entre les agents et les serveurs de sécurité. Ce cache rend un agent rapidement autonome vis-à-vis d un client donné. 28 Sign&go

29 Architecture globale de Sign&go Les mécaniques de cache de Sign&go optimisent de façon radicale les performances et permettent ainsi d appréhender sereinement les phases de montée en charge. Comment accéder à une ressource protégée? Accéder à une ressource par filtre Web Le schéma suivant présente l accès à une ressource par un agent Sign&go filtre Web. Voir Etapes, page 30 pour l explication des phases d authentification et d habilitation. Accéder à une ressource par Proxy/Reverse- Proxy Le schéma suivant présente l accès à une ressource par un agent Sign&go Proxy/Reverse-Proxy. Voir Etapes, page 30. Sign&go 29

30 Architecture globale de Sign&go Etapes 1 L utilisateur cherche à accéder à une ressource protégée sur le serveur Web. Il clique sur le lien applicatif du portail. Un agent installé sur le serveur joue le rôle d agent d authentification et d habilitation (Filtre Web, Proxy/ Reverse-Proxy). 2 L agent fournit au serveur de sécurité toutes les informations concernant l utilisateur selon le mécanisme d authentification (Identifiant/Mot de passe, en-têtes HTTP, certificat X509...). Il fournit également le jeton de session éventuellement en place en cas d authentification antérieure. 3 A chaque agent correspond une liste de schémas d authentification. Le serveur de sécurité isole la liste des schémas d authentification de l agent. 4 Le serveur de sécurité teste chaque schéma d authentification vis-à-vis des informations reçues de l agent et des habilitations enregistrées dans les annuaires utilisateurs. 5 Un schéma d authentification aboutit quand les informations reçues sont suffisantes pour authentifier l utilisateur. Un jeton de session est alors généré. Il sert de passeport d authentification à l utilisateur. Ce jeton de session intervient ensuite dans la phase de gestion des habilitations. Note Si l authentification échoue, le jeton de session n est pas créé, mais la phase de gestion des habilitations se poursuit. 6 Après la phase d authentification, le serveur de sécurité recherche la politique de sécurité associée à la ressource demandée. Note Dans le cas où plusieurs politiques de sécurité sont éligibles pour une ressource donnée, Sign&go choisit la politique correspondant à la ressource la plus restrictive. 7 Le serveur de sécurité exécute séquentiellement les règles d accès attachées à la politique de sécurité de la ressource. Une règle d accès se compose d un ensemble de critères à tester et d un ensemble de comportements correspondants aux actions de l agent. 30 Sign&go

31 Architecture globale de Sign&go 8 Après la phase d habilitation, l ensemble des comportements et le jeton de session sont renvoyés à l agent. 9 L agent applique l ensemble des comportements. 10 L utilisateur reçoit la réponse à sa requête. Le jeton de session est positionné en tant que cookie mémoire sur le navigateur du poste utilisateur. Comment authentifier un utilisateur? Authentifier un utilisateur par API Le schéma suivant présente l authentification d un utilisateur avec un agent Sign&go API. Voir Etapes, page 31 pour l explication de la phase d authentification. Etapes 1 L utilisateur s authentifie sur le portail. Les API Sign&go utilisées par des fichiers du serveur Web correspondent à l agent d authentification. Elles prennent en charge le mécanisme d authentification. 2 L agent d authentification fournit au serveur de sécurité toutes les informations concernant l utilisateur selon le mécanisme d authentification (Identifiant/Mot de passe, en-têtes HTTP, certificat X509...). 3 A chaque agent d authentification correspond une liste de schémas d authentification. Le serveur de sécurité isole la liste des schémas d authentification de l agent. Sign&go 31

32 Architecture globale de Sign&go 4 Le serveur de sécurité teste chaque schéma d authentification vis-à-vis des informations reçues de l agent et des habilitations enregistrées dans les annuaires utilisateurs. 5 Un schéma aboutit quand les informations reçues sont suffisantes pour authentifier l utilisateur. Un jeton de session est alors généré et renvoyé à l agent d authentification. 6 L agent d authentification positionne le jeton de session en tant que cookie mémoire dans le navigateur du poste utilisateur. Il sert de passeport d authentification à l utilisateur. L utilisateur est alors authentifié. C est l authentification primaire. 32 Sign&go

33 Chapitre 4 Phase d authentification : le serveur de sécurité Principe de l authentification Agents d authentification Exploitation des annuaires existants Schémas d authentification Jeton de session

34

35 Phase d authentification : le serveur de sécurité Principe de l authentification Authentification primaire Authentification secondaire Le service d authentification correspond à deux fonctions distinctes et complémentaires : L identification qui associe une entité numérique à l entité se connectant au système. Cette fonction est effectuée par les agents d authentification configurés dans le serveur de sécurité. Voir Agents d authentification, page 35. L authentification qui vérifie et confirme que l entité qui s est identifiée est bien celle qu elle prétend être. Cette fonction est effectuée par les schémas d authentification couplés aux annuaires de l entreprise. Schémas et annuaires sont configurés dans le serveur de sécurité. Voir Schémas d authentification, page 38 et Exploitation des annuaires existants, page 37. Le SSO permet de simuler la saisie des authentifications secondaires. Après validation de l authentification primaire, un jeton de session est généré dans le serveur de sécurité. Il joue le rôle de passeport de l utilisateur et autorise ainsi les authentifications secondaires. Voir Jeton de session, page 39. Les identifiants/mots de passe secondaires des utilisateurs, appelés accréditations secondaires, peuvent être stockés : dans les annuaires utilisateurs de l entreprise (LDAP dont Active Directory ou SQL) ou, dans une base SQL créée par Sign&go. Les informations des annuaires et de la base sont chiffrées. Agents d authentification Rôle des agents d authentification Lorsqu un utilisateur cherche à accéder à une ressource, l agent d authentification du serveur concerné communique au serveur de sécurité Sign&go toutes les informations de l utilisateur (identifiant/mot de passe, certificat X509...). Si l authentification est validée, l agent d authentification positionne le jeton de session en tant que cookie sur le poste utilisateur. Sign&go 35

36 Phase d authentification : le serveur de sécurité Les différents agents Les agents d authentification sont de trois types : Filtres Web, Proxy/Reverse-Proxy, API. Note Les filtres Web et Proxy/Reverse-Proxy sont des agents d authentification à la volée et jouent aussi le rôle d agents d habilitation. Filtres Web Proxy/ Reverse-Proxy Il s agit d un type intrusif d agent d authentification. Les filtres Web sont des filtres directement installés sur le serveur Web. On distingue différents types d authentification pour les filtres Web : NTLM/Kerberos Ces modes exploitent l identification de la session Windows. Ils fonctionnent uniquement avec un navigateur Internet Explorer et un serveur Web IIS sur une plateforme Windows NT pour NTLM et Windows 2000 ou XP pour Kerberos. Digest/Basic HTTP Ces modes exploitent l identification serveur soit en Digest MD5, soit en Basic HTTP. Authentification forte PKI La PKI fournit des produits et des services pour la gestion de certificats et de clés et permet la mise en place des mécanismes de non-répudiation, d authentification et d intégrité. Ce mode intervient lors de l utilisation de certificats X509. Le mapping de certificat Sign&go effectue la vérification sur les listes de révocation des certificats (CRL) et la recherche de l identité de l utilisateur dans l annuaire. Formulaire HTML Ce mode exploite un formulaire HTML pour obtenir un identifiant et un mot de passe de l utilisateur. On distingue différents types d authentification pour les Proxy/Reverse-Proxy : Digest/Basic HTTP Ces modes exploitent l identification serveur soit en Digest MD5, soit en Basic HTTP 36 Sign&go

37 Phase d authentification : le serveur de sécurité Authentification forte PKI Ce mode intervient lors de l utilisation de certificats X509. La vérification de la liste de révocation et la recherche de l identité de l utilisateur est effectué par le mapping de certificat. Formulaire HTML Ce mode exploite un formulaire HTML pour obtenir un identifiant et un mot de passe de l utilisateur. Check Point NG/Firewall-1 Ce mode récupère l identité d un individu reconnu par un coupe-feu VPN-1/Firewall-1 de Check Point. Il fonctionne uniquement avec un Reverse-Proxy. API Il s agit d un type intrusif d agent d authentification. Les API sont installées sur les serveurs Web compatibles. On distingue différents types d authentification pour les API Java ou Active-X : Identifiant/Mot de passe Ce mode valide la présence de ces données dans l annuaire. Etat de confiance Ce mode valide uniquement la présence de l identifiant utilisateur dans l annuaire. L authentification est gérée par l applicatif. Anonyme Ce mode génère des «jetons de session anonymes» qui contiennent la même identité pour tous les utilisateurs. Les «jetons anonymes» ou «jetons sans droits» ne font pas appel aux profils métiers des utilisateurs. Voir Jeton de session, page 39. Carte Professionnel de Santé (CPS) Dans ce mode, la carte CPS est couplée à un composant Java installé sur le navigateur du poste utilisateur. Exploitation des annuaires existants Annuaires existants L ensemble des données d authentification des utilisateurs est stocké dans les annuaires de l entreprise. Sign&go fonctionne avec tous les annuaires LDAP dont Active Directory et toutes les bases SQL. Sign&go 37

38 Phase d authentification : le serveur de sécurité Annuaire principal Configuration des annuaires existants Migration d annuaires Personnalisation des annuaires On nomme annuaire principal l annuaire de l entreprise qui contient les profils métiers. Cet annuaire peut être choisi comme l annuaire de base pour Sign&go. Ainsi, lors de toute authentification, l annuaire principal sera consulté. Si l utilisateur est référencé sur un autre annuaire, Sign&go exploitera alors les mappings d annuaires pour l authentification. Voir Configurer un annuaire, page 51. Les connecteurs Sign&go peuvent exploiter directement les habilitations des utilisateurs contenues dans les annuaires existants de l entreprise. Ces informations sont véhiculées dynamiquement aux différents composants Sign&go (schémas d authentification, critères...). Chaque type d annuaire a un paramétrage propre. Il suffit de configurer l annuaire dans l interface d administration de Sign&go afin de définir l emplacement des utilisateurs, des groupes et des profils métier. Plusieurs annuaires de l entreprise peuvent être ainsi configurés. La possibilité d associer plusieurs annuaires à un schéma d authentification donné permet de réaliser des migrations d annuaires. Voir Schémas d authentification, page 38. L administrateur peut créer ses propres mappings d annuaires et connecteurs d annuaires. Pour créer des annuaires personnalisés, veuillez vous référer à la documentation de développement. Schémas d authentification Définition Schémas et agents d authentification Un schéma d authentification Sign&go permet de spécifier le type d authentification qui va être utilisé lors de la phase d authentification de Sign&go. A chaque agent d authentification est associé un ou plusieurs schémas d authentification. Lorsqu un utilisateur cherche à accéder à une ressource, le serveur de sécurité exécute séquentiellement les schémas d authentification associés à l agent d authentification. Ces schémas d authentification vérifient l identité des utilisateurs vis-à-vis des annuaires associés. 38 Sign&go

39 Phase d authentification : le serveur de sécurité Si l authentification est validée, le serveur de sécurité génère un jeton de session qui sera renvoyé à l agent d authentification. Niveau de confiance Un schéma d authentification est configuré avec un niveau de confiance. Ce niveau de confiance est référencé dans l identité du jeton de session. Lors de la phase d habilitation, l administrateur peut créer des règles d accès avec des critères liés à ce niveau de confiance. Note Attention au niveau de confiance du schéma d authentification utilisant le type d authentification Anonyme (Voir API, page 37). Il est préférable d appliquer un niveau de confiance bas. Liste d authentification Schémas d authentification personnalisés Listes d authentification personnalisées Une liste d authentification regroupe des schémas d authentification de manière ordonnée. A chaque agent d authentification est associé une liste d authentification. L administrateur peut créer ses propres schémas d authentification et augmenter ainsi l offre Sign&go de schémas d authentification. Ces schémas d authentification personnalisés sont administrables de la même façon que les schémas d authentification Sign&go. Pour créer des schémas d authentification personnalisés, veuillez vous référer à la documentation de développement. Les schémas d authentification personnalisés apparaissent automatiquement dans la liste des schémas d authentification pour créer une liste d authentification personnalisée. Jeton de session Définition Un jeton de session est une information unique permettant de prouver l identité de l utilisateur. Il est généré par le serveur de sécurité en cas d authentification positive de l utilisateur. L agent d authentification positionne alors ce jeton de session en tant que cookie mémoire sur le poste utilisateur. Tous les jetons d une même installation Sign&go portent le même nom. Sign&go 39

40 Phase d authentification : le serveur de sécurité Chiffrement du jeton Persistance de l authentification Le jeton sert de passeport à l utilisateur et permet de véhiculer son identité. Les informations contenues dans le jeton sont donc cryptées. Le jeton de session, stocké dans le navigateur du poste utilisateur, a une durée de vie absolue. Ce délai, fixé par l administrateur, fait partie intégrante du jeton. Les authentifications secondaires transparentes de l utilisateur peuvent donc être gérées par le jeton de session initial s il est toujours valide. La validité du jeton de session pour l accès à une ressource dépend de sa durée de vie absolue et de son domaine de validité. Le tableau suivant présente les étapes de création ou de mise à jour d un jeton de session selon deux critères : l existence d un jeton de session initial et le résultat de l authentification. Jeton de session initial Schémas d authentification testés Authentification Pas d Authentification Présent et valide. (Niveau courant : NC) Seuls ceux dont le niveau de confiance est supérieur au NC Mise à jour du niveau courant du jeton On garde le jeton initial Absent Tous Création d un jeton Pas de jeton créé Domaine de validité Pour accéder à un site recherché, l utilisateur tape l URL du site. La structure de base d une URL est : <protocole>://<serveur>/<ressource> <serveur > représente le nom de domaine (nom de la machine hôte et type de ressource). Il est nécessaire de préciser le domaine de validité des jetons (serveur unique ou domaine DNS complet). En effet, lors des authentifications secondaires transparentes, seuls les jetons de session rattachés au serveur Web utilisé (défini dans le domaine de validité) seront pris en compte. Le domaine de validité du jeton de session doit comporter au minimum deux fois le caractère point. Dans le cas d un domaine DNS complet, il doit commencer avec un caractère point. 40 Sign&go

41 Phase d authentification : le serveur de sécurité Exemple : ou.ilex.fr sont des domaines valides alors que.fr est invalide. Composition d un jeton Un jeton de session est composé de plusieurs blocs : Identité L identité du jeton de session est définie au moment de la création du jeton et contient : l identifiant utilisateur, l annuaire sur lequel s est authentifié l utilisateur, l agent d authentification, la date et l heure d authentification, le niveau de confiance du moyen d authentification, la durée de vie absolue du jeton, le numéro de série unique du jeton. Note Le niveau de confiance est une information liée au schéma d authentification de l utilisateur, utilisable lors du contrôle d accès. Informations applicatives Les informations applicatives sont des informations utilisateurs facultatives (identifiant, mot de passe secondaire, profils métiers...) définies par l administrateur au moment de l authentification. Ces informations permettent d affiner le profil utilisateur et les habilitations. Elles seront délivrées directement aux agents d habilitation. La taille des informations applicatives est limitée à 2 Ko. Sign&go 41

42 Phase d authentification : le serveur de sécurité Pour ajouter des informations applicatives au moment de l authentification par API, filtres Web ou Proxy/Reverse- Proxy, veuillez vous référer à la documentation de développement. Note Les informations applicatives peuvent être modifiées durant toute la durée de vie du jeton. Timestamp Le Timestamp définit un délai d inactivité du jeton de session quand il n est pas utilisé pendant un certain temps. Ce délai prévaut sur la durée de vie absolue du jeton. Signature La signature permet de garantir l intégrité du jeton. 42 Sign&go

43 Chapitre 5 Phase d habilitation : la politique de sécurité Principe de la politique de sécurité Règle d accès

44

45 Phase d habilitation : la politique de sécurité Principe de la politique de sécurité Qu est-ce qu une ressource? Protection des ressources Rôle du serveur de sécurité Une ressource correspond à tout objet auquel un utilisateur tente d accéder ou tout privilège qu un utilisateur veut obtenir. Exemples de ressources : page Web, répertoire, page JSP, script CGI, servlet ou EJB... Une politique de sécurité permet de protéger un ensemble de ressources par un agent donné (Filtres Web, Proxy/Reverse- Proxy). Grâce aux règles d accès qui la composent, la politique de sécurité autorise ou refuse l accès de l utilisateur aux ressources demandées. Quand un utilisateur tente d accéder à une ressource protégée, le serveur de sécurité authentifie d abord l utilisateur par l intermédiaire des informations de l agent. Quel que soit le résultat de l authentification, la phase de gestion des habilitations est ensuite enclenchée. Le serveur de sécurité recherche alors la politique de sécurité associée à la ressource. Si la phase d habilitation est positive, l utilisateur est autorisé à accéder à la ressource demandée. Note Quand une ressource correspond à plusieurs politiques de sécurité, le serveur de sécurité choisit la politique de sécurité la plus restrictive vis-à-vis de la ressource. Niveau de confiance Le niveau de confiance de la politique de sécurité est le niveau de confiance exigé pour accéder à la ressource. Il s agit du niveau de confiance minimum pour considérer que l utilisateur est authentifié. Si le niveau de confiance courant de l individu (contenu dans le jeton de session) est inférieur au niveau de confiance requis, les règles d accès s appliquent alors sans tenir compte de l existence du jeton. Note Le niveau de confiance associé à une authentification est défini dans les schémas d authentification. Voir Schémas d authentification, page 38. Sign&go 45

46 Phase d habilitation : la politique de sécurité Règle d accès Définition Composition d une règle d accès Une règle d accès détermine la conduite à tenir lors d une requête de l utilisateur pour accéder à une ressource. Une règle d accès permet de réaliser une série de tests sur une requête provenant d un agent. En fonction du résultat de ces tests, la règle d accès dicte un certain nombre de comportements que l agent doit adopter. Un politique de sécurité peut utiliser plusieurs règles d accès. Dans ce cas, ces règles d accès sont ordonnées et exécutées séquentiellement. Une règle d accès se compose de trois éléments : des critères, des comportements à exécuter si la règle d accès aboutit : comportements OK, des comportements à exécuter si la règle d accès échoue : comportements KO. Les liens entre règle d accès, critères et comportements sont illustrés dans le tableau suivant : Règle d accès Valide Invalide Critères Tous les critères de la règle sont valides. Il suffit qu un seul critère de la règle soit invalide. Comportements OK KO Note L exécution des règles de sécurité peut s arrêter si une règle le spécifie explicitement. Exemple : création d une règle de contrôle d accès, commune à toutes les politiques de sécurité, qui arrête l exécution des autres règles d accès si l utilisateur n est pas authentifié. 46 Sign&go

47 Phase d habilitation : la politique de sécurité Critère Les critères sont des tests élémentaires de la règle d accès effectués sur la requête de l utilisateur, par exemple : présence ou non d un jeton de session, niveau d authentification spécifié dans le jeton de session, validation de l adresse IP de l utilisateur, profils métiers de l utilisateur, groupe de l utilisateur, attributs de l utilisateur, date et heure courante, accès sécurisé (connexion établie avec un protocole sécurisé). Le serveur de sécurité va, par défaut, se connecter à l annuaire principal de l entreprise pour l exécution de certains critères (groupe, profils métiers...). L administrateur a la possibilité de changer cette connexion par défaut. Veuillez vous référer à la documentation de développement. Comportement Un comportement correspond à l action de l agent en réponse aux tests des critères de la règle d accès. A l issue de la phase d habilitation, le serveur de sécurité renvoie l ensemble des comportements à l agent. Si la règle d accès est valide, les comportements OK sont exécutés, sinon ce sont les comportements KO. Les comportements sont de type : Contrôle d accès, Autoriser l accès à la ressource/ Refuser l accès à la ressource/ Rediriger l utilisateur vers une autre URL Passage d informations à l application Web, Insérer de nouveaux paramètres d URL ou en-têtes HTTP SSO Simuler l authentification en BasicHTTP/ Simuler le remplissage de formulaires HTML. Les comportements peuvent réenclencher une authentification si la première authentification n avait pas un niveau de confiance suffisant pour exploiter certaines ressources. Personnalisation des critères et comportements L administrateur peut créer ses propres critères et comportements. Veuillez vous référer à la documentation de développement. Sign&go 47

48

49 Chapitre 6 Configurer la phase d authentification Etapes initiales Gérer les jetons, l annuaire principal Sign&go et les accréditations secondaires

50

51 Configurer la phase d authentification Etapes initiales Présentation Configurer un agent L ensemble des étapes de configuration est effectué par l administrateur dans le serveur d administration. Veuillez vous référer aux chapitres Agents d authentification, page 35, Exploitation des annuaires existants, page 37, Schémas d authentification, page 38 et Liste d authentification, page 39. Pour configurer un agent : 1 Cliquez sur l icône Configuration, 2 Cliquez sur Agents, Une fiche de configuration d un agent s affiche. 3 Configurez les paramètres du nouvel agent. Ces paramètres sont décrits dans l aide. Note Le dernier paramètre Liste d authentification utilisée ne possède pas encore d options dans sa liste déroulante. 4 Cliquez sur Enregistrer. Après l enregistrement, le nouvel agent s affiche, dans le menu Agents, sous la forme Nom-Descriptif. Configurer un annuaire Pour configurer un annuaire : 1 Cliquez sur l icône Annuaire, 2 Cliquez sur Annuaires, Sign&go 51

52 Configurer la phase d authentification Une fiche de configuration d un annuaire s affiche. 3 Configurez les paramètres du nouvel annuaire. Ces paramètres sont décrits dans l aide. 4 Cliquez sur Enregistrer. Après l enregistrement, le nouvel annuaire s affiche, dans le menu Annuaires, sous la forme Nom-Descriptif. Configurer un schéma d authentification Pour configurer un schéma d authentification : 1 Cliquez sur l icône Authentification, 2 Cliquez sur Schémas d authentification, Une fiche de configuration d un schéma d authentification s affiche. 52 Sign&go

53 Configurer la phase d authentification 3 Configurez les paramètres du nouveau schéma d authentification. Ces paramètres sont décrits dans l aide. 4 Cliquez sur Enregistrer. Après l enregistrement, le nouveau schéma s affiche, dans le menu Schémas d authentification, sous la forme Nom- Descriptif. Créer une liste d authentification Pour créer une liste d authentification, plusieurs schémas d authentification peuvent être configurés : 1 Cliquez sur l icône Authentification, 2 Cliquez sur Listes d authentification, Une fiche de création d une liste d authentification s affiche. 3 Configurez les paramètres de la nouvelle liste d authentification. Ces paramètres sont décrits dans l aide. 4 Cliquez sur Enregistrer. Après l enregistrement, la nouvelle liste s affiche, dans le menu Listes d authentification, sous la forme Nom- Descriptif. Note Dans la liste, il est conseillé de classer les schémas d authentification selon leur niveau de confiance de façon décroissante grâce aux boutons Monter/Descendre. Les schémas d authentification seront exécutés séquentiellement; le premier schéma de la liste est exécuté en premier. Sign&go 53

54 Configurer la phase d authentification Associer un agent à une liste d authentification Pour associer un agent à une liste d authentification : 1 Cliquez sur l icône Configuration, 2 Cliquez sur + devant Agents pour dérouler la liste des agents créés, 3 Cliquez sur Nom-Descriptif de l agent choisi, AG01- Agent01 dans l exemple. La fiche Consultation/Modification de l agent créé s affiche. 4 Complétez le paramètre Liste d authentification utilisée. Note Un schéma d authentification pour API n est jamais pris en compte par les agents filtres Web ou Proxy/Reverse-Proxy. De même un schéma d authentification pour agents d habilitation est ignoré par les agents API. 5 Cliquez sur Enregistrer. Gérer les jetons, l annuaire principal Sign&go et les accréditations secondaires Présentation La gestion des jetons, de l annuaire principal Sign&go et des accréditations secondaires s effectue dans la partie Configuration du serveur d administration. Veuillez vous référer aux chapitres Jeton de session, page 39, Annuaire principal, page 38 et Authentification secondaire, page Sign&go

55 Configurer la phase d authentification Chiffrement du jeton Avant toute première utilisation de Sign&go, il est nécessaire de changer les clés de chiffrement par défaut. Si plusieurs serveurs de sécurité Sign&go sont déployés, il peut s avérer utile de rendre ces serveurs interopérables. Ces serveurs doivent donc utiliser les mêmes clés de chiffrement de jeton : une zone de confiance est créée. Note Les accréditations secondaires sont également chiffrées. La clé de chiffrement est dérivée de celle de la page de Configuration. Configuration des paramètres 1 Cliquez sur l icône Configuration, 2 Cliquez sur Configuration générale, La fiche Visualisation de la configuration générale de Sign&go s affiche. 3 Configurez les paramètres. Ces paramètres sont décrits dans l aide. 4 Cliquez sur Enregistrer pour prendre en compte les changements de paramètres. Sign&go 55

56

57 Chapitre 7 Configurer la phase d habilitation Créer une politique de sécurité Créer une règle d accès

58

59 Configurer la phase d habilitation Créer une politique de sécurité Etapes préalables La politique de sécurité est créée dans le serveur d administration. Pour créer une politique de sécurité, il faut d abord créer un domaine : 1 Effectuez les étapes initiales de configuration de la phase d authentification. Voir Etapes initiales, page Cliquez sur l icône Domaine, 3 Cliquez sur Domaine, La fiche de création d un domaine s affiche. 4 Configurez les paramètres du nouveau domaine. Ces paramètres sont décrits dans l aide. 5 Cliquez sur Enregistrer. Après l enregistrement, le nouveau domaine s affiche, dans le menu Domaine, sous la forme Nom-Descriptif. 6 Cliquez sur + devant le nom du domaine, Deux sous-menus apparaissent : Politiques de sécurité et Règles d accès. Les politiques de sécurité Pour créer une politique de sécurité : 1 Cliquez sur l icône Domaine, 2 Cliquez sur + devant le nom du domaine qui vous intéresse (testdom-testdom dans l exemple), Deux sous-menus apparaissent : Politiques de sécurité et Règles d accès. Sign&go 59

60 Configurer la phase d habilitation 3 Cliquez sur Politiques de sécurité, Une fiche de création d une politique de sécurité s affiche. 4 Configurez les paramètres de la politique de sécurité. Ces paramètres sont décrits dans l aide. Note Le paramètre Liste des règles d accès à appliquer ne possède pas encore de règles définies sauf si l administrateur a créé des règles d accès avant d établir la politique de sécurité. Voir Créer une règle d accès, page Cliquez sur Enregistrer. Après l enregistrement, la nouvelle politique de sécurité s affiche, dans le menu Politiques de sécurité, sous la forme Nom-Descriptif. La politique de sécurité présente le sous-menu Règles d accès. Créer une règle d accès Etapes préalables Pour créer une règle d accès, il faut configurer des critères et des comportements. Les critères et les comportements créés s affichent alors automatiquement dans la règle d accès. 60 Sign&go

61 Configurer la phase d habilitation Les règles d accès Pour créer une règle d accès : 1 Cliquez sur l icône Domaine, 2 Cliquez sur + devant le nom du domaine qui vous intéresse(testdom-testdom dans l exemple), Deux sous-menus apparaissent : Politiques de sécurité et Règles d accès. 3 Cliquez sur Règles d accès, Une fiche de création d une règle d accès s affiche. Note Si vous avez créé une politique de sécurité, vous pouvez aussi cliquer sur Règles d accès, dans le sous-menu de la politique de sécurité (Nom-Descriptif). 4 Configurez les paramètres de la règle d accès. Ces paramètres sont décrits dans l aide. Note La règle d accès ne possède pas encore de critères et de comportements. 5 Cliquez sur Enregistrer. Après l enregistrement, la nouvelle règle d accès s affiche, dans le menu Règles d accès, sous la forme Nom- Descriptif. La règle d accès présente le sous-menu : Critères, Comportements OK, Comportements KO. Sign&go 61

62 Configurer la phase d habilitation Voir Configurer un critère, page 62 et Configurer un comportement, page 63. Configurer un critère La configuration d un critère suit la création d une règle. 1 Sous le nom de la règle créée (testreg-testreg dans l exemple), cliquez Critères, Une fiche de configuration d un critère s affiche. 2 Configurez les paramètres du critère. Ces paramètres sont décrits dans l aide. 3 Cliquez sur Enregistrer. Après l enregistrement, le nouveau critère s affiche, dans le menu Critères, sous la forme Nom-Descriptif. Le critère apparaît automatiquement dans la liste des critères de la règle d accès correspondante. Note Après la configuration de plusieurs critères, cliquez sur la règle d accès pour classer ces critères à l aide des boutons Monter/Descendre. Les critères sont exécutés séquentiellement. Le premier critère de la liste est exécuté en premier. 62 Sign&go

63 Configurer la phase d habilitation Configurer un comportement La configuration des comportements OK et KO suit la création d une règle. 1 Sous le nom de la règle créée (testreg-testreg dans l exemple), cliquez Comportements OK (ou KO), Une fiche de configuration d un comportement OK (ou KO) s affiche. 2 Configurez les paramètres du comportement. Ces paramètres sont décrits dans l aide. 3 Cliquez sur Enregistrer. Après l enregistrement, le nouveau comportement s affiche, dans le menu Comportements OK (ou KO), sous la forme Nom-Descriptif. Le comportement OK (ou KO) apparaît automatiquement dans la liste des comportements OK (ou KO) de la règle d accès. Note Après la configuration de plusieurs comportements, cliquez sur la règle d accès pour classer ces comportements à l aide des boutons Monter/Descendre. Les comportements sont exécutés séquentiellement. Le premier comportement de la liste est exécuté en premier. Sign&go 63

64