Mode d emploi pour OAuth et pour sécuriser les API avec CA Layer 7

LIVRE BLANC Février 2014 Mode d emploi pour OAuth et pour sécuriser les API avec CA Layer 7 Faciliter l implémentation d OAuth au sein de votre organisation

2 Livre blanc : Faciliter l implémentation d OAuth au sein de votre organisation Table des matières Qu est-ce que OAuth? 3 Quels exemples d implémentation OAuth? 4 Ce problème n était-il pas déjà réglé? 6 En quoi la spécification OAuth 2.0 est-elle différente des précédentes versions? 6 Pourquoi l implémentation est-elle complexe? 8 Comment CA Layer 7 peut-il m aider à implémenter OAuth? 9 Quel est l avantage d OAuth Toolkit? 10 Comment CA Layer 7 peut-il m aider dans le cadre d une authentification OAuth à deux ou trois parties? 11 Contactez CA Technologies 12

3 Livre blanc : Faciliter l implémentation d OAuth au sein de votre organisation Qu est-ce que OAuth? OAuth est un protocole Web relativement nouveau qui régit l octroi d un accès limité aux applications et données. Il a été conçu pour permettre aux utilisateurs d octroyer un accès restreint aux ressources dont ils sont propriétaires (images résidant sur un site tel que Flickr ou SmugMug, par exemple) à un client tiers tel qu un site d impression de photos par exemple. Auparavant, il était courant de demander à l utilisateur de partager son nom d utilisateur et son mot de passe avec le client en question, une demande qui pouvait sembler anodine, mais qui dissimulait un risque de sécurité inacceptable. À l inverse, OAuth fournit un modèle basé sur le principe du moindre droit, dans lequel l utilisateur peut accorder un accès limité à ses applications et données en émettant un jeton à la capacité limitée. OAuth marque une étape importante, dans la mesure où il place la gestion de la délégation Web entre les mains du véritable propriétaire des ressources, lequel comble les blancs entre ses comptes sur différentes applications Web sans que des administrateurs de sécurité aient besoin d intervenir directement sur chaque site. La relation ainsi établie entre deux comptes peut s inscrire dans la durée ou être résiliée très facilement et à tout moment par l utilisateur. L une des grandes améliorations de OAuth pour la communauté Web réside dans la formalisation du processus de délégation du mappage des identités aux utilisateurs. OAuth s est rapidement imposé comme une norme de base du Web, s étendant bien au-delà des réseaux sociaux pour prendre une place très importante au sein de l entreprise : des compagnies d assurance, des câblo-opérateurs et même des prestataires de soins de santé utilisent aujourd hui OAuth afin de gérer l accès à leurs ressources. Cette popularité s explique en grande partie par le besoin qu ont les entreprises de pouvoir prendre en charge un éventail de clients et de terminaux mobiles de plus en plus varié. Elles déploient des API en conséquence afin de desservir ce nouveau canal de livraison ; dans ce contexte, OAuth est le meilleur outil de gestion des autorisations pour ces API. Cependant, il est important de reconnaître qu OAuth n est qu un composant d une solution complète de sécurité et de contrôle des accès aux API. Il est en effet facile de s attacher aux détails du protocole, et de perdre ainsi de vue ce qu implique la gestion des API de l entreprise : gestion des utilisateurs, besoins d audit, limitation du trafic et détection des menaces. Les API constituant souvent un chemin d accès direct vers les applications critiques de l entreprise, il convient de protéger celles-ci au moyen d une solution de sécurité professionnelle. CA Layer 7 s engage à fournir une infrastructure qui permet d activer OAuth dans les applications de l entreprise. Nos solutions prêtes à l emploi, que ce soit la solution de base API Proxy ou les solutions complètes SOA Gateway et Mobile Access Gateway, s intègrent avec les systèmes de gestion des identités et des accès existants de l entreprise pour lui permettre de déployer un modèle d autorisation cohérent à son échelle. Toutes les solutions de passerelle de CA Layer 7 sont disponibles sous forme d images virtuelles faciles à déployer. La flexibilité des solutions CA Layer 7 leur permet de s intégrer avec des implémentations OAuth tierces qui peuvent ne pas être entièrement compatibles avec les normes actuelles, mais qui vous prémunissent des changements liés à une technologie à évolution rapide. Ce livre blanc de CA Layer 7 Technologies décrit ce qu est OAuth et vous montre comment faciliter son implémentation au sein de votre organisation.

4 Livre blanc : Faciliter l implémentation d OAuth au sein de votre organisation Quels exemples d implémentation OAuth? Les réseaux sociaux ont été les premiers à adopter OAuth. Facebook et Twitter doivent en grande partie leur réussite au fait qu ils ne sont pas des sites Web autonomes, mais des plates-formes qui encouragent l intégration avec d autres applications. L intégration s opère au niveau d API REST qui utilise OAuth comme moyen d authentification, d autorisation et de liaison entre les comptes personnels. Twitter et Facebook offrent d excellents exemples de la mise en oeuvre de la norme OAuth. Comme bon nombre d entre nous, vous possédez probablement des comptes distincts sur ces deux grands réseaux sociaux. Peut-être même vos deux comptes, même s ils sont gérés sur des sites différents, portent-ils le même nom (associé à un mot de passe différent, nous l espérons pour votre sécurité). Dans ce contexte, comment faire en sorte que vos tweets s affichent instantanément sur votre mur Facebook? Par le passé, vous auriez probablement dû enregistrer vos noms d utilisateur et mot de passe Facebook dans votre profil Twitter. Ainsi, lorsque vous publiiez un nouveau tweet, l application Twitter se connectait pour vous afin de le publier sur Facebook en votre nom. Cette approche appelée «password anti-pattern» (anti-modèle de mot de passe) est une mauvaise idée pour plusieurs raisons. De manière générale, confier à Twitter votre mot de passe Facebook revient à lui accorder trop de droits : si une personne malveillante était amenée à pirater le site ou si un administrateur du site décidait d enfreindre la loi, il pourrait exploiter votre mot de passe en texte clair afin par exemple de publier des images compromettantes, voire verrouiller votre accès à votre propre compte ou même supprimer celui-ci. Heureusement, Twitter et Facebook utilisent OAuth. OAuth offre un modèle d autorisation déléguée qui autorise Twitter à publier sur votre mur, mais rien de plus. Le processus est illustré dans la figure 1 ci-dessous. Illustration 1. OAuth permet à Twitter de publier des tweets sur votre compte Facebook sans avoir besoin de votre mot de passe Facebook. Publication de tweets sur votre mur Facebook Client 2. Twitter publie un tweet sur Facebook au nom de l utilisateur Propriétaire de la ressource (soit l utilisateur) 1. L utilisateur publie un nouveau tweet Serveur d autorisation Serveur de ressource

5 Livre blanc : Faciliter l implémentation d OAuth au sein de votre organisation Du point de vue de l utilisateur, l interaction est à la fois simple et intuitive. Elle est expliquée dans la figure 2 ci-dessous. Depuis les paramètres de son compte Twitter, l utilisateur clique sur un bouton qui le dirige vers Facebook et lui permet de se connecter à son compte. Il établit ainsi une association entre ses deux comptes sans faire intervenir les administrateurs de sécurité de Twitter ni de Facebook. Une fois authentifié sur Facebook, il suit une procédure de consentement au cours de laquelle il peut choisir le sous-ensemble de droits qu il souhaite octroyer à Twitter pour permettre à l application de réaliser des opérations en son nom. Enfin, l utilisateur retourne automatiquement dans Twitter, où il peut continuer à publier des tweets qui apparaîtront désormais également sur son mur Facebook. La relation établie entre ses deux comptes est maintenue jusqu à ce qu il décide d y mettre fin de manière explicite, à l aide de sa page de paramètres. Figure 2. Méthode pour autoriser Twitter à publier des tweets sur votre mur Facebook. 1. Publication sur Facebook non autorisée 2. Connexion à Facebook et octroi à Twitter de l autorisation de publier sur le mur 3. Publication sur Facebook désormais autorisée Pour l utilisateur, le processus est simple et intuitif : c est précisément ce qui fait l attrait d OAuth, même si cette simplicité cache une interaction bien plus complexe entre les sites. L authentification OAuth à trois parties («Three-legged OAuth») décrite dans ce scénario est le cas d utilisation le plus courant de la spécification OAuth 1.0a, publié sous l appellation RFC 5849. Bien que détaillée, cette spécification offre un champ d application étonnamment étroit : elle définit le flux de redirection qui permet à l utilisateur d associer ses comptes, d autoriser un sous-ensemble limité d opérations et de renvoyer un jeton opaque que Twitter peut conserver de manière sécurisée pour accéder à Facebook plutôt que de stocker un mot de passe lui donnant tous les droits. Elle détaille même (dans sa version 1.0) une méthode permettant de relier le jeton au contenu des paramètres au moyen de signatures numériques, ce qui rend possible le contrôle de l intégrité du contenu envoyé via des canaux non chiffrés. L une des forces de la spécification OAuth 1.0a réside dans le fait qu elle propose une solution au défi de conception courant décrit plus haut, plutôt que de tenter de définir un cadre d autorisation généralisé. Issue d une initiative populaire pour résoudre un problème spécifique, la spécification est née au bon moment. Rien d étonnant à ce qu elle soit devenue si populaire et ait été adoptée par des sites tels que Google, DropBox, SalesForce, FourSquare et LinkedIn. Toutefois, OAuth évolue : sa version 2, publiée en octobre 2012, entend répondre à un éventail d applications bien plus étendu. Cela contribue à ajouter à sa complexité et à la tâche des développeurs qui l implémentent afin de protéger les API d entreprise.

6 Livre blanc : Faciliter l implémentation d OAuth au sein de votre organisation Ce problème n était-il pas déjà réglé? Aucun processus formel défini ne résout le problème de la délégation d autorisations auquel répond OAuth. Ses concepteurs ont pris en compte les alternatives et n ont pu mettre au point qu une poignée de solutions, toutes propriétaires. Si OAuth est né d un besoin, l un de ses principaux objectifs était l ouverture. Le langage SAML, la norme la plus utilisée pour une authentification unique fédérée (SSO), peut être utilisé comme format de jeton pour communiquer des opérations déléguées entre les sites à l aide du type de jeton sendervouches. Cependant, le SAML à lui seul ne permet pas de définir le flux des interactions nécessaires pour configurer la relation de confiance ou l association entre les comptes. De plus, le SAML est un format XML très complexe et ne convient donc pas aux pratiques de développement actuelles, basées sur les principes RESTful et les structures de données JSON simples. OpenID a tenté de proposer un système d authentification unique pour le Web : dans un monde parfait, OpenID aurait été universel et il aurait été inutile de créer OAuth. Toutefois, malgré son succès sur des sites d influence tels que Yahoo et WordPress, l adoption d OpenID ne s est jamais généralisée. Cependant, la complémentarité de ce standard avec OAuth pourrait lui donner une nouvelle chance. En quoi la spécification OAuth 2.0 est-elle différente des précédentes versions? La version 1 d OAuth a évolué très rapidement du fait d une forte demande : OAuth répondait alors à un problème courant et son adoption par les principales applications de réseaux sociaux lui a donné une grande exposition. Actuellement, OAuth est le plus souvent implémenté dans sa version 1.0a, qui intègre une légère modification par rapport à la spécification d origine afin de résoudre une vulnérabilité. Si la spécification 1.0a est bien conçue et assez complète, son champ d application est étroit. C est indéniablement l une de ses forces : elle exerce sa fonction de manière irréprochable. OAuth 1.0 bénéficie d une prise en charge très étendue, avec des bibliothèques disponibles dans la plupart des langues. Cependant, son caractère artisanal, qui séduit généralement les développeurs, plaît moins aux entreprises. OAuth 1.0a affiche également des complexités qui, jusqu à présent, ont empêché une adoption plus généralisée. Il repousse la complexité vers les clients (notamment pour le traitement du chiffrement), rendant le codage difficile avec des langages tels que JavaScript. Par exemple, OAuth 1.0a requiert que les clients signent des paramètres HTTP ; ce qui est une bonne idée pour des transmissions non codées (et un modèle d utilisation courant sur le Web conventionnel), mais moins pour des API. Le processus de signature proprement dit peut prêter à confusion du fait du besoin de normalisation des paramètres (par exemple, séquences d échappement, etc.) : c est une source majeure de frustration pour les développeurs, car les clients et les serveurs de ressources interprètent souvent différemment la façon dont les signatures sont appliquées. Certes, des bibliothèques peuvent les aider, mais le caractère obligatoire de la signature limite la capacité des développeurs à tester les transactions à l aide d une simple ligne de commande telle que curl. Une grande partie de l attrait de RESTful par rapport à d autres alternatives (services Web SOAP, par exemple) réside dans le fait qu il ne nécessite aucun outil de codage spécial. Les signatures OAuth iraient donc à l encontre de cet avantage.

7 Livre blanc : Faciliter l implémentation d OAuth au sein de votre organisation La spécification antérieure présentait également une vision limitée des types de client. Dans le modèle à trois parties, le client était généralement une application Web. Pourtant, les développeurs souhaitaient recourir davantage à OAuth dans des applications s exécutant dans un navigateur ou des applications autonomes s exécutant sur des terminaux mobiles, téléphones ou tablettes. Si cela est possible avec OAuth 1.0, l expérience utilisateur en résultant est très pauvre, car elle peut impliquer des opérations de copier-coller entre le navigateur et l application. La spécification OAuth 2.0 tente de généraliser l implémentation d origine afin de simplifier le développement client, d améliorer l expérience utilisateur globale et d adapter les déploiements. Elle a nécessité d importants changements, qui n étaient pas rétrocompatibles avec les versions antérieures. La nouvelle spécification sépare explicitement les rôles d autorisation et de contrôle des accès. Désormais, le serveur d autorisation est séparé du serveur de ressources. En plus de la séparation des rôles, la nouvelle spécification promeut également l utilisation d un serveur d autorisation central et la distribution de plusieurs serveurs de ressources, à l instar d une architecture d authentification unique (SSO) classique. Un serveur d autorisation OAuth 2.0 est l équivalent RESTful d un service d émission de jetons de sécurité (STS). Figure 3. OAuth 2.0 distingue les serveurs d autorisation des serveurs de ressources et définit les flux décrivant l acquisition du jeton. Acquisition de jeton Client Serveur d autorisation Propriétaire de la ressource Serveur de ressource Utilisation du jeton OAuth 2.0 doit prendre en charge trois profils de client : les applications Web conventionnelles ; les applications basées sur un agent utilisateur (navigateur Web) ; les applications natives (applications mobiles, boîtier décodeur ou même, console de jeu). Chaque type de client peut avoir des fonctionnalités différentes en termes d interaction entre les propriétaires des ressources, les serveurs d autorisation et les ressources protégées. Chacun peut être soumis à différentes exigences de sécurité. La spécification décrit un certain nombre de nouveaux types d accord afin de répondre à la diversité de ces besoins. Les accords décrivent un processus par lequel un client peut acquérir un accès autorisé à une ressource. Ces accords incluent : Code d autorisation : cet accord décrit le scénario traditionnel en trois parties, dans lequel le client est une application Web (Twitter, par exemple). Il utilise un code d autorisation intermédiaire qui permet de déléguer l autorisation de manière sécurisée d un serveur d autorisation à un client via l agent utilisateur du propriétaire de la ressource (le navigateur). Il présente l avantage que les données d identification du propriétaire de la ressource ne sont jamais partagées avec le client, pas plus que le jeton d accès n est partagé avec l agent utilisateur du propriétaire de la ressource (aucun risque de piratage).

8 Livre blanc : Faciliter l implémentation d OAuth au sein de votre organisation Accord implicite : il s agit d un type d accord un peu plus simple, qui convient mieux à des applications s exécutant dans un agent utilisateur, tels que les applications JavaScript. Dans ce scénario, le client acquiert directement un jeton d accès auprès du serveur d autorisation. Cette méthode permet d éliminer en grande partie la complexité liée à l utilisation du code d autorisation intermédiaire, mais présente un inconvénient, celui de donner potentiellement accès au jeton au propriétaire de la ressource. Données d identification du propriétaire de la ressource : dans ce type d accord, le propriétaire de la ressource partage ses données d identification directement avec le client, qui les utilise ensuite pour obtenir un jeton d accès, dans le cadre d une une transaction unique. Les données d identification ne sont pas conservées, car le client utilise le jeton d accès pour les interactions suivantes avec les ressources protégées. Très simple, ce processus exige néanmoins une relation de confiance entre le propriétaire de la ressource et le client. Données d identification du client : dans ce processus, le client utilise ses propres données d identification pour accéder à une ressource. Il utilise alors les droits qui lui sont associés. En plus de ces types d accord, un mécanisme d extensibilité permet de répondre à d autres besoins d autorisation. Par exemple, une spécification de jeton SAML de type porteur permet de décrire l utilisation de jetons SAML en tant que moyen d acquisition de jetons d accès OAuth. Cette spécification est très importante, car elle permet de connecter les infrastructures d authentification unique des navigateurs classiques et les API modernes. Les jetons ont été modifiés dans OAuth 2.0 afin de permettre une meilleure prise en charge de la gestion des sessions. Par le passé, les jetons d accès avaient une durée de vie très longue ( jusqu à un an) voire illimitée (dans le cas de Twitter). OAuth 2.0 introduit le concept de jetons de courte durée et d autorisations de longue durée. Les serveurs d autorisation émettent désormais des jetons d actualisation du client : il s agit de jetons de longue durée qu un client peut utiliser plusieurs fois afin d acquérir des jetons d accès de courte durée. L un des principaux avantages est que le propriétaire de la ressource comme les administrateurs de sécurité peuvent facilement empêcher les clients d acquérir de nouveaux jetons si nécessaire. Les signatures de jeton sont désormais facultatives. La recommandation est d utiliser de simples jetons de type porteur ( jetons secrets utilisés directement pour obtenir l accès) protégés par SSL. Le processus est bien plus simple que celui utilisant des signatures, même si ce dernier persiste sous une forme simplifiée, afin de prendre en charge d autres transactions que SSL. Pourquoi l implémentation est-elle complexe? Si prouver la faisabilité d OAuth, avec des bibliothèques disponibles dans les principales langues pour vous aider à coder manuellement une démonstration de bout en bout, n est pas difficile, son implémentation à l échelle de toute l organisation reste un défi important, selon le volume des transactions, le nombre d API à protéger et le nombre de clients. De plus, OAuth 2.0 est une cible mouvante. La spécification 1.0a avait résolu un problème de manière efficace, mais la portée accrue et la généralisation de la nouvelle spécification ont contribué à générer une ambiguïté considérable qui rend l interopérabilité très complexe. C est pourquoi de nombreuses applications de réseaux sociaux (les premiers à avoir adopté la tendance OAUth) - sont restées à la version 1.0 en attendant une stabilisation. L ouverture des formats de jetons illustre cela : si le processus a contribué à considérablement simplifier le processus de signature, un aspect problématique pour les développeurs dans les spécifications précédentes, il a également introduit la capacité d encapsuler différents jetons (SAML par exemple), offrant de nouvelles opportunités de tirer parti des investissements existants, mais créant en même temps des défis importants en termes d interopérabilité.

9 Livre blanc : Faciliter l implémentation d OAuth au sein de votre organisation La plus grande erreur consisterait à considérer OAuth de manière isolée : bien que séduisant, OAuth n est qu une pièce dans le puzzle du système de contrôle des accès de l entreprise. L autorisation ne peut être dictée entièrement par le client : l entreprise hébergeant la ressource protégée doit également disposer d un moyen de contrôle. Les implémentations OAuth à un seul emplacement tiennent rarement compte de cette bipolarité, alors même qu il est essentiel pour l entreprise que la confiance et le contrôle soient réciproques. Plutôt que d être déployé en tant que solution autonome, OAuth doit s intégrer dans un système général de contrôle d accès aux API de l entreprise basé sur des règles. S il est basé sur des règles, les accès peuvent être contrôlés par les deux parties. Le système inclut des contrôles du type restrictions horaire et des listes d adresses IP autorisées/interdites. Il identifie et neutralise les menaces telles que les attaques par injection SQL ou XSS (Cross-Site Scripting). Il valide le contenu des paramètres et des messages (JSON ou XML inclus) en le comparant à des valeurs acceptables. Il s intègre totalement avec les systèmes d audit de l entreprise, afin de permettre aux fournisseurs de ressources de savoir exactement qui accède à quel contenu et à quel moment. Enfin, un contrôle des accès riche et basé sur des règles autorise une gestion des accords sur les niveaux de service en façonnant les communications réseau, en acheminant les transactions vers les serveurs disponibles et en limitant l excès de trafic avant qu il n affecte l expérience utilisateur ou ne représente une menace pour les serveurs. L entreprise n envisagerait jamais de créer sa propre infrastructure de gestion des identités et des accès pour son site Web : les architectes et développeurs reconnaissent qu une telle opération implique bien plus qu une simple authentification HTTP de base. Il en va de même pour OAuth, dont l aspect, simple en apparence, dissimule un processus d autorisation global extrêmement complexe. Comment CA Layer 7 peut-il m aider à implémenter OAuth? CA Layer 7 fournit une solution clés en main complète pour des implémentations OAuth 1.0a et OAuth 2.0. OAuth est inclus dans le moteur de contrôle des accès basé sur les règles des solutions API Proxy, SOA Gateway et Mobile Access Gateway de CA Layer 7. CA Layer 7 vous permet de déployer OAuth à l échelle de votre entreprise : le cas échéant, une seule instance de passerelle permet de traiter des dizaines de milliers de transactions à la seconde. Ces solutions peuvent être déployées en tant qu appliances matérielles ou images virtualisées (économiques). Les deux types de solution disponibles permettent de déployer une infrastructure de sécurité de qualité militaire à la norme OAuth d entreprise, combinant des modules cryptographiques certifiés FIPS, une détection des menaces avancées, une gestion du trafic conforme aux SLA et un contrôle des accès affiné, le tout au sein d un seul package. C est comme si au lieu d un simple verrou, vous aviez un garde devant votre porte. Les solutions de passerelle de CA Layer 7 peuvent être déployées en temps que serveurs d autorisation (authorization servers, AS) et serveurs de ressources protégées (resource servers, RS). Ces deux éléments peuvent être fusionnés en une seule instance de passerelle ou être séparés, dans une configuration incluant un serveur d autorisation centralisé desservant un grand nombre d instances de serveur de ressources distribuées (comme dans la figure 4). Les solutions de passerelle sont proposées dans des formats matériels et d appliances virtuelles, offrant l éventail de déploiements le plus étendu. Les solutions matérielles sont disponibles avec des modules de sécurité matérielle embarqués (hardware security modules, HSM), pour offrir une protection-clé nécessaire dans les environnements les plus sécurisés. Les appliances virtuelles facilitent le déploiement et peuvent s exécuter partout, que ce soit sur le bureau ou une puissante infrastructure de serveurs.

10 Livre blanc : Faciliter l implémentation d OAuth au sein de votre organisation Figure 4. Les solutions de passerelle de CA Layer 7 facilitent l implémentation d OAuth. Propriétaire de la ressource (soit l utilisateur) Client Serveur d autorisation Les fonctions de serveur d autorisation et de serveur de ressource peuvent être combinées sur une seule passerelle ou distribuées sur le réseau Serveur de ressource Réseau d entreprise Quel est l avantage d OAuth Toolkit? La solution OAuth Toolkit de CA Layer 7 utilise des modèles standardisés et immédiatement prêts à l emploi, pour un déploiement standard d OAuth. Sur la base de ces modèles, les clients peuvent ajouter de puissantes fonctionnalités OAuth à des API existantes en quelques minutes au lieu de plusieurs jours. Il convient de reconnaître que la solution «universelle» promise par tant de fournisseurs fonctionne rarement parfaitement. Ainsi, dans la plupart des projets du monde réel, les organisations possèdent déjà des systèmes de gestion des identités auxquels elles doivent accéder ou des infrastructures à clé publique (PKI) qu elles doivent intégrer. Si nous excellons dans l intégration de données et d applications, l intégration de la sécurité reste un défi constant pour notre secteur. Afin de mieux répondre aux défis d intégration, CA Layer 7 propose également des composants OAuth de base, autant pour le chiffrement que pour la normalisation des paramètres, en passant par la gestion des sessions. Ces composants de base, utilisés dans notre solution clé en main complète, sont proposés sous forme d assertions entièrement configurables au sein d une règle de contrôle d accès. Ils permettent aux architectes et développeurs d affiner leurs implémentations OAuth afin de répondre à quasiment tous les défis possibles. L ouverture des modèles de CA Layer 7, ainsi que la puissance d un kit d outils flexible et ouvert offrent de nombreux atouts dans le contexte de la personnalisation du processus d autorisation OAuth. L établissement de la confiance initiale joue un rôle critique dans l ensemble du processus OAuth. CA Layer 7 vous permet de personnaliser entièrement cette étape afin de garantir l intégration avec l infrastructure de gestion des identités et les exigences de l entreprise en matière de conformité.

11 Livre blanc : Faciliter l implémentation d OAuth au sein de votre organisation Comment CA Layer 7 peut-il m aider dans le cadre d une authentification OAuth à deux ou trois parties? Les solutions de passerelle de CA Layer 7 peuvent fournir des services d autorisation pour des points de terminaison et un contrôle d accès pour des services protégés. Ces deux fonctions peuvent coexister au sein d une seule instance de passerelle ou être séparées. Une telle séparation favorisera l évolutivité, la redondance et la distribution géographique des services. Elle permet également une harmonisation au niveau métier, notamment en séparant les API publiques de celles de l entreprise au moyen de partitions. La plupart des organisations ont un grand nombre d API à protéger, souvent desservies par un nombre important d emplacements. Dans ces cas, il est judicieux de déployer des solutions de passerelle centralisées en tant que serveurs d autorisation (souvent en clusters afin d assurer la redondance) et des clusters distants de passerelles afin de protéger des instances d API spécifiques. Figure 5. Exemple de déploiement type dans le cadre d un scénario classique à deux parties d autorisation basée sur l identification du propriétaire des ressources et du client. Les deux schémas de déploiement peuvent être utilisés simultanément pour des implémentations OAuth 1.0a et 2.0. Ce schéma fonctionne également pour des scénarios à deux et trois parties, ainsi que pour le modèle d autorisation OAuth 2.0, y compris dans le cadre d autorisations utilisant un jeton SAML de type porteur. Ces déploiements sont illustrés dans les figures 5 et 6. Déploiement sur 2 piliers de CA Layer 7 Pare-feu 1 Pare-feu 2 Serveur d autorisation Infrastructure d identité Propriétaire de la ressource Clients Équilibreur de charge Serveur de ressource Serveur de ressource protégé (API sécurisées) Figure 6. Scénario de déploiement type à trois parties avec autorisation via un code d autorisation et autorisation implicite. Les solutions de passerelle de CA Layer 7 peuvent prendre en charge simultanément toutes les versions d OAuth, ainsi que des mappages personnalisés afin de résoudre les problèmes d interopérabilité. Propriétaire de la ressource Client Déploiement sur 3 piliers de CA Layer 7 Pare-feu 1 Pare-feu 2 Serveur d autorisation Équilibreur de charge Serveur de ressource Serveur de ressource protégé (API sécurisées) Infrastructure d identité

12 Livre blanc : Faciliter l implémentation d OAuth au sein de votre organisation Contactez CA Technologies CA Technologies se fera un plaisir de répondre à vos questions, commentaires et remarques générales. Pour plus d informations, veuillez contacter votre responsable de compte CA Technologies ou visiter le site www./security Restez connecté à CA Technologies sur Agility Made Possible : l avantage de CA Technologies CA Technologies (NASDAQ : CA) fournit des solutions de gestion des systèmes d information qui aident les clients à gérer et à sécuriser des environnements informatiques complexes pour supporter des services métier agiles. Les organisations s appuient sur les logiciels et les solutions SaaS de CA Technologies pour accélérer l innovation, transformer leur infrastructure et sécuriser les données et les identités, du cœur des data centers jusqu au Cloud. CA Technologies s engage à ce que ses clients atteignent les résultats souhaités et la valeur métier attendue grâce à l utilisation de sa technologie. Pour en savoir plus sur nos programmes de succès clients, visitez le site www./customer-success. Pour plus d informations sur CA Technologies, rendez-vous sur le site www.. Copyright 2014 par CA Layer 7, une société CA Technologies. Document confidentiel. Tous droits réservés.