Introduction à Sign&go Guide d’architecture · Apports du SSO pour l’entreprise Sign&go 9...

Introduction à Sign&goGuide d’architecture

Sign&go 3

Contact

ILEX51, boulevard Voltaire92600 Asnières-sur-SeineTél. : (33) 1 46 88 03 40Fax : (33) 1 46 88 03 41

Mél. : [email protected] Web : www.ilex.fr

Informations légales

Sign&goTM 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. 122-4 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. 335-2 et suivants du Code de la Propriété Intellectuelle.

Copyright ILEX 2003. Tous droits réservés.

Table des matières

Sign&go 5

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

Sign&go : une solution SSO adaptée ............... 19Personnalisation des habilitations ...................................... 21Gestion centralisée de la sécurité ........................................ 22Interopérabilité ...................................................................... 24

Architecture globale de Sign&go ..................... 25Sign&go : schéma général d’architecture ........................... 27Principe général de Sign&go ............................................... 27Architecture haute disponibilité ......................................... 28Comment accéder à une ressource protégée ? .................. 29Comment authentifier un utilisateur ? ............................... 31

Phase d’authentification : le serveur de sécurité .......................................................... 33

Principe de l’authentification .............................................. 35Agents d’authentification ..................................................... 35Exploitation des annuaires existants .................................. 37Schémas d’authentification .................................................. 38Jeton de session ...................................................................... 39

Phase d’habilitation : la politique de sécurité .43Principe de la politique de sécurité ..................................... 45Règle d’accès .......................................................................... 46

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

Configurer la phase d’habilitation .................... 57Créer une politique de sécurité ........................................... 59Créer une règle d’accès ......................................................... 60

7

Chapitre 1

Apports du SSO pour l’entreprise

Définition du Single Sign-On (SSO) ..................................... 9Différents types de SSO ........................................................ 10SSO Web : la problématique du portail ............................. 11Architecture SSO Web Reverse-Proxy ............................... 11Architecture SSO Web Proxy .............................................. 14Architecture SSO Web à base de filtres .............................. 16


Sign&go 9

Définition du Single Sign-On (SSO)

Principe 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.

Mise en oeuvre 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...

Fondements de lasécurité

Le SSO est donc une extension de deux fondements de la sécurité : l’authentification et l’habilitation.


10 Sign&go

Différents types de SSO

Classification Dans le cadre des solutions orientées entreprise (intranet, extranet), on distingue trois grands types de SSO :

SSO Poste LocalIl 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 CentralIl s’agit d’une sous-catégorie de SSO Poste Local qui donne accès aux applications des sites centraux des entreprises.SSO WebA 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.

Une différenciationfaible

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.

Avantage du SSOWeb

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é.


Sign&go 11

SSO Web : la problématique du portail

Principe du portail 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.

Utilisation du portail 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...).

Apports du SSOWeb

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).


12 Sign&go

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.

InstallationLe 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).

ArchitectureLes 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).


Sign&go 13

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é.

PKICe 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.


14 Sign&go

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 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.

Avantages Les principaux avantages de l’architecture SSO Web Proxy reposent sur l’installation, l’architecture et la montée en charge.


Sign&go 15

InstallationAprè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.

ArchitectureL’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.

ConfigurationCe 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.

PKICe système de SSO est partiellement compatible avec les PKI.


16 Sign&go

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 :


Sign&go 17

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.

PKIIl 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.

InstallationL’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).

ArchitectureCe 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.


18 Sign&go

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).

19

Chapitre 2

Sign&go : une solution SSO adaptée

Personnalisation des habilitations ...................................... 21Gestion centralisée de la sécurité ........................................ 22Interopérabilité ...................................................................... 24


Sign&go 21

Personnalisation des habilitations

Problématique duportail d’entreprise

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.

Intégration auxannuaires existants

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.

Gestion du contenudes annuaires

existants

L’alliance de Sign&go, outil de SSO, et de Meibo1, 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.


22 Sign&go

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èglesd’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é

Serveurd’administration

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.

Annuaire Sign&go 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é.

Interfaceadministrateur

Sign&go

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.


Sign&go 23

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.

Configuration 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.

Annuaire 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.

NoteEn cas de problèmes, n’hésitez pas à envoyer un mail à l’équipe support ILEX en cliquant sur le bouton Mail.


24 Sign&go

Authentification 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.

PKI Le menu PKI permet de créer/modifier/supprimer les mappings de certificats.

Domaine 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-formescompatibles

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 plates-formes.

Serveurs Webcompatibles

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).

25

Chapitre 3

Architecture globale de Sign&go

Sign&go : schéma général d’architecture .......................... 27Principe général de Sign&go ............................................... 27Architecture haute disponibilité ......................................... 28Comment accéder à une ressource protégée ? .................. 29Comment authentifier un utilisateur ? ............................... 31


Sign&go 27

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 :

ComposantsSign&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’administrationIl permet la gestion centralisée de Sign&go.

Principe général de Sign&go

Principe du SSO 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.

Jeton de sessioncrypté

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.


28 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 desserveurs de

sécurité

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-OverL’agent se connecte sur un premier serveur, puis se connecte sur un second serveur si le premier ne répond plus.Round-RobinL’agent se connecte successivement sur chaque serveur de sécurité afin de procéder à un équilibrage de charge entre les différents serveurs.

Indépendance desserveurs de

sécurité

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).

Montée en charge 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é.


Sign&go 29

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 à uneressource 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 à uneressource 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.


30 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.

6 Après la phase d’authentification, le serveur de sécurité recherche la politique de sécurité associée à la ressource demandée.

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.

NoteSi l’authentification échoue, le jeton de session n’est pas créé, mais la phase de gestion des habilitations se poursuit.

NoteDans 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.


Sign&go 31

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 unutilisateur 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.


32 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.

33

Chapitre 4

Phase d’authentification : le serveur de sécurité

Principe de l’authentification .............................................. 35Agents d’authentification .................................................... 35Exploitation des annuaires existants .................................. 37Schémas d’authentification .................................................. 38Jeton de session ..................................................................... 39


Sign&go 35

Principe de l’authentification

Authentificationprimaire

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.

Authentificationsecondaire

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 agentsd’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.


36 Sign&go

Les différentsagents

Les agents d’authentification sont de trois types :Filtres Web,Proxy/Reverse-Proxy,API.

Filtres Web 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/KerberosCes modes exploitent l’identification de la session Windows. Ils fonctionnent uniquement avec un navigateur Internet Explorer et un serveur Web IIS sur une plate-forme Windows NT pour NTLM et Windows 2000 ou XP pour Kerberos.Digest/Basic HTTPCes modes exploitent l’identification serveur soit en Digest MD5, soit en Basic HTTP.Authentification forte PKILa 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 HTMLCe mode exploite un formulaire HTML pour obtenir un identifiant et un mot de passe de l’utilisateur.

Proxy/Reverse-Proxy

On distingue différents types d’authentification pour les Proxy/Reverse-Proxy :

Digest/Basic HTTPCes modes exploitent l’identification serveur soit en Digest MD5, soit en Basic HTTP

NoteLes filtres Web et Proxy/Reverse-Proxy sont des agents d’authentification à la volée et jouent aussi le rôle d’agents d’habilitation.


Sign&go 37

Authentification forte PKICe 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 HTMLCe mode exploite un formulaire HTML pour obtenir un identifiant et un mot de passe de l’utilisateur.Check Point NG/Firewall-1Ce 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 passeCe mode valide la présence de ces données dans l’annuaire.Etat de confianceCe mode valide uniquement la présence de l’identifiant utilisateur dans l’annuaire. L’authentification est gérée par l’applicatif.AnonymeCe 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.


38 Sign&go

Annuaire principal 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.

Configuration desannuaires existants

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.

Migrationd’annuaires

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.

Personnalisationdes annuaires

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 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.

Schémas et agentsd’authentification

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.


Sign&go 39

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 deconfiance

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.

Listed’authentification

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.

Schémasd’authentification

personnalisés

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.

Listesd’authentification

personnalisées

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.

NoteAttention 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.


40 Sign&go

Chiffrement dujeton

Le jeton sert de passeport à l’utilisateur et permet de véhiculer son identité. Les informations contenues dans le jeton sont donc cryptées.

Persistance del’authentification

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.

Domaine devalidité

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.

Jeton de session initial

Présent et valide.(Niveau courant : NC) Absent

Schémas d’authentification testés

Seuls ceux dont le niveau de confiance est supérieur au NC

Tous

Authentification Mise à jour du niveau courant du jeton

Création d’un jeton

Pas d’Authentification On garde le jeton initial Pas de

jeton créé


Sign&go 41

Exemple : www.ilex.fr ou .ilex.fr sont des domaines validesalors que .fr est invalide.

Composition d’unjeton

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.

Informations applicativesLes 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.

NoteLe niveau de confiance est une information liée au schéma d’authentification de l’utilisateur, utilisable lors du contrôle d’accès.


42 Sign&go

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.

TimestampLe 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.

SignatureLa signature permet de garantir l’intégrité du jeton.

NoteLes informations applicatives peuvent être modifiées durant toute la durée de vie du jeton.

43

Chapitre 5

Phase d’habilitation : la politique de sécurité

Principe de la politique de sécurité .................................... 45Règle d’accès .......................................................................... 46


Sign&go 45

Principe de la politique de sécurité

Qu’est-ce qu’uneressource ?

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...

Protection desressources

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.

Rôle du serveur desécurité

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.

Niveau deconfiance

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.

NoteQuand 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.

NoteLe niveau de confiance associé à une authentification est défini dans les schémas d’authentification. Voir “Schémas d’authentification”, page 38.


46 Sign&go

Règle d’accès

Définition 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.

Composition d’unerègle d’accès

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

NoteL’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é.


Sign&go 47

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 URLPassage d’informations à l’application Web,Insérer de nouveaux paramètres d’URL ou en-têtes HTTP SSOSimuler 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.

Personnalisationdes 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.

49

Chapitre 6

Configurer la phase d’authentification

Etapes initiales ....................................................................... 51Gérer les jetons, l’annuaire principal Sign&go et les accréditations secondaires ................................................... 54


Sign&go 51

Etapes initiales

Présentation 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.

Configurer unagent

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.

4 Cliquez sur Enregistrer.Après l’enregistrement, le nouvel agent s’affiche, dans le menu Agents, sous la forme Nom-Descriptif.

Configurer unannuaire

Pour configurer un annuaire :1 Cliquez sur l’icône Annuaire,2 Cliquez sur Annuaires,

NoteLe dernier paramètre ’Liste d’authentification utilisée’ ne possède pas encore d’options dans sa liste déroulante.


52 Sign&go

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 unsché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.


Sign&go 53

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 listed’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.

NoteDans 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.


54 Sign&go

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’.

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 35.

NoteUn 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.


Sign&go 55

Chiffrement dujeton

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.

Configuration desparamè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.

NoteLes accréditations secondaires sont également chiffrées. La clé de chiffrement est dérivée de celle de la page de Configuration.

57

Chapitre 7

Configurer la phase d’habilitation

Créer une politique de sécurité ........................................... 59Créer une règle d’accès ......................................................... 60


Sign&go 59

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 51.2 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 desé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.


60 Sign&go

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.

5 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.

NoteLe 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 60.


Sign&go 61

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.

4 Configurez les paramètres de la règle d’accès. Ces paramètres sont décrits dans l’aide.

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.

NoteSi 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).

NoteLa règle d’accès ne possède pas encore de critères et de comportements.


62 Sign&go

Voir “Configurer un critère”, page 62 et “Configurer un comportement”, page 63.

Configurer uncritè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.

NoteAprè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.


Sign&go 63

Configurer uncomportement

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.

NoteAprè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.

Introduction à Sign&go Guide d’architecture · Apports du SSO pour l’entreprise Sign&go 9...

Documents

Transcript of Introduction à Sign&go Guide d’architecture · Apports du SSO pour l’entreprise Sign&go 9...