FR3118382A1 - Procédé et dispositif permettant un accès autorisé et authentifié pour des identités fédérées - Google Patents

Procédé et dispositif permettant un accès autorisé et authentifié pour des identités fédérées Download PDF

Info

Publication number
FR3118382A1
FR3118382A1 FR2013775A FR2013775A FR3118382A1 FR 3118382 A1 FR3118382 A1 FR 3118382A1 FR 2013775 A FR2013775 A FR 2013775A FR 2013775 A FR2013775 A FR 2013775A FR 3118382 A1 FR3118382 A1 FR 3118382A1
Authority
FR
France
Prior art keywords
user
abe
identity
access
protected
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR2013775A
Other languages
English (en)
Other versions
FR3118382B1 (fr
Inventor
Nouha Oualha
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique CEA
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commissariat a lEnergie Atomique CEA, Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique CEA
Priority to FR2013775A priority Critical patent/FR3118382B1/fr
Publication of FR3118382A1 publication Critical patent/FR3118382A1/fr
Application granted granted Critical
Publication of FR3118382B1 publication Critical patent/FR3118382B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H04L9/3073—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves involving pairings, e.g. identity based encryption [IBE], bilinear mappings or bilinear pairings, e.g. Weil or Tate pairing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Algebra (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

L’invention porte sur un procédé opérant dans un environnement ayant des identités fédérées, permettant à un fournisseur de services de délivrer à un utilisateur un accès autorisé et authentifié à des ressources protégées et partagées dans une fédération, en utilisant des mécanismes de chiffrement basés sur les attributs ou ABE « Attribute-Based Encryption ». Figure pour l’abrégé : Fig.2

Description

Procédé et dispositif permettant un accès autorisé et authentifié pour des identités fédérées
Domaine de l’invention
L’invention se situe dans le domaine des communications réseau, et en particulier le domaine de la sécurité dans les réseaux informatiques de télécommunication à connectivité intermittente, indisponible, ou coûteuse. Des exemples de ces réseaux sont les réseaux à faibles ressources émergents avec des communications machine-à-machine, l’Internet des Objets (IoT), les réseaux de capteurs sans-fil, les réseaux véhiculaires, tout réseau où les dispositifs contraints qui fournissent des ressources ou des services protégés sont déployés et laissés sans surveillance dans des emplacements difficiles d’accès.
L’invention s’applique aussi à des réseaux d’urgence pour les systèmes de protection du public et de secours en cas de catastrophe (en anglais « Public Protection and Disaster Relief » ou PPDR) quand l'infrastructure des réseaux et des communications n’est plus fiable à cause d’un désastre.
Etat de la Technique
Assurer l’authentification et l'autorisation est primordial pour sécuriser l’accès à des ressources protégées, notamment dans le contexte d’une fédération. Les solutions et les standards d’authentification et d’autorisation d’identités fédérées (« federated identity » en anglais) existants permettent de déléguer l’authentification et l’autorisation d’un utilisateur qui souhaite accéder à des ressources, à un fournisseur d’identités qui va aussi gérer les identités de l’utilisateur. Le fournisseur de service doit alors connaître tous les fournisseurs d’identités des utilisateurs.
Dans un groupe d’entreprises, il est intéressant de donner le contact d’un seul fournisseur d’identités à des fournisseurs de service tiers.
Il existe plusieurs solutions et standards qui permettent l’authentification et l’autorisation pour des identités fédérées.
Une solution qui repose sur le standard OpenID Connect 1.0 contrôlé par la fondation OpenID, est une simple couche d'identité qui vient s'ajouter au protocole OAuth 2.0 (D. Hardt, The OAuth 2.0 Authorization Framework, IETF RFC 6749, October 2012). Il permet à des fournisseurs de service de vérifier l'identité de l'utilisateur final sur la base de l'authentification effectuée par un serveur d'autorisation, i.e. le fournisseur d’identité, ainsi que d'obtenir des informations de profil de base sur l'utilisateur final de manière interopérable et semblable à l’architecture REST « Representational State Transfer ».
Dans OpenID connect 1.0, l'authentification peut suivre l'une des trois voies suivantes :
- Flux de codes d'autorisation : Le flux OAuth 2.0 dans lequel un code d'autorisation est renvoyé à partir de l'extrémité d'autorisation et tous les jetons sont renvoyés à partir de l'extrémité de jeton.
- Flux hybride : Le flux OAuth 2.0 dans lequel un code d'autorisation est renvoyé à partir de l'extrémité d'autorisation, certains jetons sont renvoyés à partir de l'extrémité d'autorisation, et d'autres sont renvoyés à partir de l'extrémité de jeton.
- Flux implicite : Le flux OAuth 2.0 dans lequel tous les jetons sont renvoyés à partir du point final d'autorisation et ni le point final de jeton ni un code d'autorisation ne sont utilisés.
La illustre de manière simplifiée les flux de messages existants pour le protocole d’authentification OpenID Connect 1.0 avec des identités fédérées en mode flux implicite. Un utilisateur (102) émet (1) une requête d’inscription d’identité vers un fournisseur d’identité (104) et (2) une requête d’accès à des ressources vers un fournisseur de service (106). Le fournisseur de service redirige (3) vers le fournisseur d’identité (104) une requête d’authentification de l’utilisateur. Si le fournisseur d’identité et l’utilisateur s’authentifient (4), le fournisseur d’identité renvoie (5) une réponse d’authentification redirigée vers le fournisseur de service, avec un jeton d’accès, ce qui permet à ce dernier (106) de répondre positivement (7) à la demande d’accès aux ressources de l’utilisateur 102). Une option (6) permet au fournisseur de services (106) d'échanger un jeton par un autre jeton, par exemple par un jeton RPT.
Une autre solution repose sur le standard SAML 2.0 « Security Assertion Markup Language » qui est basé sur le langage XML et développé par le consortium OASIS « Organization for the Advancement of Structured Information Standards ». Le standard SAML définit un protocole pour échanger des informations liées à la sécurité et propose une authentification unique (en anglais «single sign -on» ou SSO) sur le web. De cette manière, un utilisateur peut naviguer sur plusieurs sites différents en ne s'authentifiant qu'une seule fois, sans pour autant que ces sites aient accès à des informations trop confidentielles.
Cependant, toutes ces solutions nécessitent que le fournisseur d’identité gère l’utilisateur authentifié.
Dans certains systèmes où le fournisseur d’identité ne gère pas l’identité de l’utilisateur, il peut jouer le rôle d’une passerelle entre le fournisseur de service et un autre fournisseur d’identité qui gère les identités de l’utilisateur. Ce service de passerelle appelé « courtier en identité » (ou « identity brokering » en anglais), met en relation plusieurs fournisseurs de services avec différents fournisseurs d'identités. L’outil « Keycloak » propose un tel service.
Il faut aussi noter que souvent avec les protocoles d’authentification basés sur les identités fédérées, le responsable de l'application de la politique d’accès utilise le jeton d’accès pour décider d’autoriser ou non l’accès à la ressource demandée. En effet, lui ou le demandeur d’accès peuvent échanger auprès du fournisseur d’identité un jeton d’accès simple, obtenu après authentification avec un jeton RPT (en anglais « Requesting Party Token »), qui est un jeton d'accès spécial qui contient la description de l’autorisation. L’article de E. Maler et al. "User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization », Janvier, 2018 peut être consulté sur ce sujet.
Aussi, il existe un besoin pour une solution améliorée pour fournir un accès autorisé et authentifié pour des identités fédérées.
La présente invention répond à ce besoin d’une manière simple et pratique qui ne fait pas intervenir plusieurs fournisseurs d’identités au moment de l’authentification et de l’autorisation d’un utilisateur.
La présente invention répond à ce besoin en proposant une solution qui ne requière pas d’étape d’échange de jetons d’accès, car elle fournit à la fois l’authentification et l’application de la politique d’accès.
Un objet de la présente invention est un procédé flexible et pratique permettant l’accès autorisé et authentifié avec des identités fédérées.
La présente invention vise à permettre à un utilisateur d’accéder à des ressources protégées après avoir été à la fois authentifié et autorisé en un nombre de messages minimisé, grâce à l’utilisation d’algorithmes de chiffrement basé sur les attributs.
Dans ce contexte, l’invention permet de simplifier et d’accélérer l’authentification et l'autorisation en permettant à un seul fournisseur d’identité, un fournisseur d’identité maître, de délivrer des jetons d’accès pour des utilisateurs qui sont gérés par les autres fournisseurs d’identités de la fédération ou fournisseurs d’identité locaux.
Dans un mode de réalisation, l’authentification de l’utilisateur est réalisée en utilisant une primitive cryptographique par attributs ou ABE pour « Attribute-Based Encryption ».
La présente invention permet la mise en application cryptographique de politiques de sécurité dans un contexte de fédération d’identités.
La présente invention permet l’application de politiques de sécurité fines et d’une manière flexible.
La présente invention permet également d’accélérer l’accès à des ressources protégées et d’améliorer la mise en échelle.
Le procédé de l’invention apporte plusieurs avantages, en termes de sécurité, de performance et d’aspect pratique. Elle permet notamment :
- une mise en application cryptographique de politique d’accès à des ressources protégées dans un contexte de fédération d’identités ;
- une application de politiques de sécurité fines ;
- de simplifier et rendre flexibles les accès des utilisateurs d’une fédération ;
- d’accélérer l’accès à des ressources protégées et également d’améliorer la mise en échelle ;
- à un fournisseur de service d’enregistrer les points d’accès d’un unique fournisseur d’identité pour une fédération de plusieurs fournisseurs d’identité, où ce dernier n’aura ni la charge, ni la responsabilité d’inscrire les identités de tous les utilisateurs de cette fédération ;
- une mise en place de plusieurs niveaux de politiques de sécurité, par exemple, des politiques de sécurité organisationnelles comme des politiques au niveau d’une société mère vis-à-vis de ses filiales, ses sociétés affiliées, et ses partenaires, et celles au niveau des employés et clients de ces dernières.
D’une manière générale, le procédé de l’invention s’appuie sur la mise en œuvre combinée de deux protocoles :
- un protocole d’authentification utilisateur ; et
- un protocole d’authentification et d’autorisation de fédération d’identité.
D’une manière générale, les domaines d’application de l’invention sont généralement ceux des industriels du domaine de la sécurité des communications machine-à-machine et PPDR, les domaines des réseaux à faibles ressources dans lequel un dispositif contraint en ressources (par exemple un CPU, une mémoire, une batterie) contrôle l’accès aux ressources ou aux services qu’il héberge.
De tels réseaux peuvent être déployés dans des lieux distants, difficiles d’accès où une connexion régulière à une autorité d’authentification et d’autorisation n’est pas réalisable. Dans ces conditions, le procédé de l’invention permet au dispositif d’appliquer la politique d’accès associée aux ressources ou aux services sans passer par une autorité de confiance et sans relation de confiance préalablement établie avec les utilisateurs.
Avantageusement, le procédé de l’invention peut également s’appliquer dans le contexte des réseaux d’urgence pour les systèmes de protection du public et de secours en cas de catastrophe (PPDR). Dans ce type de réseaux, la connexion à une autorité de confiance peut être endommagée, perturbée, ou soumise à des contraintes techniques (par exemple, un trafic très important). La solution proposée par la présente invention permet aux utilisateurs, notamment les primo-intervenants, d’accéder aux ressources et services déployés dans la zone sinistrée d’une manière sécurisée.
Dans un cadre général de la gestion fédérée des identités dans le domaine des technologies d’information dans une fédération d’organisations, la présente invention permet de simplifier la gestion des accès par des utilisateurs d’une organisation aux ressources offertes par une autre organisation de la fédération.
Pour obtenir les résultats recherchés, il est proposé un procédé mis en œuvre dans un environnement ayant des identités fédérées, pour délivrer à un utilisateur un accès autorisé et authentifié à des ressources protégées et partagées dans une fédération, l’environnement comprenant au moins un fournisseur de service hébergeant des ressources protégées et partagées. Le procédé comprend des étapes consistant à :
- recevoir d’un utilisateur, une requête d’accès à une ressource protégée et partagée, l’utilisateur disposant d’au moins une clé privée ABE « Attribute-Based Encryption » en fonction de son identité ;
- authentifier l’utilisateur par une méthode de chiffrement ABE basée sur les attributs, auprès d’un fournisseur d’identité maître, ledit fournisseur d’identité maître étant associé à un générateur de clés privées ABE configuré pour délivrer des clés privées ABE à des fournisseurs d’identité locaux ; et
- autoriser ou refuser l’accès à la ressource protégée et partagée, selon le résultat de l’authentification.
Selon un mode de réalisation, l’étape d’authentifier l’utilisateur, comprend des étapes consistant à :
- rediriger la requête de l’utilisateur vers ledit fournisseur d’identité maître, sous la forme d’un message de demande de jeton d’identité basé sur ABE ;
- vérifier la réception d’un message de réponse du fournisseur d’identité maître ; et
- vérifier si le message reçu contient un jeton d’identité validant l’identité de l’utilisateur ou une erreur d’authentification.
Selon un mode de réalisation, le procédé comprend avant l’étape de réception d’une requête d’accès à une ressource protégée et partagée, des étapes consistant à :
- pour l’utilisateur, enregistrer au moins une identité chez un fournisseur d’identités local ;
- pour le fournisseur d’identité local, fournir à un délégataire de clés privées ABE associé, les attributs de l’utilisateur ; et
- pour le délégataire de clés privées ABE, délivrer à l’utilisateur, au moins une clé privée ABE générée en fonction de ladite au moins une identité enregistrée par l’utilisateur.
Selon un mode de réalisation, le procédé comprend avant l’étape de réception d’une requête d’accès à une ressource protégée et partagée, des étapes consistant à :
- pour un délégataire de clés privées ABE, de s’inscrire auprès du fournisseur d’identités maître ;
- pour le fournisseur d’identité maître, de fournir au générateur de clés privées ABE les attributs associés ; et
- pour le générateur de clés privées ABE, de générer des clés privées ABE au délégataire de clés privées ABE.
Selon un mode de réalisation, l’étape d’authentifier l’utilisateur par une méthode de chiffrement ABE basée sur les attributs, comprend des étapes consistant à :
- rediriger la requête de l’utilisateur vers ledit fournisseur d’identité maître, sous la forme d’une requête en redirection « OpenID Connect » de demande d’authentification, incluant une valeur de balise « amr » permettant de noter une authentification basée sur ABE dans la demande de jeton d’identité « OpenID » ;
- vérifier la réception d’un message du fournisseur d’identité maître avec une réponse « OpenID Connect » ; et
- vérifier si le message reçu contient un jeton d’identité validant l’identité de l’utilisateur, ou contient une erreur d’authentification.
L’invention concerne aussi un dispositif opérant dans un environnement ayant des identités fédérées, pour délivrer à un utilisateur un accès autorisé et authentifié à des ressources protégées et partagées dans une fédération, l’environnement comprenant au moins un fournisseur de service hébergeant des ressources protégées et partagées, le dispositif comprenant :
- des moyens pour recevoir d’un utilisateur une requête d’accès à une ressource protégée et partagée, l’utilisateur disposant d’au moins une clé privée ABE « Attribute-Based Encryption » en fonction de son identité ;
- des moyens pour authentifier l’utilisateur par une méthode de chiffrement ABE basée sur les attributs, auprès d’un fournisseur d’identité maître, ledit fournisseur d’identité maître étant associé à un générateur de clés privées ABE configuré pour délivrer des clés privées ABE à des fournisseurs d’identité locaux ; et
- des moyens pour autoriser ou refuser l’accès à la ressource protégée et partagée, selon le résultat de l’authentification.
Dans un mode de réalisation, le dispositif comprend un calculateur configuré pour exécuter les étapes du procédé de l’invention.
Le dispositif comprend de plus des moyens configurés pour opérer les étapes du procédé de l’invention.
Le dispositif peut opérer dans un environnement de réseau Internet mettant en œuvre le protocole OpenID Connect, et où des applications Web-JavaScript basées sur un navigateur et des applications mobiles natives sont le fournisseur de service qui souhaite authentifier et autoriser un utilisateur.
Dans une variante d’implémentation, le protocole pour échanger des informations est le protocole SAML 2.0.
L’invention concerne aussi un programme d’ordinateur qui comprend des instructions de code pour l’exécution des étapes du procédé de l’invention, lorsque le programme est exécuté sur un ordinateur.
L’invention a aussi pour objet un support d'enregistrement lisible par un processeur sur lequel est enregistré un programme comportant des instructions pour l’exécution des étapes du procédé de l’invention, lorsque le programme est exécuté par un processeur.
Description des figures
D’autres caractéristiques et avantages de l’invention apparaîtront à l’aide de la description qui suit et des figures des dessins annexés dans lesquels :
La déjà décrite illustre de manière simplifiée les flux de messages pour le protocole d’authentification OpenID Connect 1.0 avec des identités fédérées en mode flux implicite ;
La illustre les flux de messages selon les étapes du procédé de l’invention et les entités impliquées, dans un mode de réalisation ;
La illustre de manière simplifiée les flux de messages pour la mise en place initiale de clés privées selon le protocole ABE, dans un mode de réalisation de l’invention ;
La illustre de manière simplifiée les flux de messages pour l’inscription d’un utilisateur, dans un mode de réalisation de l’invention ;
La illustre de manière simplifiée, l’accès sécurisé à une ressource protégée, par un utilisateur enregistré, dans un mode de réalisation de l’invention ;
La est un organigramme des étapes opérées par un fournisseur de service lors d’une requête d’accès sécurisé par un utilisateur enregistré, dans un mode de réalisation de l’invention ; et
La est un organigramme des étapes opérées par un fournisseur d’identité lors d’une requête d’accès sécurisé par un utilisateur enregistré, dans un mode de réalisation de l’invention.
Description détaillée de l’invention
Un exemple d’application de l’invention pris pour décrire les principes de l’invention, mais non limitatif, peut être celui d’une société mère qui souhaite fournir des accès pour ses filiales, ses sociétés affiliées et ses partenaires, à des ressources fournies par une tierce partie avec qui elle a conclu un contrat pour l’utilisation de ces ressources (un contrat de licence par exemple). La société mère ne souhaite pas gérer les employés et les clients de ses filiales, de ses sociétés affiliées et de ses partenaires, mais elle souhaite appliquer une politique de sécurité pour leur accès.
Dans ce contexte d’exemple, la présente invention permet aux employés et aux clients d’accéder aux ressources de la société mère, en utilisant des protocoles standards de fédération d’identité, tout en permettant à la société mère d’appliquer une politique de sécurité à ces derniers sans gérer leurs identités. Ceci est possible grâce au protocole d’authentification mis en œuvre dans le procédé de l’invention et utilisant le chiffrement basé sur les attributs.
L’invention repose sur l’utilisation combinée de deux protocoles : un protocole d’authentification d’utilisateur et un protocole d’authentification et d’autorisation d’identité fédérée.
La description détaillée d’un mode de réalisation de l’invention s’appuie sur l’utilisation d’un protocole d’authentification d’utilisateur utilisant le chiffrement basé sur les attributs (ABE) combiné à un protocole d’authentification et d’autorisation d’identité fédérée basé sur OpenID Connect 1.0 en mode flux de message implicite.
L’homme du métier pourra décliner les principes de l’invention en mettant en œuvre d’autres protocoles d’authentification d’utilisateur combinés à d’autres protocoles d’authentification et d’autorisation d’identité fédérée basés sur d’autres modes de flux de messages. Les principes de l’invention peuvent être adaptés à un mode de flux de code d’autorisation (ou flux de base), ou à un mode de flux hybride qui est une combinaison de flux de code d’autorisation et flux implicite, ces modes de flux différant par la manière dont les jetons d’accès sont retournés par le fournisseur d’identités.
Dans un mode de réalisation, le protocole d’authentification utilisateur utilisé est une méthode de chiffrement basé sur les attributs (ABE) tel que par exemple la méthode décrite dans la demande de brevet FR3081652 de la Demanderesse. D’autres méthodes mettant en œuvre des mécanismes de cryptographie basés sur les attributs peuvent être utilisés, l’homme du métier pouvant se reporter à la demande de brevet précitée pour une description complète et détaillée de tels protocoles d’authentification des utilisateurs qui sont applicables à la méthode de l’invention.
Le procédé de l’invention utilise le chiffrement basé sur les attributs (ABE) plutôt que des algorithmes de chiffrement à clé publique standards, pour fournir à la fois un chiffrement à clé publique et une mise en application cryptographique du contrôle d’accès. L’invention conserve l’avantage d’un mécanisme de chiffrement basé sur les attributs qui permet d’accéder à un service en étant authentifié sur la base de ses attributs sans être identifié personnellement.
L’invention permet à un fournisseur de services ou de ressources de contrôler l’accès à ces services ou ressources par un utilisateur non authentifié. Le contrôle d’accès est réalisé en fonction d’une politique d’accès. Un utilisateur est autorisé s’il possède des attributs qui satisfont la politique d’accès. On rappelle qu’un attribut peut concerner l’utilisateur, les ressources ou services protégés, ou le contexte (par exemple, date, lieu, niveau de menace, etc.). La notion d’attribut permet par exemple de définir des groupes d’utilisateurs qui possèdent un attribut commun. Chaque utilisateur peut appartenir à un ou plusieurs groupes. Une politique d’accès est définie comme une combinaison de portes logiques de seuil sur des attributs. Un attribut peut être affecté à un utilisateur temporairement ou de façon permanente. A son niveau le plus simple, une politique d’accès peut consister à autoriser l’accès aux individus possédant un attribut prédéterminé. Par exemple, dans le contexte d’un conglomérat ou celui d’une grande entreprise, on considère une entreprise composée d’une société mère et de ses deux divisions A et B. La société mère souhaite par exemple partager une ressource fournie par une tierce partie, uniquement aux employés du département des ressources humaines RH de sa division A. La division A distribue d’une manière sécurisée des clés privées et personnalisées ‘ABE’ à ses employés selon leurs attributs. En particulier, les agents des ressources humaines de la division A possèdent au moins les clés ABE associées aux attributs « division A » et « département RH ». Avantageusement, la présente invention rend possible l’application de la politique d’accès de la société mère sans que cette dernière participe à l’identification des employés de ses divisions, en permettant à la société mère d’appliquer la politique d’accès exprimée par la combinaison logique [« division A » ET « département RH »], avant de permettre l’accès à la ressource protégée. Ainsi, seuls les employés qui ont les clés ABE associées aux attributs « division A » et « département RH » peuvent accéder à cette ressource protégée.
L’invention se base sur un mécanisme de chiffrement basé sur les attributs. Elle est compatible à la fois d’un mécanisme de chiffrement de type CP-ABE pour lequel un fournisseur contrôle l’accès aux ressources/services qu’il propose selon une politique d’accès, mais aussi d’un mécanisme de chiffrement de type KP-ABE pour lequel un fournisseur contrôle l’accès aux ressources/services qu’il propose directement en fonction d‘une liste d’attributs autorisés.
Dans un mode de réalisation, le procédé de l’invention met en œuvre différentes entités, dont les trois entités fonctionnelles - Utilisateur ; Fournisseur de service ; Fournisseur d’identité - du protocole d’authentification et d’autorisation d’identité fédérée OpenID Connect 1.0, auxquelles sont associées deux autres entités : un Générateur de clés privées ABE et un Délégataire de clés privées ABE.
Le dispositif peut opérer dans un environnement de réseau Internet mettant en œuvre le protocole OpenID Connect, et où des applications Web-JavaScript basées sur un navigateur et des applications mobiles natives sont le fournisseur de service qui souhaite authentifier et autoriser un utilisateur.
Dans une variante d’implémentation, le protocole pour échanger des informations est le protocole SAML 2.0.
La illustre les flux de messages entre les entités impliquées selon différentes phases du procédé de l’invention.
Le procédé de l’invention se découpe en plusieurs phases que sont :
- une phase (A) de mise en place initiale de clés ;
- une phase (B) d’inscription d’un utilisateur ; et
- une phase (C) d’accès sécurisé par un utilisateur enregistré à une ressource protégée et partagée dans une fédération.
Les entités fonctionnelles participant au procédé selon l’invention sont :
- 202 : une entité dite ‘Utilisateur’, correspondant à un terminal à partir duquel un utilisateur souhaite accéder à une ressource protégée. Le terme terminal est générique pour désigner tout type d’ordinateur que ce soit un ordinateur fixe, portable, un tablette, un téléphone, …Dans la suite de la description, le terme « utilisateur » est utilisé pour désigner un terminal utilisé par un utilisateur pour requérir et accéder à un service ou à une ressource proposé(e) par un fournisseur.
- 212 : une entité dite ‘Fournisseur de Service’, correspondant à un équipement qui héberge une/des ressource(s) protégées et partagées (ou des services) auxquelles un utilisateur souhaite accéder. Un service peut être un service hébergé sur un serveur distant et proposé par un fournisseur sur Internet par exemple. Il peut s’agir d’une application logicielle. Une ressource peut être un calculateur ou un processeur ou une mémoire dans un serveur distant ou sur le terminal de l’utilisateur lui-même. Le fournisseur de service fournit le service ou la ressource à un utilisateur après l’avoir authentifié selon le protocole de la présente invention, et l’avoir autorisé à accéder au service ou à la ressource.
- 204, 208 : une entité dite ‘Fournisseur d’identité’, correspondant à au moins un module fonctionnel qui réalise l’authentification et l’autorisation d’utilisateurs dont il gère les identités, pour accéder à des ressources protégées, et qui délivre ces identités d’une manière sécurisée. Dans une mode de réalisation selon l’exemple décrit, le module fonctionnel est implémenté comme un premier module dit ‘Fournisseur d’identité maître’ (208) ou fournisseur d’identité de la fédération, et un second module dit ‘Fournisseur d’identité local’ (204) ou fournisseur d’identité dédié.
- 210 : une entité dite ‘Générateur de clés privées ABE’, correspondant à une entité ou tiers de confiance, associée à un fournisseur d’identité maître, qui génère et délivre des clés publiques et privées ABE, i.e. selon un mécanisme de chiffrement basé sur les attributs.
- 206 : une entité dite ‘Délégataire de clés privées ABE’, correspondant à une entité associée à un fournisseur d’identité local, qui reçoit et stocke des clés privées reçues d’un générateur de clés privées ABE, et qui les distribue aux utilisateurs en fonction de leurs identités.
Le fournisseur d’identités est désigné comme le fournisseur d’identités maître (208) en déterminant son identifiant comme l’identifiant préféré de l'utilisateur pour s’authentifier auprès des fournisseurs de services, i.e. le fournisseur de services choisit ce fournisseur d’identités en lui envoyant une requête pour effectuer l’authentification de l’utilisateur. Le fournisseur de services peut récupérer l’identifiant du fournisseur d’identités maître de l’utilisateur en utilisant les informations envoyées par l’utilisateur, par exemple son login, son certificat numérique ou par d’autres moyens.
Avantageusement, dans la présente invention, les fournisseurs d’identité, dits dédiés ou locaux (204), gèrent les identités de certains utilisateurs mais ne sont pas responsables de leur authentification.
Dans un exemple concret, le fournisseur d’identités maître (208) peut être responsable d’authentifier auprès de fournisseurs de services tiers tous les utilisateurs appartenant à une même entreprise, université, centre de recherche, ou toute autre organisation, même ceux dont ils ne gèrent pas directement les identités. Les identités de ces derniers sont gérées par des fournisseurs d’identité locaux (204) au sein de la même organisation.
La phase (A) du procédé de l’invention consiste en la mise en place initiale des clés. Elle ne fait pas intervenir l’utilisateur (202), ni le fournisseur de service (212). Cette phase est réalisée une fois, lors de la mise en place du système d’authentification basée sur ABE. L’homme du métier pourra se reporter à la demande de brevet précitée de la Demanderesse pour compléter la lecture des mécanismes de chiffrement basé sur les attributs.
Durant la phase (A), détaillée en référence à la , le délégataire de clés privées ABE s’inscrit (2002) auprès du fournisseur d’identités maître (208) qui fournit (2004) au générateur de clés privées ABE (210) les attributs associés. A réception des attributs, le générateur de clés privées ABE (210) génère d’abord des clés publiques ABE, puis génère des clés privées ABE. Les clés privées ABE sont par la suite distribuées (2006) d’une manière sécurisée, aux délégataires de clés privées (206) correspondants, selon les identités gérées par les fournisseurs d’identité locaux (204) associés.
La phase (B) du procédé de l’invention consiste en l’inscription d’un utilisateur. Elle fait intervenir l’utilisateur (202), le fournisseur d’identités local (204) et le délégataire de clés privées ABE (206). Cette phase est réalisée à chaque fois qu’il y a un nouvel utilisateur qui s’inscrit ou qui met à jour ses identités.
Durant la phase (B), détaillée en référence à la , l’utilisateur (202) enregistre (2102) ses identités chez un fournisseur d’identités (204), qui fournit (2104) au délégataire de clés privées (206) associé, les attributs de l’utilisateur. Le délégataire de clés privées ABE délivre (2106) à l’utilisateur, d’une manière sécurisée, des clés privées ABE générées selon les identités enregistrées par l’utilisateur.
La phase (C) du procédé de l’invention couvre les étapes permettant un accès sécurisé par un utilisateur enregistré (lors de la phase B) à une ressource protégée et partagée dans une fédération. Elle fait intervenir l’utilisateur (202), le fournisseur d’identités maître (208), le générateur de clés privées ABE (210) et le fournisseur d’identités maître (208). La phase (C) est réalisée à chaque fois qu’un utilisateur enregistré souhaite accéder à une ressource protégée par un fournisseur de service avec lequel il ne partage pas encore un contexte de sécurité.
La phase (C) détaillée en référence à la , comprend des étapes consistant en ce que :
2202 : L’utilisateur (202) demande d’accéder à une ressource protégée par un fournisseur de service (212).
2204 : le fournisseur de service renvoie/redirige la requête d’authentification vers un fournisseur d’identités maître (208) connu par le fournisseur de service. Dans un mode de réalisation, le renvoi de la requête se fait en utilisant une requête en redirection « OpenID connect » de demande d’authentification, incluant une nouvelle valeur de la balise « amr » (pour « Authentication Methods References » en anglais) du « claim », pour noter une authentification basée sur ABE dans la demande de jeton d’identité OpenID, tel que : "amr": ["abe"].
2206 : l’utilisateur (202) s’authentifie auprès du fournisseur d’identités maître (208) en utilisant le protocole d’authentification basé sur ABE.
2208 : après une authentification réussie, le fournisseur d’identité maître (208) renvoie l’utilisateur (202) vers le fournisseur de service (212) utilisant une réponse en redirection « OpenID connect » de réponse d’authentification, incluant un jeton d’identité « OpenID » avec la nouvelle balise « amr » dans les claims pour noter une authentification basée sur ABE réussie.
2210 : en validant le jeton d’accès, le fournisseur de service (212) permet à l’utilisateur (202) d’accéder à la ressource protégée.
La est un organigramme des étapes (600) opérées par un fournisseur de service (212) dans un mode de réalisation de la phase (C) de l’invention, i.e. lorsqu’un utilisateur enregistré souhaite accéder à une (des) ressource(s) du fournisseur de service. Un utilisateur enregistré est un utilisateur qui selon le mode opératoire de la phase (B) a préalablement inscrit ses identités auprès du fournisseur d’identité (208), et qui dispose alors de clés privées ABE.
Le procédé débute à réception (602) d’une requête utilisateur d’accès à une ressource.
Selon l’exemple d’application proposé, le fournisseur d’identité maître qui authentifie l’utilisateur avec le protocole d’authentification basé sur ABE pendant la phase (C) est associé à la société mère, alors que le fournisseur d’identité local qui enregistre les identités de l’utilisateur peut être associé à sa filiale. Le fournisseur de service fournit par exemple des solutions Web, payées par la société mère et utilisées par ses employés ou par les clients de sa filiale.
Dans une étape suivante (604), le procédé permet au fournisseur de service de mettre en œuvre une redirection de l’utilisateur vers le fournisseur d’identité maître, en générant un message requête de type OpenID Connect, avec une valeur de la balise amr permettant d’indiquer dans la demande de jeton d’identité OpenID, une authentification qui est basée sur ABE.
L’étape suivante (606) du procédé consiste pour le fournisseur de service à vérifier qu’il reçoit un message du fournisseur d’identité maître qui contient une réponse OpenID.
A réception de ce message, le procédé permet au fournisseur de service de vérifier (608) la validité du jeton d’identité contenu dans la réponse OpenID.
Si le jeton est valide, le fournisseur de service répond favorablement (612) à la demande d’accès aux ressources de l’utilisateur, ou si le jeton n’est pas valide, l’accès aux ressources est refusé (614) à l’utilisateur.
La est un organigramme des étapes (700) opérées par un fournisseur d’identité (208) dans un mode de réalisation de la phase (C) de l’invention, i.e. lorsqu’un utilisateur enregistré souhaite accéder à une (des) ressource(s) du fournisseur de service (212).
Le procédé débute (702) à réception d’un message OpenID Connect ayant une balise amr de valeur : "amr" : ["abe"], émis (604) par le fournisseur de service.
Dans une étape suivante (704), le procédé permet au fournisseur d’identité maître de mettre en œuvre un processus d’authentification avec l’utilisateur (202), basé sur ABE.
Dans une étape suivante (706), le procédé permet au fournisseur d’identité maître de vérifier si l’authentification est réussie ou non.
Si l’authentification a échouée, le procédé permet au fournisseur d’identité maître de générer (708) une redirection vers le fournisseur de service d’un message avec une réponse OpenID Connect qui contient une erreur d’authentification.
Si l’authentification a réussie, le procédé permet au fournisseur d’identité maître de générer (710) une redirection vers le fournisseur de service d’un message avec une réponse OpenID Connect qui contient un jeton d’identité.
Les principes de l’invention peuvent être adaptés à des variantes de réalisation. Trois variantes de réalisation indiquées, mais l’homme du métier pourra décliner des alternatives en conservant les mêmes principes.
Dans une première variante de réalisation, le procédé de l’invention est mis en œuvre avec un seul fournisseur d’identité qui enregistre les utilisateurs, et avec un délégataire de clés privées ABE qui est co-localisé avec le générateur de clés privées ABE. Ce mode de réalisation permet à la fois d’authentifier les utilisateurs et d’appliquer une politique de sécurité fine.
Puisque les messages d’authentification de l’utilisateur sont généralement sécurisés (par exemple par SSL/TLS), le protocole d’authentification qui est basé sur ABE peut, dans une variante de réalisation, être réduit à un simple échange « défi/réponse », où le fournisseur d’identité envoie un horodatage ou un nonce chiffré par ABE selon la politique de sécurité. L’utilisateur doit pouvoir le déchiffrer s’il possède les clés associées à des attributs qui satisfont la politique de sécurité, et ainsi répondre par l’horodatage ou le nonce déchiffré.
Une troisième variante de réalisation est applicable pour des algorithmes de chiffrement ABE qui comprennent un algorithme de délégation de clés privées ABE qui permet de générer des nouvelles clés privées différenciées pour des attributs inclus dans la liste des attributs associés aux clés privées originales. Cet algorithme de délégation de clés peut alors être utilisé par le délégataire de clés privées ABE pour délivrer à des utilisateurs des nouvelles clés privées ABE lors de leur inscription.
Ainsi, il a été décrit une solution selon différentes variantes, pour valider l’accès à des ressources protégées dans un contexte d’identités fédérées. La solution présente entres autres avantages de ne pas faire intervenir plusieurs fournisseurs d’identités au moment de l’authentification et de l’autorisation d’un utilisateur.

Claims (11)

  1. Procédé mis en œuvre dans un environnement ayant des identités fédérées, pour délivrer à un utilisateur un accès autorisé et authentifié à des ressources protégées et partagées dans une fédération, et comprenant au moins un fournisseur de service hébergeant des ressources protégées et partagées, le procédé comprenant des étapes consistant à :
    - recevoir (2202) d’un utilisateur (202) une requête d’accès à une ressource protégée et partagée, l’utilisateur disposant d’au moins une clé privée ABE « Attribute-Based Encryption » en fonction de son identité ;
    - authentifier (2204, 2206, 2008) l’utilisateur par une méthode de chiffrement ABE basée sur les attributs, auprès d’un fournisseur d’identité maître (208), ledit fournisseur d’identité maître étant associé à un générateur de clés privées ABE (210) configuré pour délivrer des clés privées ABE à des fournisseurs d’identité locaux (204) ; et
    - autoriser (2210) ou refuser (614) l’accès à la ressource protégée et partagée, selon le résultat de l’authentification.
  2. Le procédé selon la revendication 1 dans lequel l’étape d’authentifier l’utilisateur, comprend des étapes consistant à :
    - rediriger (604) la requête de l’utilisateur vers ledit fournisseur d’identité maître (208), sous la forme d’un message de demande de jeton d’identité basé sur ABE ;
    - vérifier (606) la réception d’un message de réponse du fournisseur d’identité maître (208) ; et
    - vérifier (608) si le message reçu contient un jeton d’identité validant l’identité de l’utilisateur ou une erreur d’authentification.
  3. Le procédé selon la revendication 1 ou 2 comprenant avant l’étape de réception (2202) d’une requête d’accès à une ressource protégée et partagée, des étapes consistant à :
    - pour l’utilisateur, enregistrer (2102) au moins une identité chez un fournisseur d’identités local (204) ;
    - pour le fournisseur d’identité local, fournir (2104) à un délégataire de clés privées ABE (206) associé, les attributs de l’utilisateur ; et
    - pour le délégataire de clés privées ABE, délivrer (2106) à l’utilisateur, au moins une clé privée ABE générée en fonction de ladite au moins une identité enregistrée par l’utilisateur.
  4. Le procédé selon l’une quelconque des revendications 1 à 3 comprenant avant l’étape de réception (2202) d’une requête d’accès à une ressource protégée et partagée, des étapes consistant à :
    - pour un délégataire de clés privées ABE, de s’inscrire (2002) auprès du fournisseur d’identités maître (208) ;
    - pour le fournisseur d’identité maître, de fournir (2004) au générateur de clés privées ABE (210) les attributs associés ; et
    - pour le générateur de clés privées ABE (210), de générer (2206) des clés privées ABE au délégataire de clés privées ABE.
  5. Le procédé selon l’une quelconque des revendications 1 à 4 dans lequel l’étape d’authentifier l’utilisateur par une méthode de chiffrement ABE basée sur les attributs, comprend des étapes consistant à :
    - rediriger (2204, 604) la requête de l’utilisateur vers ledit fournisseur d’identité maître (208), sous la forme d’une requête en redirection « OpenID Connect » de demande d’authentification, incluant une valeur de balise « amr » permettant de noter une authentification basée sur ABE dans la demande de jeton d’identité « OpenID » ;
    - vérifier (606) la réception d’un message du fournisseur d’identité maître (208) avec une réponse « OpenID Connect » ; et
    - vérifier (608) si le message reçu contient un jeton d’identité (710) validant l’identité de l’utilisateur, ou contient une erreur d’authentification (708).
  6. Un programme d’ordinateur comprenant des instructions de code permettant d’exécuter les étapes du procédé de l'une quelconque des revendications 1 à 5, lorsque ledit programme est exécuté sur un ordinateur.
  7. Support d'enregistrement lisible par un processeur sur lequel est enregistré un programme comportant des instructions pour l'exécution des étapes du procédé de l’une quelconque des revendications 1 à 5, lorsque le programme est exécuté par un processeur.
  8. Un dispositif opérant dans un environnement ayant des identités fédérées, pour délivrer à un utilisateur un accès autorisé et authentifié à des ressources protégées et partagées dans une fédération, l’environnement comprenant au moins un fournisseur de service hébergeant des ressources protégées et partagées, le dispositif comprenant :
    - des moyens pour recevoir d’un utilisateur (202) une requête d’accès à une ressource protégée et partagée, l’utilisateur disposant d’au moins une clé privée ABE « Attribute-Based Encryption » en fonction de son identité ;
    - des moyens pour authentifier l’utilisateur par une méthode de chiffrement ABE basée sur les attributs, auprès d’un fournisseur d’identité maître (208), ledit fournisseur d’identité maître étant associé à un générateur de clés privées ABE (210) configuré pour délivrer des clés privées ABE à des fournisseurs d’identité locaux (204) ; et
    - des moyens pour autoriser ou refuser l’accès à la ressource protégée et partagée, selon le résultat de l’authentification.
  9. Le dispositif selon la revendication 8 comprenant un calculateur configuré pour exécuter les étapes du procédé de l’une quelconque des revendications 1 à 5.
  10. Le dispositif selon la revendication 8 ou la revendication 9 opérant notamment dans un environnement de réseau Internet mettant en œuvre le protocole OpenID Connect, et où des applications Web-JavaScript basées sur un navigateur et des applications mobiles natives sont le fournisseur de service qui souhaite authentifier et autoriser un utilisateur.
  11. Le dispositif selon la revendication 8 ou la revendication 9, où le protocole pour échanger des informations est le protocole SAML 2.0 « Security Assertion Markup Language ».
FR2013775A 2020-12-21 2020-12-21 Procédé et dispositif permettant un accès autorisé et authentifié pour des identités fédérées Active FR3118382B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR2013775A FR3118382B1 (fr) 2020-12-21 2020-12-21 Procédé et dispositif permettant un accès autorisé et authentifié pour des identités fédérées

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2013775 2020-12-21
FR2013775A FR3118382B1 (fr) 2020-12-21 2020-12-21 Procédé et dispositif permettant un accès autorisé et authentifié pour des identités fédérées

Publications (2)

Publication Number Publication Date
FR3118382A1 true FR3118382A1 (fr) 2022-06-24
FR3118382B1 FR3118382B1 (fr) 2024-04-26

Family

ID=74860132

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2013775A Active FR3118382B1 (fr) 2020-12-21 2020-12-21 Procédé et dispositif permettant un accès autorisé et authentifié pour des identités fédérées

Country Status (1)

Country Link
FR (1) FR3118382B1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017036146A1 (fr) * 2015-08-31 2017-03-09 索尼公司 Procédé pour autoriser un accès et appareil utilisant le procédé
FR3081652A1 (fr) 2018-05-28 2019-11-29 Commissariat A L'energie Atomique Et Aux Energies Alternatives Methode d'etablissement de cles pour le controle d'acces a un service ou une ressource
CN108418784B (zh) * 2017-12-04 2020-09-25 重庆邮电大学 一种基于属性密码的分布式跨域授权和访问控制方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017036146A1 (fr) * 2015-08-31 2017-03-09 索尼公司 Procédé pour autoriser un accès et appareil utilisant le procédé
US20210006548A1 (en) * 2015-08-31 2021-01-07 Sony Corporation Method for authorizing access and apparatus using the method
CN108418784B (zh) * 2017-12-04 2020-09-25 重庆邮电大学 一种基于属性密码的分布式跨域授权和访问控制方法
FR3081652A1 (fr) 2018-05-28 2019-11-29 Commissariat A L'energie Atomique Et Aux Energies Alternatives Methode d'etablissement de cles pour le controle d'acces a un service ou une ressource

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
D. HARDT: "The OAuth 2.0 Authorization Framework", IETF RFC 6749, October 2012 (2012-10-01)
E. MALER ET AL., USER-MANAGED ACCESS (UMA) 2.0 GRANT FOR OAUTH 2.0 AUTHORIZATION, January 2018 (2018-01-01)
NIWA YUSUKE ET AL: "Construction of a Multi-domain Functional Encryption System on Functional Information Infrastructure", 2013 16TH INTERNATIONAL CONFERENCE ON NETWORK-BASED INFORMATION SYSTEMS, IEEE, 4 September 2013 (2013-09-04), pages 105 - 112, XP032534006, DOI: 10.1109/NBIS.2013.19 *

Also Published As

Publication number Publication date
FR3118382B1 (fr) 2024-04-26

Similar Documents

Publication Publication Date Title
US11212268B2 (en) Method and system for identity and access management for blockchain interoperability
KR101063368B1 (ko) 연합 환경에서 신원 제공자를 위한 디지털 권리 관리(ｄｒｍ) 강화 정책 관리
KR101054700B1 (ko) 연합 환경에서 서비스 제공업자를 위한 디지털 권리 관리(ｄｒｍ) 강화 정책 관리
US7860883B2 (en) Method and system for distributed retrieval of data objects within multi-protocol profiles in federated environments
US9608814B2 (en) System and method for centralized key distribution
TWI432000B (zh) 供應數位身份表徵
US7860882B2 (en) Method and system for distributed retrieval of data objects using tagged artifacts within federated protocol operations
TWI438642B (zh) 供應數位身份表徵的系統及方法
US8935808B2 (en) Identity attribute exchange and validation broker
US9800614B2 (en) Method and system for global logoff from a web-based point of contact server
US20080021866A1 (en) Method and system for implementing a floating identity provider model across data centers
WO2011073560A1 (fr) Acces a un reseau de distribution de contenu numerique
JP2005519533A (ja) 通信システム中の複製クライアント識別情報の検出
US10958630B2 (en) System and method for securely exchanging data between devices
US8931064B2 (en) Identity attribute exchange and validation ecosystem
WO2017081208A1 (fr) Procede de securisation et d'authentification d'une telecommunication
CN117501729A (zh) 传统认证与基于云的认证的集成
Chae et al. A study on secure user authentication and authorization in OAuth protocol
Chinnasamy et al. A scalable multilabel‐based access control as a service for the cloud (SMBACaaS)
Kaur et al. A survey paper on social sign-on protocol OAuth 2.0
WO2002089407A2 (fr) Comptabilite dans des reseaux de communication entre homologues
WO2019228853A1 (fr) Methode d'etablissement de cles pour le controle d'acces a un service ou une ressource
Shaikh et al. Identity management in cloud computing
FR3118382A1 (fr) Procédé et dispositif permettant un accès autorisé et authentifié pour des identités fédérées
Das et al. Design of a Trust-Based Authentication Scheme for Blockchain-Enabled IoV System

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20220624

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4