C. Scénarios de mise en œuvre 27
télécharger 325.98 Kb.
|
b.Protocoles et formats de jetons de sécuritéb.1Identités numériques d’entrepriseWikipedia3 définit la fédération des identités comme suit: « Federated identity, or the ‘federation’ of identity, describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains. The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration. » Cette première section s’intéresse aux standards de fédération qui permettent de matérialiser au travers de leurs diverses implémentations une identité « portable » entre domaines de sécurité. Les collaborations de type B2B (Business to Business en anglais) ou G2G (Government to Government en anglais) entrent typiquement dans ce cadre. b.1.1Fédération des identités « Front-Channel »La fédération d’identité est bien souvent perçue en premier lieu comme le moyen de disposer d’une authentification Web unique (Web Single Sign-on en anglais ou Web SSO en abrégé) fédérée à destination des portails et sites Web de façon à établir une collaboration fédérée entre organisations et domaines de sécurité afférents, i) l’authentification étant réalisée au sein du domaine de sécurité où l’identité est déclarée et ii) la ressource accédée se situant dans un autre domaine de sécurité qui a délégué l’authentification. Par rapport à des ressources de type portails et sites Web, on parle ici plus spécifiquement de fédération des identités « Front-Channel » qui est l’objet de cette section. La section suivante s’intéresse à la fédération des identités « Back-Channel » au-delà des portails et sites Web, à savoir la fédération à destination des échanges de messages/données via services Web entre entités fédérées et l’ensemble des « Back-End » impactés. Il existe aujourd’hui différentes approches technologiques de la fédération des identités « Front-Channel », voire potentiellement sous forme de différentes versions pour une même proposition protocolaire. Ceci traduit le fait qu’au demeurant aucune spécification n’est universellement adoptée à ce jour. Essayons d’y voir un peu plus clair.    Le projet Liberty Alliance4 (LA en abrégé), dont l’ensemble du travail et des livrables a été transmis aujourd’hui à l’Initiative Kantara5, au même titre que le projet Shibboleth6 à l’initiative de l’Internet2/MACE7 (Middleware Architecture Committee for Education) et d’une façon plus générale la communauté SAML ont profondément contribué à l’analyse et la compréhension de toute une série de cas d'utilisation et d’exigences associées, et les protocoles, formats et concepts proposés par ces groupes de travail ont été une étape importante pour tous ceux impliqués dans (la « portabilité » de) l'identité numérique.  On peut ainsi citer les versions 1.0, 1.1 et 2.0 du standard SAML issus du comité OASIS Security Services (SAML en abrégé) TC8 ainsi que les spécifications ID-FF (Identity Federation Framework en anglais) 1.x du projet Liberty Alliance et Shibboleth 1.x du projet éponyme, qui constituent des extensions des versions 1.x du standard SAML.Ces groupes de travail et projets doivent être remerciés pour leur contribution qui a fait indéniablement avancer la réflexion sur les différentes dimensions que recouvrent la définition précédente, notamment sur le plan des conditions relatives à la collaboration entre différentes entités, l’établissement d’un cadre de confiance intégrant les engagements et zones de responsabilité (juridique) de chacun, etc. Sur le plan technique, si les spécifications SAML 1.x, ID-FF 1.x, Shibboleth 1.x et SAML 2.0 reposent sur des principes similaires, ces spécifications n’en ont pas pour autant systématiquement les mêmes fonctionnalités, les mêmes périmètres en termes de profils et de liaisons (binding en anglais), loin s’en faut. Par voie de conséquence, des implémentations potentielles de ces spécifications ne sont pas forcément interopérables entre elles. Principes et fonctionnement similaires ne sont pas synonymes d’interopérabilité. L’initiative Kantara a repris l’activité de tests d’interopérabilité développée à l’origine par le projet Liberty Alliance pour les protocoles ID-FF et SAML. Nous souhaitons souligner, au passage, que le projet Shibboleth désigne à la fois une spécification et une implémentation, à savoir un système distribué sous licence de logiciel libre. En tant que spécification, Shibboleth 1.x constitue à l’origine une extension du standard SAML 1.x ; ce dernier définissant un protocole pour échanger des informations liées à la sécurité de façon à traiter la problématique d'authentification unique Web. L’implémentation Shibboleth 2.x repose sur les spécifications SAML 2.0. Notons au passage que Shibboleth est aujourd’hui largement utilisé au sein des Universités en France dans le cadre de la fédération Education-Recherche9, un service rendu par le GIP RENATER. Dans la pratique, la version 1.1 du standard OASIS SAML et les différentes versions de la spécification ID-FF, ont été prises en compte au même titre que d’autres contributions comme les spécifications Shibboleth 1.x, pour donner lieu à la version 2.0 du standard OASIS SAML. Finalisé en 2005, le standard SAML 2.0 est désormais adopté aujourd’hui en lieu et place des propositions initiales du projet Liberty Alliance. Il en est de même pour le projet Shibboleth comme souligné ci-avant. Parallèlement aux évolutions protocolaires précédentes, le protocole WS-Federation Passive Requestor Profile (WS-Fed PRP en abrégé) a été développé à l’origine par IBM, BEA Systems, Microsoft, VeriSign, et RSA Security en tant que branche à destination des navigateurs dans le cadre d’une initiative plus vaste à destination des services Web (Cf. section § b.1.2.1 Prise en compte de la sécurisation des services Web de type SOAP et les besoins associés). Cette spécification a démontré en effet son large potentiel d’interopérabilité depuis 2004 avec l’atelier WS-Fed Protocol workshop (Microsoft, IBM, RSA, Oracle (Oblix), BMC (OpenNetwork), CA (Netegrity), Ping Identity). Ce protocole souvent appelé WS-Fed Passive est aujourd’hui repris, comme dérivé simplifié (profil à destination des navigateurs), à la section § 13 Web (Passive) Requestors du standard OASIS Web Services Federation Language (WS-Federation) Version 1.210 issu du comité technique OASIS Web Services Federation (WSFED)11. Il connait également aujourd’hui une audience certaine. Pour autant, l’interopérabilité entre applications dans des environnements technologiques hétérogènes est une dimension essentielle de la collaboration entre organisations. Dans ce contexte et compte tenu des éléments précédents, le support simultané des protocoles SAML 2.0 et WS-Fed Passive et la disponibilité d’une passerelle entre les deux s’impose de façon à pouvoir réunir au sein d’un même scénario des organisations ayant effectué des choix protocolaires différents. Ainsi, dans le contexte d’une transaction donnée, et en fonction des acteurs en présence, une partie du dialogue peut s’effectuer selon l’un des protocoles supportés, et l’autre partie selon un autre protocole. Ainsi, plus de 76% des plateformes d’identité proposent aujourd’hui une implémentation des standards SAML 2.0 et de WS-Fed Passive pour le support des identités fédérées « Front-Channel ». C’est le cas notamment avec Microsoft Active Directory Federation Services (AD FS) 2.0 (Cf. section éponyme § c.1.2).   Il convient de noter au passage que l’authentification réalisée au niveau du fournisseur d’identité peut être déléguée à son tour en s’appuyant sur un autre protocole d’authentification Web unique, cette fois non fédéré, comme le protocole CAS (Central Authentication Service)12 développé à l’origine par l’université de Yale et dont les évolutions sont gérées aujourd’hui dans le cadre du projet Jasig13. On retrouve ce type d’approche typiquement dans le contexte du projet Shibboleth (en tant que système distribué sous licence de logiciel libre), mais pas uniquement. Ceci étant, disposer d’une identité fédérée pour des scénarios de Web SSO fédéré entre portails et sites Web constitue certes un premier pas important mais à l’évidence aujourd’hui insuffisant. En effet, la notion de services accessibles dans un cadre de fédération ne se limite à l’accès des pages Web (statiques ou dynamiques) situées sur des sites Web fédérés. Il y a au-delà du site lui-même, pour le service invoqué, des échanges de messages avec des services (Web) de l’entité accédée (ou d’autres entités potentiellement situées au-delà du domaine de sécurité courant). Ne serait-ce que vu d’un client passif (navigateur), de nombreuses questions restent sans réponse ou une réponse très limitée : sous quelle identité ces pages invoquent des services Web situés dans d’autres domaines de sécurité ? Quelle information d’identité véhiculent-ils ? Est-elle intelligible et digne de confiance pour le service invoqué ? Etc. On sort ici du cadre d’application stricte des spécifications mentionnées précédemment et, en particulier, des spécifications SAML 2.0 et/ou WS-Federation Passive précédentes. Le recours ici à une autre spécification, comme par exemple la spécification Liberty Alliance ID-SWF, induit un degré de complexité supplémentaire à ne pas négliger. Cette dernière repose en effet sur des fondements différents, introduit d’autres protocoles et n’adresse malheureusement la problématique posée que de façon très parcellaire. En effet, que dire alors de services invocables directement sous forme de services Web depuis un client actif (client « intelligent » ou smart client en anglais) ? Par ailleurs, la notion même de cercle de confiance statique introduit en son temps par ID-FF ne répond que très partiellement à la réalité des scénarios de mise en œuvre. Pour embrasser la diversité des scénarios (et des acteurs potentiels), il apparaît nécessaire de supporter aussi bien des schémas de confiance directe, indirecte, par courtage (brokering en anglais) ainsi que la délégation. Dès lors, une notion de cercle de confiance statique vole en éclat au profit d’un modèle de fédération complètement dynamique basé sur les cadres de confiance établis unitairement entre les acteurs et sur l'exposition, l'échange de métadonnées (politiques) (et potentiellement différents types de jetons de sécurité, etc.). La diversité des cas d’usage (scénarios) de la fédération des identités (« Front Channel » vs. « Back Channel ») impose, en conséquence, de disposer d’une approche technologique ou d'un « Framework » plus vaste et offrant une flexibilité accrue :
Il s’avère donc nécessaire d’aller au-delà pour embrasser la diversité des situations à prendre en considération. |
