Sécurisation des architectures traditionnelles et des SOA

Transcription

1 Sécurisation des architectures traditionnelles et des SOA Un livre blanc de Bull Evidian Gestion SAML des accès SSO aux applications classiques et J2EE. Max Vallot Sommaire Émergence des architectures SOA dans l entreprise SAM J2EE, un serveur d authentification SAML JAAS Intégration des applications héritées, Web et SAML J2EE Les architectures SOA pour applications internes nécessitent des services de contrôle des accès et d authentification de base homogènes

2 2013 Evidian Les informations contenues dans ce document reflètent l opinion d Evidian sur les questions abordées à la date de publication. En raison de l évolution constante des conditions de marché auxquelles Evidian doit s adapter, elles ne représentent cependant pas un engagement de la part d Evidian, qui ne peut garantir l exactitude de ces informations passée la date de publication. Ce document est fourni à des fins d information uniquement. EVIDIAN NE FAIT AUCUNE GARANTIE IMPLICITE NI EXPLICITE DANS LE PRESENT DOCUMENT. Les droits des propriétaires des marques citées dans cette publication sont reconnus.

3 Table des matières Émergence des architectures SOA dans l entreprise... 4 Développement d une architecture d applications modulaire pour une intégration du système d information de l entreprise... 4 Caractérisation des «services» dans une architecture SOA... 5 Conception et mise en œuvre d une architecture SOA... 6 Internet ou Intranet? Architectures SOA et Web Services... 7 Sécurisation d une architecture SOA... 7 Déploiement de fonctions de sécurité spécifiques... 8 Intégration dans des environnements non-soa... 8 Exemple d une plate-forme de gestion des accès et des identités... 8 SAM J2EE, un serveur d authentification SAML JAAS SAM J2EE utilise la connexion JASS et l authentification SAML Module de connexion JAAS Point d application des politiques Serveur d authentification SAML Point de décision des politiques SAM J2EE - Architecture SAM J2EE Caractéristiques principales Authentification des utilisateurs Fonction SSO (Single Sign-On) Audit de l authentification des utilisateurs Haute disponibilité et extensibilité Administration centralisée Une solution de gestion et de sécurité basée sur les annuaires Intégration des applications héritées, Web et SAML J2EE 14 SAM J2EE est un module AccessMaster A l opposé d une approche «big bang» Administration cohérente Authentification unique Scénario avec authentification forte des utilisateurs. 16 Scénario avec administration centralisée et fonction SSO Scénario dans un environnement Web Les architectures SOA pour applications internes nécessitent des services de contrôle des accès et d authentification de base homogènes F2 09LS Rev02 3

4 Émergence des architectures SOA dans l entreprise Dans les grandes entreprises, une large part du budget informatique est affectée à la gestion et à la maintenance des réseaux développés au fil des années. Il reste, par conséquent, peu de ressources disponibles pour financer les nouveaux projets dont ces sociétés ont besoin pour demeurer compétitives. Par ailleurs, dans une architecture informatique classique, les informations stratégiques (sur les recettes, les coûts, la concurrence, les tarifs, les politiques et modèles, etc.) nécessaires aujourd hui, et cruciales pour l avenir, sont difficiles d accès. Dans son ensemble, le système d information, grevé par une disponibilité médiocre et des redondances (au mieux) ou des incohérences (au pire), affiche donc de faibles performances générales. Enfin, l organisation des systèmes d information classiques est telle que les applications ou les données sont fortement dépendantes de leurs environnements techniques. En conséquence, tout effort de modernisation requiert un lourd investissement. Il y a quelques années, plusieurs tentatives ont été menées pour améliorer la factorisation des applications et l accessibilité des données partagées. Les premières ont été la conception orientée objet et CORBA. Elles n ont toutefois bénéficié qu aux seules applications, sans transformer radicalement le système d information. La recherche s est poursuivie avec les solutions EAI (Enterprise Application Integration), dont le principal défaut est de rendre toute l architecture dépendante de formats propriétaires, alors qu à bien des égards, les applications et les données évoluent vers une standardisation généralisée de leurs interfaces. Il fallait donc développer un concept architectural rendant possible l interconnexion des applications et des données, dont l indépendance vis-à-vis de l infrastructure matérielle soit basée sur des standards. Ce concept est généralement connu sous le nom d architecture SOA (Service Oriented Architecture, architecture orientée services). Développement d une architecture d applications modulaire pour une intégration du système d information de l entreprise Pour développer une architecture SOA, il faut organiser et analyser le système d information selon les processus métier de l entreprise. Avant de mettre en œuvre cette nouvelle architecture, vous devez évaluer les besoins liés à ces différents processus. Ceci aboutit à une organisation en domaines. Par la suite un ensemble de «services» doit être défini dans chaque domaine. Ces services constitueront les seules interfaces stables sur lesquelles reposeront les processus métier d un domaine. Celles-ci permettront également d échanger des ressources ou des données entre les domaines. Avec cette structure en services, de nouveaux processus peuvent rapidement être développés. 39 F2 09LS Rev02 4

5 Le département informatique ou les chefs de projet n ont plus qu à concentrer leur activité sur ces processus, au lieu de s efforcer à recréer des interfaces ou à générer des solutions presque identiques et des bases de données redondantes. Les divers projets sont basés sur un annuaire commun de services, qui constituent les services d applications ou de données «de base». Caractérisation des «services» dans une architecture SOA Si vous prenez les domaines comme seul objet de travail, vous risquez de les considérer comme des groupes isolés sans interaction entre eux. Les «services» sont donc essentiels pour intégrer les domaines dans l architecture unique, flexible et modulaire d un système d information. Mais comment définir un «service»? C est la question la plus souvent posée lorsqu un projet d architecture SOA est lancé. Vous trouverez quelques réponses ci-dessous : Les services sont l interface donnant accès à la logique métier des domaines. Chaque service est fourni par une application dédiée («fournisseur de service»). Les services ne doivent pas être spécifiques à un seul type de consommateur de service. Ils doivent être de conception suffisamment large pour pouvoir être utilisés par plusieurs consommateurs de service («forte granularité»). Ceci permet d accroître leur efficacité et de réaliser des économies d échelle. Les services sont stables sur le long terme. Ils décrivent les principales interactions au sein d une entreprise, qui sont habituellement bien plus durables que la mise en œuvre de besoins métier particuliers. Un service distingue le fournisseur du consommateur ; leurs implémentations sont ainsi rapidement modifiables de manière autonome (tant que le service reste stable). Un service établit un lien entre les domaines et l infrastructure informatique sous-jacente. La figure ci-après représente la structure d une architecture SOA. Figure 1. Principes d une architecture SOA Processus métier Domaine A Domaine B Domaine C Services A Services B Services C Infrastructures 39 F2 09LS Rev02 5

6 Conception et mise en œuvre d une architecture SOA Pour organiser une architecture SOA, vous devez mettre en œuvre une plate-forme de gestion (d intégration) des services. Elle est souvent appelée plate-forme NAP (Network Application Platform, plate-forme d applications réseau). La plate-forme NAP ne tient pas compte de la logique métier. En tant que participants au service, le fournisseur et le consommateur de service sont chargés de définir la logique métier, de la mettre en œuvre et d assurer son support. Ils sont inclus dans une organisation décentralisée et distribuée, conformément au paradigme du service intégré. Les services techniques de base (par exemple, les fonctions SSO, la supervision, la gestion des droits des utilisateurs, etc.) sont fournis par la plate-forme, ce qui rend l architecture encore plus souple. La figure 2 présente la mise en œuvre d une architecture SOA générale. Figure 2. Exemple de la mise en oeuvre d une architecture SOA Services techniques de base Gestion de la sécurité et des utilisateurs Administration du réseau des services Plate-forme NAP (Network Application Platform) pour l intégration Service Service Consumer Consommateur Consumer de service Service Service Provider Fournisseur Provider de service 39 F2 09LS Rev02 6

7 Internet ou Intranet? Architectures SOA et Web Services Pour mettre en place une architecture SOA, des investissements non négligeables doivent être engagés, pour des avantages considérables. Le système d information est progressivement révisé afin d être intégralement rationalisé et rendu compatible. L architecture SOA agit comme une sorte de système d exploitation réparti. Principal atout, un projet SOA ne nécessite pas de changement complet du jour au lendemain (approche «big bang»). Une fois la plate-forme NAP mise en place, les «services» sont progressivement définis et créés, puis les «fournisseurs» et les «consommateurs» s abonnent à la plate-forme. Vous pouvez alors abandonner les interfaces classiques par phases successives. Il serait dommage de restreindre les éléments clés des architectures SOA à quelques «services» fournis par le Web (certains types de transactions et d échanges via l extranet, par exemple). Une architecture SOA ne requiert pas nécessairement des Web Services. Il est important, au-delà de l implémentation de Web Services, de comprendre les principes architecturaux et les liens entre les services, les processus métier et les infrastructures techniques. Cependant, les standards de Web Services, qui sont en phase de maturation, constitueront à l avenir le jeu d outils le plus complet pour créer une architecture SOA. Sécurisation d une architecture SOA Pour sécuriser une architecture SOA, vous pouvez mettre en oeuvre au sein de la plate-forme NAP un ensemble de mécanismes permettant de protéger les échanges entre les fournisseurs et les consommateurs de service. Ces mécanismes font partie d un groupe de services nommé services techniques de base. Ils comprennent l adressage de services, la gestion des messages, la supervision de l architecture SOA, ainsi que la gestion des accès et des identités. Ces deux derniers services de base doivent permettre à tout fournisseur ou consommateur de service de vérifier l identité de l utilisateur associé à une transaction en cours (même si c est un serveur) et de s assurer qu il a le droit d effectuer cette transaction. De manière générale, les «fournisseurs de service» et les «consommateurs de service» utilisent ces services techniques de base de gestion des identités et des accès à deux niveaux : Lors de la première authentification d un utilisateur, la validité des informations que celui-ci fournit est vérifiée par les services techniques de base. Dans ce cas, l utilisateur peut tirer profit de la fonction SSO (Single Sign-On ou authentification unique). Lors d une demande «Consommateur/Fournisseur», le fournisseur de service doit pouvoir, grâce aux services techniques de base, vérifier l identité et les droits de l utilisateur. Les opérations sur les droits des utilisateurs et leur identité sont gérées directement par les services techniques de base sur la plate-forme NAP. 39 F2 09LS Rev02 7

8 Déploiement de fonctions de sécurité spécifiques En raison des contraintes géographiques liées à l organisation de l entreprise ou du niveau de confidentialité des applications utilisées, il peut être nécessaire de déployer une architecture de sécurité spécifique au niveau de la plate-forme NAP, sans pour autant impacter les applications. Par exemple, si une société fédère ses annuaires LDAP au niveau NAP dans un annuaire virtuel (V-Directory), elle sera en mesure d utiliser tous les processus existants de gestion des identités d utilisateur. Voici d autres exemples d architectures pouvant être déployées par les services de sécurité de base en toute transparence pour les applications : environnement de gestion multi-domaines des utilisateurs, solution de traçabilité des accès aux applications ou encore authentification des utilisateurs via des certificats X.509 (PKI). Intégration dans des environnements non-soa Les services de sécurité de base permettent également d assurer la cohérence entre la toute nouvelle architecture SOA et le système d information classique : mainframe, client-serveur, Web, etc. Comme ils sont indépendants des fournisseurs et des consommateurs de service, les services de sécurité de base d une architecture SOA peuvent être intégrés dans une solution plus globale de gestion des accès et des identités s appliquant au système d information. Exemple d une plate-forme de gestion des accès et des identités Pour doter une plate-forme NAP de fonctions d accès et d authentification en y intégrant une plate-forme IAM (Identity and Access Management Platform, plate-forme de gestion des accès et des identités), vous devez mettre en place trois niveaux distincts. Chacun traite distinctement la politique d authentification et d autorisation : Point de gestion des politiques (Policy Management Point, PMP), où cette politique est définie. Point de décision des politiques 1 (Policy Decision Point, PDP), où des décisions sont prises en fonction de cette politique. Point d'application des politiques (Policy Enforcement Point, PEP), où les décisions sont mises en oeuvre. 1 D habitude, les points de décision des politiques sont dédiés aux politiques d autorisation. Toutefois, le mot «politique» s applique également aux étapes d authentification. 39 F2 09LS Rev02 8

9 Sources d'identité Annuaire + flux Méta-annuaire Base de données RH Liberty Alliance Point de gestion des politiques Gestion des identités Gestion des politiques Point de décision des politiques Moteur d identification Moteur d autorisation Point d'application des politiques Poste de travail Passerelle Agent Les points de gestion des politiques et les points de décision des politiques sont indépendants de la technologie utilisée par les fournisseurs et les consommateurs de service. Les points d'application des politiques, en interface directe avec les consommateurs et les fournisseurs de service, sont très dépendants de la technologie que ceux-ci utilisent. Par exemple, le module SDM (Security Data Manager, module situé sur les PC) d AccessMaster est un point d application des politiques installé sur un poste de travail et mettant en oeuvre des règles dynamiques. L interface LDAP d AccessMaster connecte le serveur AccessMaster (point de gestion des politiques) à une source d identité LDAP. Le module SAM J2EE (Secure Access Manager J2EE) d AccessMaster met en œuvre un modèle SAML 2 dans lequel les modules de connexion JAAS sont des points d'application des politiques et les serveurs d authentification sont des points de décision des politiques. 2 SAML est un standard développé par OASIS (Organization for the Advancement of Structured Information Standards, et qui rend possible l interopérabilité des systèmes de sécurité fournissant des services d autorisation et d authentification. 39 F2 09LS Rev02 9

10 SAM J2EE, un serveur d authentification SAML JAAS SAM J2EE utilise la connexion JASS et l authentification SAML SAM J2EE (Secure Access Manager J2EE) est un service d authentification et d autorisation basé sur les standards ouverts de sécurisation des Web Services et des applications Java. Module de connexion JAAS Point d application des politiques SAM J2EE dispose d un module de connexion (Login Module) conçu pour l interface standard JAAS (Java Authentication and Authorization Service), et qui s'exécute dans un environnement Java. JAAS est une interface de programmation dotée de mécanismes souples et évolutifs de sécurisation des applications Java client et serveur. Elle agit également comme une couche d abstraction entre une application et les procédures d authentification et d autorisation, ce qui permet aux développeurs d applications d utiliser n importe quel mécanisme de sécurité. Avec le module de connexion JAAS de SAM J2EE, une application Java ou J2EE peut rapidement et facilement être sécurisée à l aide de mécanismes d authentification et d autorisation. C est une solution compatible avec toute application Java utilisant l interface JAAS à un degré d intégration peu poussé. Serveur d authentification SAML Point de décision des politiques Il s agit d un serveur qui effectue l'authentification puis, pour chaque authentification réussie, fournit une assertion SAML (Secure Assertion Markup Language). SAML procure un mécanisme de sécurité inter-opérable par lequel des applications dotées de leur propre système d autorisation et d authentification échangent des éléments d'authentification. Il apporte un cadre de sécurisation aux environnements multi-domaines ou aux architectures multi-niveaux. Ainsi, grâce au partage d informations de sécurité nécessaires à la réalisation d une transaction entre deux sites, celle-ci peut être initialisée sur un site et validée sur un autre. Lorsque les fonctionnalités SAML de SAM J2EE sont exploitées par les applications de l entreprise, celles-ci peuvent interagir plus facilement et en toute sécurité avec d autres entités, comme des partenaires commerciaux ou des clients. Le jeton SAML d un utilisateur peut circuler entre des partenaires commerciaux de confiance liés par une relation de type SSO (Single Sign-On). Les assertions SAML sont signées et vérifiées par les applications via une infrastructure PKI (Public Key Infrastructure). Une administration conviviale permet de définir le contenu des assertions, de gérer les infrastructures PKI associées nécessaires et, à un plus large niveau, toutes les configurations. 39 F2 09LS Rev02 10

11 SAM J2EE - Architecture Figure 3. Modules de connexion JAAS de SAM J2EE et serveur d authentification SAML Modules de connexion JAAS Demande d'authentification Serveur d'authentification HTTPS SAML Console d'administration Annuaire uitlisateurs Annuaire SAM J2EE Definition des utilisateurs Annuaires LDAP Définition des contenus SAML, Clés, certifications, listes CRL Le module de connexion JAAS est en interface avec le serveur d authentification utilisant le protocole SAML. Les applications sont alors en mesure d authentifier les demandeurs dans toutes les organisations, mais aussi de fournir des attributs utilisateur permettant de contrôler l accès aux ressources dans des zones multidomaines de sécurité. Les assertions SAML (authentification et attributs) sont signées par l autorité hébergée par le serveur d authentification. La signature SAML (XML) requiert le déploiement de certificats et la prise en charge des listes CRL (Certificate Revocation List). Ces fonctionnalités, transparentes pour l utilisateur, sont fournies par SAM J2EE. 39 F2 09LS Rev02 11

12 SAM J2EE Caractéristiques principales Les principales caractéristiques de SAM J2EE sont les suivantes : Authentification des utilisateurs Fonction SSO (Single Sign-On) SAM J2EE prend en charge plusieurs types d authentification. Les utilisateurs peuvent être authentifiés par l un des éléments suivants : par un nom d utilisateur et un mot de passe, par un mot de passe à usage unique reconnu dans les jetons matériels, par les dispositifs OTP (One-Time Password, mot de passe à usage unique) pris en charge par SAM SE (Secure Access Manager Standard Edition). Dans ce cas, le module de connexion installé sur le poste de travail obtient du module SDM de SAM SE le mot de passe à usage unique, qu il utilise pour authentifier l utilisateur et lui fournir une signature unique (fonction SSO). L utilisation du protocole SSL (Secure Socket Layer) garantit la confidentialité des échanges entre le module de connexion JAAS et le serveur d authentification. La fonction SSO est intégrée à SAM J2EE au niveau du jeton SAML de l utilisateur. Lorsque ce jeton est présenté aux applications, celles-ci n ont pas besoin de demander à l utilisateur de s identifier à nouveau. Audit de l authentification des utilisateurs Avec SAM J2EE, vous pouvez effectuer l audit des opérations d authentification des utilisateurs. Les messages d audit sont stockés dans des fichiers journaux consultables à tout moment. Haute disponibilité et extensibilité Les fonctions intégrées de SAM J2EE de haute disponibilité et de partage de charge permettent de garantir le maintient d'un niveau de performance satisfaisant et prévisible. Administration centralisée Au lieu de gérer séparément les règles d authentification, d infrastructure PKI (Public Key Infrastructure) et de contrôle d accès pour chaque application, SAM J2EE réunit toutes ces fonctionnalités en une seule console. Cette console d administration est une application Java exécutée sur des navigateurs Web prenant en charge le module d extension Java Run-time Environment. En outre, SAM J2EE dispose d une administration personnalisable à l aide d un jeu d interfaces API Java. Les programmeurs peuvent ainsi utiliser toutes les fonctions de la console d administration pour développer une application d administration personnalisée. 39 F2 09LS Rev02 12

13 Une solution de gestion et de sécurité basée sur les annuaires SAM J2EE incorpore en toute conformité les standards relatifs aux annuaires LDAP en mode natif. Deux annuaires sont utilisés : L annuaire SAM contient les descriptions des objets de sécurité et la configuration. L annuaire Utilisateurs (annuaire LDAP de l entreprise) contient les informations relatives aux utilisateurs et aux groupes. Il est possible qu un tel annuaire existe déjà dans votre société. Pour cette raison, cette instance peut être séparée de l annuaire SAM. Il n est donc pas nécessaire d'installer et de gérer des annuaires d utilisateurs distincts et redondants. 39 F2 09LS Rev02 13

14 Intégration des applications héritées, Web et SAML J2EE SAM J2EE est un module AccessMaster SAM J2EE fait partie de la suite de gestion des identités et de contrôle des accès intégrée et modulaire AccessMaster. Les modules "Secure Access Manager" présentent des fonctions avancées de contrôle des accès et d administration, utilisables même dans des architectures très hétérogènes. Dotés de solides fonctions d authentification, ils peuvent traiter plusieurs annuaires LDAP, réaliser des audits et possèdent de nombreuses fonctions d administration : Secure Access Manager - Standard Edition (SAM SE) est la solution avancée de contrôle des accès et d administration pour toutes les applications Intranet. Secure Access Manager - Web Edition (SAM Web) est la solution avancée de contrôle des accès et d administration dédiée aux projets Web Internet et Intranet. SSO Xpress SE est une solution SSO simple, sûre et auto-administrable pour tous les utilisateurs de l environnement Active Directory. Déployable sur les postes de travail Windows, elle peut aussi être installée sur des clients légers, tels que Windows Terminal Server ou Citrix. Pour mettre en oeuvre le «cycle de vie des utilisateurs», les modules de gestion des identités proposent une console d administration intégrée permettant de gérer les identités des utilisateurs, leurs comptes d application et leurs certificats : Identity Manager, pour l administration de tous les utilisateurs et de leurs attributs dans plusieurs annuaires LDAP. Provisioning Manager, pour l administration des comptes d utilisateur dans les divers systèmes, applications et bases de données de l entreprise. Certificate Manager, pour l administration des certificats d utilisateur. En fonction de la politique de sécurité de l entreprise, chaque module peut être déployé séparément ou intégré aux autres de manière homogène. 39 F2 09LS Rev02 14

15 A l opposé d une approche «big bang» Une nouvelle architecture peut être déployée selon trois approches. La première consiste à déployer une nouvelle architecture complètement séparée avec notamment son propre référentiel d utilisateurs, ses interfaces utilisateur, ses concepts, et dotée d un nouveau jeu d applications développées sur une longue période. Cette refonte globale (approche «big bang») peut probablement réussir, mais c est une démarche risquée. En effet, les phases de développement s étalent sur plusieurs années et, en général, lorsque les applications sont enfin prêtes, les besoins réels ne correspondent plus aux spécifications initiales. La deuxième approche repose sur le développement d une première application utilisant de nouveaux concepts. Toutefois, les avantages apportés par cette seule application ne permettent pas de compenser le coût de l implantation de la nouvelle architecture. Enfin, la troisième approche consiste à mettre en oeuvre une architecture prenant en charge les deux environnements coexistants : le système classique comprenant toutes les applications utiles déjà implémentées (applications mainframe, client-serveur, etc.) et le jeu d applications de pointe nouvellement développées. La solution de gestion des accès et des identités AccessMaster convient parfaitement à cette dernière approche car elle fonctionne aussi bien dans un environnement classique que dans un nouveau système. Administration cohérente Le serveur d authentification SAM J2EE est une extension du serveur AccessMaster. Il peut donc utiliser les déclarations d utilisateur du référentiel AccessMaster. Via le module Identity Manager, SAM J2EE peut exploiter les définitions d utilisateur disponibles dans l annuaire LDAP de l entreprise. Dans ce cas, la console d administration SAM J2EE sert uniquement à déclarer et à gérer les assertions SAML. Authentification unique Lorsqu un utilisateur s authentifie via AccessMaster, il peut accéder indifféremment aux applications classiques et SAML J2EE. Pour ces deux environnements, AccessMaster fournit des fonctionnalités SSO et de contrôle des accès. 39 F2 09LS Rev02 15

16 Scénario avec authentification forte des utilisateurs L accès aux applications SAML J2EE peut s appuyer sur les méthodes d authentification d AccessMaster, telles que les jetons Windows Kerberos, les certificats de clé publique ou les mots de passe à usage unique. Dans le scénario suivant (voir figure 4), le module Secure Access Manager - Standard Edition (SAM SE) d AccessMaster procède à l authentification forte des utilisateurs et contrôle l accès à toutes les applications. Figure 4. Authentification forte pour les environnements classique et SAML J2EE Users LDAP repository Validation de l'uitlisateur dans le référentiel des utilisateurs Assertions utilisateur SAML Signature SAML Validation de l'uitlisateur dans le référentiel des utilisateurs Extraction de l'assertion et de la combinaison nom d'utilisateur/mot de passe Authentification Authentification AccessMaster Console d'adminisatration Verification SAML Fourniture des attributs utilisateur SAML Authentification de l'utilisateur Obtention des privilèges noms d'utilisateur/mot de passe/assertions Connexion aux applications Vers les applications J2EE côté serveur Application Client Module de connexion JAAS AccessMaster (Module SDM) Vers les applications classiques AccessMaster côté client Lorsqu il joue le rôle de point d application des politiques sur le poste de travail, le module client SDM d AccessMaster exécute les tâches suivantes : authentification initiale de l utilisateur, connexion aux applications classiques à l aide d un nom d utilisateur et d un mot de passe, connexion aux applications SAML J2EE. 39 F2 09LS Rev02 16

17 AccessMaster côté serveur Lorsqu il agit comme un point de décision des politiques, le serveur AccessMaster valide l authentification initiale de l utilisateur de la manière suivante : il vérifie la validité du nom d utilisateur et du mot de passe, il extrait le nom d utilisateur et le mot de passe dédiés aux applications, ainsi que les assertions SAML. Le serveur traite ensuite les demandes SAML transmises par les applications comme suit : il vérifie les assertions SAML, il valide les utilisateurs, il extrait les privilèges et les droits. Scénario avec administration centralisée et fonction SSO Dans le présent scénario, il n est pas nécessaire que l accès aux applications SAML J2EE soit géré par le module SDM d AccessMaster installé sur le PC. L utilisateur n a besoin que d un seul identifiant pour se connecter à son environnement classique via le module SDM d AccessMaster (point d application des politiques sur le poste de travail) ou à ses applications SAML J2EE via le module client de connexion JAAS (point d application des politiques sur le poste de travail, sur une passerelle ou sur le serveur de l application souhaitée). Figure 5. SSO pour les environnements classiques et SAML J2EE Utilisateurs Répertoires LDAP Console d'administration Validation de l utilisateur dans LDAP Récupération des identifiants et mots de passe secondaires Validation de l'utilisateur dans LDAP Récupération de l'assertion SAML Authentification de l'utilisateur Obtention de l assertion SAML Connexion aux applications Authentification SAM Authentification de l'utilisateur Obtention des privilèges noms d'utilisateur/mot de passe/assertions Connexion aux applications Vers les applications SAML J2EE Client Application JAAS Login Module AccessMaster (SDM) Vers les applicaions classiques 39 F2 09LS Rev02 17

18 Dans cette situation, le module SDM d AccessMaster et le module de connexion JAAS sont tous deux en interaction avec le serveur AccessMaster (point de décision des politiques) pour authentifier l utilisateur. Les tâches d administration telles que la déclaration ou la modification de l identité de l utilisateur sont effectuées dans un seul référentiel, qui peut être un référentiel LDAP. Scénario dans un environnement Web Le module Secure Access Manager Web Edition (SAM Web) d AccessMaster est dédié aux environnements Web et ne nécessite aucun client côté PC. Par exemple, vous pouvez l utiliser afin de gérer l accès des partenaires commerciaux à un extranet. Dans ce scénario, le module SAM Web (point d application des politiques sur une passerelle) authentifie l utilisateur lorsqu il se connecte. Le module SAM Web contrôle ensuite l accès aux applications suivantes : applications Web classiques auxquelles l utilisateur se connecte en entrant son identifiant dans une fenêtre ou un masque de saisie, applications SAML J2EE auxquelles l utilisateur se connecte à l aide d assertions SAML transmises via le module de connexion JAAS. 39 F2 09LS Rev02 18

19 Les architectures SOA pour applications internes nécessitent des services de contrôle des accès et d authentification de base homogènes Avec l annuaire et la gestion des messages, les services de contrôle des accès et d authentification sont au coeur d une architecture SOA. Pour éviter les inconvénients liés à l approche «big bang», une architecture SOA englobant des applications internes doit pouvoir fournir des services aux applications existantes (mainframe, client-serveur ou Web) ainsi qu aux nouvelles applications SAML, telles que J2EE. Les services de sécurité de base doivent donc inclure les fonctionnalités suivantes : Authentification des utilisateurs basée sur une fonction SSO sécurisée et interfaçage entre les applications existantes et les nouvelles applications SAML. Gestion des identités des utilisateurs reposant sur l annuaire LDAP de l entreprise, pour une intégration aisée dans le processus existant de gestion des utilisateurs. Gestion des assertions et des privilèges, de façon à contrôler l accès aux applications J2EE, client-serveur ou mainframe. AccessMaster permet de mettre en œuvre une solution centralisé de gestion des identités et des accès au sein des architectures traditionnelles et des infrastructures SAML. 39 F2 09LS Rev02 19

20 Pour plus d informations, consultez le site info@evidian.com