C. Scénarios de mise en œuvre 27








télécharger 325.98 Kb.
titreC. Scénarios de mise en œuvre 27
page3/10
date de publication30.03.2017
taille325.98 Kb.
typeScénario
ar.21-bal.com > loi > Scénario
1   2   3   4   5   6   7   8   9   10

b.1.2Fédération des identités « Back-Channel »


Afin de considérer la diversité des cas d’usage, sortons à présent du cadre de fédération frontal plus directement lié aux portails et sites Web pour aborder celui esquissé au chapitre précédent de la fédération à destination des échanges de messages/données entre entités fédérées et l’ensemble des « Back-End » impactés.

b.1.2.1Prise en compte de la sécurisation des services Web de type SOAP et les besoins associés


Dans le contexte de la sécurisation des services Web de type SOAP, la nature autonome des services Web met l’accent sur la gestion explicite des cadres de confiance entre les applications et services. Ceci nécessite que des processus ou des systèmes qui étaient centralisés évoluent de facto vers un modèle fédéré.

Nous sommes intimement convaincus qu’un tel modèle fédéré implique qu’une information d’identité et/ou d’autorisation de confiance pour le service accédé soit véhiculée dans chaque message SOAP de façon sécurisée et standard. Cette information d’identité et/ou d’autorisation de confiance est véhiculée sous forme d’un ou plusieurs jetons (d’authentification et/ou d’autorisations) exprimant des revendications.

oasis.png Au-delà de la possibilité de signer/chiffrer tout ou partie d’un message SOAP, le standard OASIS Web Services Security: SOAP Message Security (WS-Security) 1.x permet de véhiculer de façon agnostique un ou plusieurs jeton(s) de sécurité (avec le cas échéant une preuve de possession associée). C’est à notre sens, cette dimension qu’il convient de privilégier pour la sécurisation des services Web de type SOAP.

Le profil Basic Security Profile 1.114 défini par le groupe de travail éponyme au niveau de l’organisation WS-I constitue un socle de référence pour garantir l’interopérabilité entre les différentes implémentations15.

WS-Security fait partie du corpus des standards des services Web avancés, à savoir la pile WS-* (STAR pour Secured, Transacted, Asynchronous & Reliable en anglais) constitué d’un ensemble de recommandations du W3C et de standards de l’OASIS.



Il convient de noter, au passage, que le WS-I vient d’annoncer la fin et la conclusion de ses travaux sur l’interopérabilité des services Web avancés initiés en 2002 avec la publication désormais en version finale des profils élémentaires (Basic Profile) 1.2 et 2.0 ainsi que le profil sécurisé et fiable (Reliable and Secure Profile) 1.0 :

« WAKEFIELD, Mass., USA – November 10, 2010 – After nearly a decade of work and industry cooperation, the Web Services Interoperability Organization (WS-I; http://www.ws-i.org) has successfully concluded its charter to document best practices for Web services interoperability across multiple platforms, operating systems and programming languages.

The release of WS-I member approved final materials for Basic Profile (BP) 1.2 and 2.0, and Reliable Secure Profile (RSP) 1.0 fulfills WS-I’s last milestone as an organization. By publishing the final three profiles, WS-I marks the completion of its work. »

Communiqué de presse WS-I Completes Web Services Interoperability Standards Work16

Comme indiqué, ces profils seront maintenus par l’OASIS dans le cadre de la transition en cours.

Pour revenir aux éléments constituants de la pile WS-*, le standard OASIS Web Services Trust Language (WS-Trust) issu du comité technique OASIS Web Services Secure Exchange (WS-SX)17 définit pour cela un modèle de service de jetons de sécurité (Security Token Service en anglais ou STS en abrégé) auprès duquel de tels jetons (d’authentification, d’autorisations, d’attributs, de pseudonymes) peuvent être obtenus ainsi que le protocole pour converser avec ce service de jetons de sécurité.

Un tel service est à même d’émettre, de valider et d’échanger des jetons de sécurité, d’émettre dans ce dernier cas par exemple un jeton de délégation (élément Act As). Ainsi, par exemple, un demandeur émet une requête et, si les règles exprimées par sa politique et celles du destinataire le permettent, le demandeur reçoit en retour un jeton de sécurité.

Un jeton de sécurité contient un ensemble de revendications dont le type et la sémantique sont fonction du cadre de confiance courant considéré :

Informations d’identité résultant de l’authentification telles que le niveau et le type d’authentification ;

Information du genre « Autorisé pour X », par exemple une liste de services cibles ;

Toute autre information valide dans le contexte du cadre de confiance considéré.

Il est du ressort spécifique du service et/ou de l’organisation destinataire de faire confiance ou non aux revendications ainsi produites ; ces dernières étant des déclarations et/ou affirmations de fait. Autrement dit, la confiance à placer dans l’information ainsi reçue est à la discrétion du service et/ou de l’organisation destinataire.

Le STS émetteur peut signer par un procédé cryptographique (recommandation W3C XML Signature Syntax and Processing (Second Edition)18 (XML-DSig en abrégé) par exemple) les jetons afin de garantir leur intégrité (il n'est plus possible de modifier le contenu du jeton à partir de l’instant de sa signature) et de permettre la vérification de leur origine. Lorsque l’authentification et, le cas échéant, l’autorisation effectuées par le STS sont réussies, un jeton de sécurité est envoyé au demandeur.

La Figure suivante résume les différents rôles d’un STS.



Figure - Service de jetons de sécurité ou STS.

La notion d’échange induit la capacité de transformation de jetons en termes de type de confiance, de format, de sémantique et de (valeurs des) revendications véhiculées par un jeton.

En fonction du rôle particulier du STS considéré et de son emplacement dans la topologie globale, le type et la sémantique des revendications contenues dans le jeton de sécurité varient. Il est aussi possible d’émettre plusieurs jetons pour des services cibles différents.

Un STS peut jouer plusieurs rôles distincts et participer à différents types de topologies de schémas de confiance :

STS fournisseur d’identités demandeur - L’authentification effectuée par le STS vis-à-vis du référentiel d’authentification du fournisseur d’identités produit un jeton de sécurité à destination du service cible afin d’obtenir un accès autorisé.

STS consommateur d’identités - Le STS vérifie les jetons de sécurité présentés par les demandeurs et génère des jetons donnant accès au service cible.

STS courtier en confiance entre deux ou plusieurs parties - Dans ce cas, le cadre de confiance établie entre chaque partie et le négociant crée un cadre de confiance entre les parties elles-mêmes.

La Figure  montre un exemple des flux entre les parties impliquées. Voici une description des étapes numérotées dans la figure :

  1. Le demandeur présente les informations de sécurité ou crédentités nécessaires au STS fournisseur d’identités demandeur A.

Le STS fournisseur d’identités demandeur A valide l’identité et renvoie un jeton de sécurité au demandeur.

Le demandeur présente ce jeton au STS consommateur d’identités cible B.

Le STS consommateur d’identités cible B vérifie la validité et l'origine du jeton, et renvoie au demandeur un jeton d'accès pour le service cible C. Il n’a pas besoin de reconnaître directement le demandeur ou son identité. Il fait confiance au STS fournisseur d’identités demandeur A et accepte par conséquent son jeton.

Le demandeur présente le jeton d’accès au service cible C (dont la sécurité est gérée par le STS consommateur d’identités B) et accède à cette ressource.



Figure  – Authentification fédérée.

L’interaction entre plusieurs STS et les rôles associés varient en fonction de la topologie et du modèle. La Figure  montre quelques variations possibles :

  1. Un système demandeur s’exécute dans le contexte de sécurité d’un compte utilisateur et doit montrer ses informations de sécurité ou crédentités.

Le système envoie une requête au STS A. Il présente les crédentités du compte utilisateur sous lequel il s’exécute et spécifie le service demandé, X.

Après l’authentification réussie de l’utilisateur et l’autorisation pour le service X, le STS émet et renvoie deux jetons :

  1. Un jeton d’authentification (Au) qui confirme l’authentification réussie de l’utilisateur (et donc du système demandeur). Il pourra être utilisé pour obtenir ultérieurement des autorisations complémentaires sans nécessiter une nouvelle authentification complète de l’utilisateur auprès du STS A.

  2. Un jeton d’autorisation (AzX) pour l’utilisateur (en l’occurrence le système demandeur) du service X. Il contient les identificateurs appropriés qui définissent le contexte de la relation entre l'utilisateur (le système) et le service X.

Le système contacte pour la première fois le service X et présente le jeton d'autorisation AzX émis par le STS A.

Le STS X vérifie la validité du jeton AzX et émet un nouveau jeton X, spécifique au STS X, qui contient des revendications appropriées pour accéder au service X. Par exemple, le STS X peut traduire les identificateurs contenus dans le jeton AzX en informations plus spécifiques liées à un rôle dans le contexte du service X.

Les appels suivants (6, 7, 8, etc.) en provenance du système présentent le jeton X dont la validité peut être vérifiée très rapidement, bien plus rapidement que le contrôle du jeton AzX et la traduction des revendications. Le transfert via le jeton X des identificateurs appropriés spécifiques au service X, permet aussi de prendre des décisions d’autorisation au sein du service.



Figure  – Rôles des STS et échange de jeton.

Après avoir interagi avec le service X, le système demandeur a besoin d’accéder à un autre service Y. La Figure  illustre cette situation où de petites différences apparaissent par rapport à l’exemple précédent.

En supposant que le jeton d’authentification (Au) précédemment émis par le STS A soit toujours valide et qu’il ait été stocké de façon fiable et sécurisée par un intermédiaire ou par le système demandeur lui-même, l’obtention d’un jeton pour accéder à un autre service Y peut être très simple et n’exige pas la présentation des informations de sécurité complètes de l’utilisateur. C’est le principe même d’une ouverture de session unique pour accéder à plusieurs services. Les flux échangés sont les suivants (Figure ) :

  1. Le contexte applicatif du système demande l’accès à un autre service Y.

Le système émet une requête à destination du STS A, présentant le jeton d’authentification Au précédemment émis par ce dernier, tout en précisant le service cible Y.

Après les vérifications réussies de la validité du jeton d’authentification Au et de l’autorisation de l’utilisateur (le système) pour le service X, le STS A émet et renvoie deux jetons:

  1. Un jeton d'authentification Au rafraîchi ou renouvelé (optionnel), avec une durée de validité éventuellement modifiée afin de permettre le prolongement de l'authentification d'origine. (Cela dépend de la définition des stratégies et de l’équilibre souhaité entre sécurité et aspect pratique.)

  2. Un jeton d’autorisation AzY qui contient les identificateurs appropriés, propres au service Y et définissant le contexte de la relation entre l’utilisateur et le service Y.

Le système demandeur contacte pour la première fois le service Y et présente le jeton d'autorisation AzY émis par le STS A.

Le STS Y vérifie la validité du jeton AzY et émet un nouveau jeton Y, propre au STS Y, contenant les revendications appropriées pour accéder au service Y.

Les appels suivants (6, 7, 8, etc.) en provenance du système présentent le jeton Y dont la validité peut être vérifiée très rapidement, bien plus rapidement que le contrôle du jeton AzY et la traduction des attributs. Le transfert via le jeton Y des identificateurs appropriés spécifiques au service Y, permet aussi de prendre des décisions d’autorisation au sein du service.



Figure  – Rôles des STS et échange de jeton, nouveau service.

L'idée de transformation de jetons et de revendications introduite par ce standard constitue très certainement l'avancée technique la plus significative dans l'informatique distribuée depuis au moins les dix dernières années.

L’impact et les réponses qui sont ainsi apportées n’ont d’ailleurs pas été complètement anticipés au début des travaux dans ce domaine.

Compte tenu de la diversité des scénarios (et des acteurs potentiels) à prendre en considération, il apparaît nécessaire de supporter aussi bien des schémas de confiance directe, indirecte, par courtage ainsi que la délégation. Ceci exige un modèle de fédération qui ne peut être autrement que complètement négocié dynamiquement via un pilotage par les métadonnées.

En complément du standard OASIS WS-Trust, le standard OASIS WS-Federation propose notamment une extension des métadonnées de SAML 2.0 (décrites dans la spécification Metadata for the OASIS Security Assertion Markup Language (SAML) V2.019) adaptée au contexte des services Web.

La spécification WS-Federation permet, par ailleurs, le développement et le déploiement de services de fédération avancés (services d’authentification, d’autorisations, d’attributs, de pseudonymes, etc.) comme une simple variation du modèle de transformation de revendications d’un service de jetons WS-Trust.

Dès lors, pour une transaction donnée, au travers de la chorégraphie d’invocation en cours, le cadre de confiance est dynamique et fondé sur la prise en charge de politiques de confiance (métadonnées de fédération) établies et exposées par les différentes parties impliquées et sur la transmission (et l’échange) de jetons de sécurité (d’authentification, d’autorisations, d’attributs, de pseudonymes) :

  • Les (intermédiaires et les) ressources fédérées comprennent des jetons (d’authentification, d’autorisations, d’attributs, de pseudonymes) spécifiques (en termes de format et de sémantique pour les revendications ainsi véhiculées),

  • Les STS émettent des jetons ou bien traduisent les jetons émis par d’autres services de jetons, tiers de confiance en d’autres jetons (depuis ce que le demandeur initial possède vers ce que le service Web accédé en final exige/a besoin pour prendre (ou en déduire) ses décisions d’autorisation).

Les jetons de sécurité résultants de cette transaction sont partagés, soit directement soit indirectement, entre les parties impliquées dans le traitement du message. En conséquence, ces jetons de sécurité sont émis par un STS, racine approuvée (de confiance) ou par un STS, nœud de la chaîne de confiance et/ou de délégation.

Les standards OASIS WS-Security, WS-Trust et WS-Federation rendent possible pour la fédération l’émergence d’un modèle complètement distribué et dynamique piloté par l'exposition, l'échange de politiques de fédération (métadonnées de fédération) avec, à la clé, une très large variété de schéma de confiance applicables.

La gestion, la découverte et l'accès à de tels services Web sécurisés s’en trouvent notablement simplifiés lorsque ces derniers reposent tous sur un modèle de traitement commun et parlent le même protocole.

b.1.2.2Considérations additionnelles vis-à-vis des standards OASIS WS-Federation 1.2 et SAML 2.0


La spécification WS-Federation doit être considérée comme une spécification évolutive des spécifications SAML, et non pas comme une alternative.

Le livre blanc Understanding WS-Federation20, publié conjointement par IBM et Microsoft, tous deux membres du comité OASIS WSFED donne une appréciation du périmètre fonctionnel de la spécification. Cette spécification permet typiquement de constituer une identité composite sous forme de multiples jetons obtenus depuis différents fournisseurs (d’identités et/ou d’attributs) comme évoqué à la fin du premier chapitre vis-à-vis du méta-système d’identités.

Comme souligné en introduction de la section précédente, le travail de la communauté SAML a constitué une étape importante pour tous ceux impliqués dans (la « portabilité » de) l'identité numérique. Rien dans la spécification WS-Federation n’invalide ce travail.

Pour autant, une proposition technologique n’apporte pas forcément de façon immuable une réponse pertinente dans le temps. Si l’on se souvient un instant du moment où SAML a été introduit et positionné comme une alternative à l’« authentification » LDAP, aucun des contributeurs LDAP de l’époque n’a considéré la proposition faite comme la réponse ultime au domaine de l’identité et des attributs. Des personnes comme Mark Wahl, Bob Morgan ou encore Keith Hazelton, profondément impliquées dans Kerberos et LDAP, et vues par beaucoup comme des « gourous » LDAP, se sont alors au contraire montrées prêtes à embrasser de nouvelles technologies comme SAML en tant que réponse à de nouveaux cas d’usage.

Tout comme SAML a introduit une nouvelle fondation en son temps, WS-Federation est destinée à résoudre un certain nombre de points que nombreux souhaitent voir mieux définies de façon à faciliter l'interopérabilité au niveau de la fédération comme, par exemple, une séparation claire entre les mécanismes de confiance, les formats de jetons de sécurité, et les protocoles pour obtenir ces jetons.

La spécification WS-Federation vient ainsi compléter des standards OASIS comme, en particulier WS-Security et WS-Trust. WS-Security permet de véhiculer de façon agnostique un ou plusieurs jeton(s) de sécurité (avec le cas échéant une preuve de possession associée). WS-Trust définit un modèle de service de jetons de sécurité ou STS.

Ces protocoles n’avaient même pas été inventés lors des évolutions de SAML.

D’ailleurs à ce titre, comment attendre de SAML une adéquation optimale avec ces considérations qui au final émergent depuis peu ? Ceci ne déprécie en aucune façon les succès passés de SAML.

Par ailleurs, comme mentionné précédemment, une section de la spécification WS-Federation définit les règles de codage qui permettent à de nombreuses fonctionnalités du protocole WS-Trust et des extensions WS-Federation d’être utilisées par les navigateurs et les portails et sites Web via des mécanismes standard HTTP. Cette section, initialement connue sous le nom de profil passif de WS-Federation (WS-Fed Passive) duplique la fonctionnalité définie dans la spécification SAML 2.0 abordée précédemment.

Cette superposition trouve sa fondation et justification dans les objectifs même de WS-Federation afin de fournir un protocole commun pour effectuer des opérations de fédération d’identités à destination des services Web mais également des portails et sites Web.

Un même protocole commun assure des économies par rapport au développement, aux tests, au déploiement et à la maintenance des services de fédération, et ce aussi bien pour les fournisseurs de technologies que pour les clients, consommateurs de ces technologies.

L’échec dans l'intégration des scénarios à bases de clients passifs (navigateurs) et de clients actifs multiplie non seulement les coûts mais induit également pour les clients aujourd’hui ou dans un futur proche des problématiques de migration douloureuses.

Le standard WS-Federation se distingue ainsi du standard SAML en proposant à l’industrie des bénéfices qui ne sont disponibles dans aucun autre standard existant.

La fédération des identités « Back-Channel » est tout aussi fondamentale en termes d’interopérabilité et impacte en particulier les services Web et leur sécurité en termes d’authentification et de contrôle d’accès.

b.1.2.3Prise en compte du style d’architecture REST


Wikipedia21 définit REST et les services Web RESTful comme suit:

« Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. The term Representational State Transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. Fielding is one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification versions 1.0 and 1.1.

Conforming to the REST constraints is referred to as being ‘RESTful’.



A RESTful web service (also called a RESTful web API) is a simple web service implemented using HTTP and the principles of REST. It is a collection of resources, with three defined aspects:

  • the base URI for the web service, such as http://example.com/resources/

  • the MIME type of the data supported by the web service. This is often JSON, XML or YAML but can be any other valid MIME type.

  • the set of operations supported by the web service using HTTP methods (e.g., POST, GET, PUT or DELETE).

»



De façon à pouvoir étendre le méta-système d’identité aux consommateurs d’identités conformes au style d’architecture REST ainsi décrit, Microsoft, Google, et Yahoo ont investi conjointement sur la définition d’un profil du standard ouvert OAuth (Open Authorization) issu d’une initiative communautaire pour les autorisations démarrée en 2006.

Pour mémoire, OAuth est destiné à l’origine au partage de ressources proposées par un site depuis un autre site sans avoir à gérer des crédentités (credentials en anglais). OAuth permet aux utilisateurs de fournir des jetons en lieu et place de leur crédentités pour accéder aux ressources souhaitées. Chaque jeton confère ainsi un accès pour un site donné vis-à-vis de ressources spécifiques et sur une période donnée. OAuth constitue un service complémentaire mais distinct d’OpenID (Cf. section éponyme § b.2.2). Le protocole OAuth 1.0 correspond à la RFC 5849 The OAuth 1.0 Protocol22. Le guide The Authoritative Guide to OAuth 1.023 présente une vue d’ensemble sur ce protocole.



Le profil résultant WRAP (Web Resource Authorization Protocol)24, également appelé OAuth WRAP, propose, tout en offrant une similitude en termes de pattern à OAuth 1.0A, un nombre important de capacités qui n’étaient pas présentes précédemment dans OAuth. La spécification résultante est désormais en cours de standardisation au sein de l’IETF (IETF OAuth WG25) et sert de fondation à la définition d’OAuth 2.026. L’article Introducing OAuth 2.027 propose une vue d’ensemble d’OAuth 2.0.

La définition de WRAP s’est accompagnée de celle d’un nouveau format de jeton d’accès, en l’occurrence le format SWT (Simple Web Token) qui peut être utilisé au sein de WRAP. L’obtention d’un jeton SWT peut se faire sur la base de la fourniture d’un jeton SAML préalablement obtenu dans le cadre, par exemple, d’une fédération d’identité « Front-Channel ».

La Figure illustre les interactions entre les différentes parties impliquées.

  1. Un secret périodiquement rafraîchi est échangé entre le serveur d’autorisation et la ressource protégée.

  1. Des règles de contrôles d’accès sont définies pour le client.

  2. Le client demande un jeton d’accès (revendications) pour l’accès à la ressource protégée.

  3. Le serveur d’autorisation mappe les revendications reçues en entrée vers des revendications en sortie sur la base de l’exécution des règles de contrôle d’accès.

  4. Le serveur d’autorisation retourne le jeton d’accès avec les revendications en sortie issues de l’étape précédente.

  5. Le client envoie son message avec le jeton de contrôle d’accès.



Figure – Principes de WRAP

Ce format est également en cours de standardisation au sein du groupe à l’IETF.

Le service ACS (Access Control Services) de la plateforme Windows Azure AppFabric supporte le protocole WRAP et peut émettre des jetons SWT (Cf. section § c.1.3 Microsoft Windows Azure AppFabric platform Access Control Services (ACS) 2.0).

Par ailleurs, en reconnaissance d’un intérêt substantiel pour représenter un ensemble de revendications dans des jetons JSON (JavaScript Object Notation), une proposition de spécification d’un jeton JWT (JSON Web Token)28 vient d’être publiée dans la liste OAuth pour y être discutée.

b.1.3Sélection du fournisseur d’identité


Dans l’usage fait des identités et le contrôle associé, une composante essentielle du méta-système, tel qu’abordé à la section § a Notions de méta-système et de mash-up d’identités, est la notion de cartes d’information et sélecteur d’identités.

Wikipedia définit les cartes d’informations (Information Card en anglais) ou i-cards29 comme :

« A rectangular icon displayed in the user interface of an identity agent that represents a digital identity--a set of claims about a digital subject. »

En d’autres termes, une carte d’informations constitue un artefact permettant d’obtenir auprès d’un fournisseur d’identités, après identification/authentification, une preuve d’identité sous forme de revendications (claims en anglais).

Le sélecteur d’identités contient les cartes d’informations relatives aux différentes identités de l’utilisateur.

Une telle approche permet non seulement aux personnes d’être en contrôle, au travers de la notion de « sélecteur d’identités », de leurs identités (manipulées sous forme de cartes d’informations) et de l’usage qui en est fait.

Le sélecteur d’identités permet, en effet, à l’utilisateur, dans le cadre d’une fédération centrée sur lui-même :

  • De s’assurer de l’identité du fournisseur de services accédé,

  • De sélectionner dans le contexte courant de la transaction son identité (via la sélection d’une carte d’informations), et par la même le fournisseur d’identités de son choix,

  • De la communiquer, après son consentement explicite, au fournisseur de services accédé ou consommateur d’identités.

Avec la disponibilité de cartes d’information et d’un sélecteur d’identité, le méta-système d’identités :

  • Repositionne les identités numériques d’un sujet sous son contrôle direct et explicite,

  • Offre une expérience utilisateur prévisible, cohérente et reconductible quels que soient les fournisseurs d’identités et de services impliqués dans le contexte de la transaction courante,

  • Élimine les coûteuses intégrations pas toujours des plus ergonomiques ni des plus cohérentes tant au niveau fournisseur d’identités que fournisseur de services.

Le standard OASIS Identity Metasystem Interoperability Version 1.030 issu du comité technique OASIS Identity Metasystem Interoperability (IMI)31 définit les cartes d’information et leur modalité d’usage au sein du méta-système d’identité. Ce standard est issu du profil d'interopérabilité pour le sélecteur d’identités (Identity Selector Interoperability Profile (ISIP) 1.x32 publié à l’origine par Microsoft et couvert par l’Open Specification Promise33 (OSP en abrégé) de Microsoft.

L’ensemble des problématiques adressées par le sélecteur d’identités (au sein d’un écosystème de confiance), en permettant aux utilisateurs de gérer leurs propres identités (quelles soient omni ou non directionnelles), et les problèmes que rencontre la fédération des identités sont dans l’ensemble orthogonaux. 

Le méta-système d’identités n’est donc pas positionné contre tel ou tel protocole de fédération, mais au contraire supprime les frictions qui peuvent exister et résout des problématiques connexes et complémentaires. Il s’agit donc d’une approche orthogonale. Il convient de noter à ce titre le profil SAML 2.0 suivant en cours d’élaboration : SAML V2.0 Information Card Token Profile34.

Le livre blanc The Information Card Ecosystem: The Fundamental Leap from Cookies & Passwords to Cards & Selectors propose une vue d’ensemble sur les cartes d’information et les sélecteurs d’identité.



La constitution de l’Information Card Foundation35 (ICF en abrégé) en juin 2008 (Cf. communiqué de presse36 associé) permet de :

  • Fédérer la collaboration de l'industrie qui a émergé autour du méta-système d’identités et des cartes d'information ;

  • Et promouvoir l’usage des cartes d’informations quels que soient les environnements, les socles technologiques et les langages considérés pour les sélecteurs, les fournisseurs et consommateurs d’identité.

Parmi son comité directeur, on trouve Google, Microsoft, Novell, Oracle et PayPal.

De nombreuses solutions logicielles développées par des éditeurs, des communautés et des contributions individuelles à destination de l’ensemble des principales plateformes de développement sont ainsi proposées. Le sélecteur d’identité proposé par Microsoft s’appelle Windows CardSpace.



L’interopérabilité de ces solutions a pu être testée via les divers ateliers d’interopérabilité organisés par l’OSIS (Open-Source Identity System)37.
1   2   3   4   5   6   7   8   9   10

similaire:

C. Scénarios de mise en œuvre 27 iconC. Scénarios de mise en œuvre 27

C. Scénarios de mise en œuvre 27 iconScénarios relatifs au service Web de mise à jour des appareils 13

C. Scénarios de mise en œuvre 27 iconCalendrier de mise en œuvre 14

C. Scénarios de mise en œuvre 27 iconScénario pédagogique. Pour de Lièvre, Quintin & Depover (2002), IL...
«activités», «tâches», «scénarios», …, se posent des questions de «granularité», de mise en scène et d’architecture

C. Scénarios de mise en œuvre 27 icon"Mise en œuvre de Cisco Unified Communication Manager"

C. Scénarios de mise en œuvre 27 iconPrincipes et conditions de mise en œuvre du protocole enum en France

C. Scénarios de mise en œuvre 27 iconThierry brugvin lipha, Paris Est la difficile mise en œuvre

C. Scénarios de mise en œuvre 27 iconLa mise en œuvre de la prime d’activité : un enjeu pour la Branche Famille

C. Scénarios de mise en œuvre 27 iconLa mise en œuvre d’une «mixité sociale» dans le parc hlm de la ville de Martigues

C. Scénarios de mise en œuvre 27 iconMéthodologie de mise en œuvre et problèmes posés par la première application de la réforme 2005








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com