Cwin16 - Paris - fédération d'identités

For internal use only
La Fédération d’identités
Un passeport obligatoire pour l’ouverture du SI
de l’entreprise à son écosystème
Paris, 26/09/2016, Ali Bekkali & André Follic

Presentation Title | Date
Copyright © 2016 Capgemini and Sogeti – Internal use only. All rights reserved. 2
Contacts
André FOLLIC
Directeur de projets, Architecte d’Entreprise
andre.follic@capgemini.com
Capgemini CSD
Atalante Champs Blancs
7, rue Claude Chappe
35577 Cesson Sevigne
Mobile: +33 (0) 6 82 91 93 66
Ali BEKKALI
Porteur offre Cybersécurité
ali.bekkali@capgemini.com
Capgemini CSD
Atalante Champs Blancs
7, rue Claude Chappe
35577 Cesson Sevigne
Mobile: +33 (0) 6 88 63 83 45

Fédération d’identités 26/09/2016
Sommaire
 Objectifs de la présentation
 Positionnement de la Fédération des
identités dans la cybersécurité
 Enjeux de la gestion d’identités
 Démarche projet
 Enjeux de la Fédération d’identités
 Solutions
 Questions / Réponses

Fédération d’identités | 26/09/2016
Objectifs de la présentation: répondre à ces questions
 Gestion d’identités, Why ?
 Fédération d’identités, Why ?
 Quelles sont les nouvelles normes et les nouveaux protocoles en
Fédération d’identité ?
 Quels sont les liens avec l’API Management ?
 Quelles sont les limites ?
 Comment construit-on un projet de Fédération d’identités ?
 Quels sont les prérequis ?
 Quelle gouvernance doit-on mettre en place pour un projet de
Fédérations d’identités ?

Positionnement de la Fédération des identités dans le domaine de la
Cybersécurité: Transverse
Sécurité du Cloud
Analyse des risques, accompagnement pour la définition des services de sécurité
et pour le déploiement d’une architecture robuste de sécurité
IAM étendu
SSO, fédération des identités, gestion des droits et des profils, provisionning, workflow, référentiels des
identités, self-services, annuaire entreprise, etc.
Sécurité dans la mobilité
Analyse de risques et stratégie mobile, sécurisation des architectures mobiles, durcissement de socles
techniques, règles d’ingénierie développement mobile, audit statique de sécurité
 Sécurité des développements
 Gestion des identités - IAM
 Services de confiance/PKI
 Frameworks de sécurité
 Sécurisation de la mobilité
 Sécurité du Cloud Computing
 Audits techniques de la SSI
 Architecture Entreprise SSI
 Modèles d’architectures SSI
 Architecture logicielle SSI
 Architecture technique SSI
 Audits d’architecture SSI
 Gestion des risques IT
 Pilotage sécurité des SI
 Conseil
 Référentiel documentaire
 Audits de conformité
 Formation & sensibilisation
Gouvernance SSI Architecture SSI Expertise SSI

Gestion des identités et des accès
IAM - Contexte et Enjeux (1/2)
 IAM : Identity & Access Management
• Consiste à gérer le cycle de vie des personnes
au sein du système d’information, pourquoi ?
 Tendances
• De nombreux systèmes hétérogènes
• Multiplication des référentiels d’identité souvent
incompatibles (SGBD, annuaires, fichiers à plats)
 Conséquences
• Pour l’utilisateur : de nombreux identifiants et
mots de passe à mémoriser
• Pour l’administrateur : traitement manuel de
nombreux référentiels via des outils spécifiques
• Niveau de sécurité du SI incertain : « Qui a accès
à quoi ? »

IAM - Contexte et Enjeux (2/2)
Fonctions
Convergence
& Simplicité
Sécurité
TCO *
Audit &
conformité
Historique des
opérations sur
les droits et
des accès aux
ressources
Assurance que
la politique de
sécurité est
respectée
Self-service
Possibilité pour
les utilisateurs
d’effectuer eux-
mêmes
certaines
tâches sans
recourir au
helpdesk
Gestion
Centralisée de
l’identité
Mécanisme
automatisé et
centralisé de
gestion des
identités et
d’attribution
des droits
SSO
Une seule
saisie du login
et du mot de
passe pour
accéder à un
ensemble de
services
Fédération des
identités
*Total Cost of Ownership
Coût du processus Global
Enjeux
Homogénéiser les profils
avec les politiques d’accès
Fidéliser les utilisateurs par
un plus grand confort
d’utilisation
Contrôler l’accès aux
données et aux
applications
Conserver la trace des
opérations
Réduire les coûts de
gestion des utilisateurs,
de helpdesk et de
développement des
applications
 3 Objectifs principaux

IAM - Deux briques essentielles
The right Identity The right access rights The right resources The right context
Le contrôle de l’identité est nécessaire pour le contrôle des risques et des couts
Identity & Access Governance Access Management

Les besoins de l’Entreprise
• Créer le schéma détaillé de l'organisation de l'entreprise
• Référencer et définir la "carte d’identité" des éléments
• Définir la cartographie des éléments entre eux
• Agréger et consolider les informations d'identité dans un
référentiel unique
• Synchroniser les informations d'identité entre les référentiels
• Gérer les règles d’autorité sur chaque info d'identité
• Détecter & propager les modifications entre référentiels
• Gérer l’intégrité des informations entre les référentiels
• Gérer les informations d'identité
• Offrir un point d’accès et d’administration unique
• Disposer d'une vue unifiée des droits et habilitation

Processus de gestion des identités et des habilitations
 La gestion des identités et des habilitions des utilisateurs doit s’inscrire
dans un processus couvrant les différentes étapes du cycle de vie des
utilisateurs au sein de l’entreprise
Entrée
Initialisation
 Création de
l’identité
 Ouverture du
compte (mail,
système)
 Définition des
droits d’accès et
habilitations
Business Process
Exercice des fonctions Sortie
Révocation
 Archivage de
l’identité
 Redirection de
courrier
 Suppression des
comptes
 Révocation des
droits d’accès et
habilitations
Accès à la
ressource
Présentation
Authentification
Contrôle d’accès
Modification
 Changement droits
accès
 Modification données
personnelles ou
contractuellesPersonnalisation

Profils métiers et rôles applicatifs
Permissions
Droits
Profil Métier
Profil Métier
Rôle Applicatif
Utilisateur 1
Utilisateur 2
Rôle Applicatif
Rôle Applicatif
Permissions
Droits
Administration fonctionnelle
Administration technique
Permissions
Droits
Permissions
Droits
Profil de référence par métier et
regroupant un ensemble de rôles
applicatifs nécessaires à l’exercice
de l’activité professionnelle
correspondante
Ensemble de permissions
(accès à une fonction ou une
opération) pour une application
ou un service

 Démarche globale d’un projet IAM en lien avec l’urbanisation du SI
et l’architecture d’Entreprise (TOGAF)
Légende:
= Phase du projet
= Atelier facilitation
6 = Étape
Phase 2 – Mise en oeuvre
Spécifications détaillées6
•Résolution
Planification
détaillée
8
9 Déploiement
(Site pilote et autres)
Pilotage du projet
Conduite du changement
Phase 1 – Étude du besoin, cadrage
Catégorisation des
acteurs
1
Stratégie et
planification
5
2 Classification de
l’information
3 Procédures de
gestion des
autorisations
4
Maquette
(Proof Of Concept)
}} Réalisation d’un prototype7
Phase0–Pré-cadrage–Etuded’opportunité

Sujets à traiter
Centralized
Identity Store
Self
service
Role
management
Compliance
reporting Automated
provisioning
Identity
lifecycle
Policy
management
Authorization
lifecycle
Risk
managementSecurity
User
experience
Review
attestation
Single
Sign On
Access
management
Federation
Privileged
accounts

Fédération des identités
Tendances Globales….s’inscrivant dans le cadre de l’ouverture des SI
Cloud
Apps
Private
Apps
Company
ManagedDevice
Enterprise applications
People Devices Network Apps Data
UnManaged
Device
Identity
Provider
Federation
Server
Access
Manager
IAM
Policies
Access
Management
employees
Consultants
Contractors
3rd Parties
Customers
 Tendance actuelle « IAM Dynamique » : Un utilisateur doit pouvoir accéder à
n’importe quelle donnée, depuis n’importe quel terminal, en passant par n’importe quel
réseau, via n’importe quelle application
 Gestion de bout en bout du cycle de vie de l’identité numérique
 Authentification basée sur les risques : utilisateur, service, horaire, adresse IP, appareil, etc.
 Autorisation contextuelle : gestion fine de l’accès aux ressources de l’entreprise
 Une fédération accrue des identités

Contexte et Enjeux
Fédération d’identité
 Etablissement d’une relation de confiance entre deux entités/organismes
 Interconnecter les systèmes d'informations
 Offrir une interopérabilité entre systèmes de gestion des identités et
des accès
 Accroitre le niveau de sécurité

Contexte et Enjeux
Fédération – Apports Fonctionnels
 Transmettre l’identité de façon
sécurisée
 Mécanismes de signature et de
chiffrement électronique
 S’appuie sur des standards pour
le transfert d’information
 Permet à l’utilisateur de ne
s’authentifier qu’une fois
 Pas de transmission de mot de
passe : sécurité accrue
 Expérience utilisateur améliorée
Fédération – Composants
 Fournisseur d’identité :IDP
 Garant de l’identité des users
 Respect de la Politique Secu
 Fournisseur de service : SP
 Protège d’accès aux ressources
 Vérifie l’identité
 Transmet l’identité au service
 Cercle de confiance :
 Définition d’un contrat d’attributs
 Échanges sécurisées

Protocoles mis en œuvre
 Nombreux standards de fédération
d’identités existants
 Normalisation des échanges d’identité
entre
fournisseurs d’identité et fournisseurs
de services
 Choix du protocole adapté en fonction
des différences
dans l’implémentation
Fournisseur d’identité
Serveur
d’authentification
Référentiel des
utilisateurs
Fournisseur de services
Ressources
Agent SSO
Utilisateur
Validation
du jeton
Obtention d’un jeton
Présentation du jeton
3
1
2

La Fédération d’Identité peut s’effectuer via plusieurs protocoles
Protocoles de fédération
SAML
1.0
SAML
1.x
SAML
2.0
WS-Federation
1.0
WS-Federation
1.1
OpenID Connect
REST/JSON
SOAP
SOAP
WS-Federation
1.2

Protocoles mis en œuvre – SAML V2
 SAML (pour Security Assertion
Markup Language)
 est un standard développé par OASIS
définissant un protocole pour échanger
des informations liées à la sécurité.
 La structure des assertions
 Les protocoles permettant l’échange
d’assertion et la gestion des sessions
 L’intégration des protocoles avec les
protocoles de transport SOAP et
HTTP
 Le format des messages basé sur
XML
 SAML - La sécurisation des échanges
 Signature électronique des messages
(XML-Signature) pour l’intégrité
 Le chiffrement des messages
(XML-Encryption) pour la confidentialité
 Support des certificats X.509
1
Requêted’accès
Validation de
l’assertion SAML
3
Ressource
Identity ProviderService Provider
Cercle de confiance
4
6
2
4 2
5

Protocoles mis en œuvre – SAML V2
SP-Initiated SSO
6
2
5
1
Validation de
l’Assertion
SAML
Circle Of Trust
Identity Provider
Service Provider
Ressources
3
4
Service d’authentification

Protocoles mis en œuvre – WS-FEDERATION
« […]spécification qui définit des
mécanismes de fédération d'espaces de
confiance hétérogènes. Elle offre la
possibilité de fédérer des domaines de
sécurité et permet d'établir des
contextes de sécurité entre des
applications utilisant des spécifications de
sécurité distinctes. »
S’appuie sur les spécifications WS-
Security, WS-Policy et WS-
SecureConversation.
Effectue l'authentification mutuelle
d'applications utilisant des approches de
sécurité hétérogènes, comme les
mécanismes d'authentification Kerberos.
6
2
4
1
Authentifie
l’utilisateuret
donnel’accès
CircleOfTrust
Identityprovider
ServiceProvider
Ressources
3
Serviced’authentification
STS:SecurityTokenService

Protocoles mis en œuvre – OpenID Connect
OpenID Connect
 Surcouche d’authentification au protocole OAuth2, permettant à l’application Cliente, ici appelée
Relying Party (RP), de vérifier l’identité de l’utilisateur final, a partir de l’authentification effectuée
par OpenID Provider (OP)
 L’OpenID Provider regroupe à la fois les rôles d’Authorization Server (AS) et de Resource Server
(RS) d’OAuth2
 En plus de l’Access Token et du Refresh Token, l’AS fournit au RP un ID Token, contenant
principalement un subject_id associé à l’utilisateur final auquel appartiennent les données qu’on
cherche à obtenir.
 Le subject_id de l’utilisateur et le issuer_id de l’OP peuvent être utilisés pour identifier de façon
unique le compte de l’utilisateur au niveau du RP
 Cet ID Token est signé avec la clé privée de l’OP, afin que le RP puisse valider l’authenticité de
ce token.

Protocoles mis en œuvre – OpenID Connect
1
Requêted’accès
3
Ressource
4
2
4
2
Access Token
Authentication
Redirect for Authentication
10
Relying Party
Authorization
Server
End User
Relying Party Resource Server
Mobile application Host protected
ressource
End User AuthorzisationServer
Application user Manage authentication
and OIDC Token
OpenID Connect, utilisé pour l’authentification des utilisateurs

Protocoles mis en œuvre – OAUTH
OAuth2
 Gestion des autoisations inter-applicatives
 Des spécifications pour définir :
 La structure des différents jetons
 Les protocoles permettant l’échange
de jetons et la gestion des sessions
 L’intégration des protocoles avec les
protocoles de transport SOAP et HTTP
 Des cas d’utilisation standard jetons
 La sécurisation des échanges
 Validation des jetons directement auprès de
l’entité les ayant délivré
 Echange de jetons directement entre
l’application cliente et le serveur d’autorisation
 Jetons avec une courte durée de vie
1
Requêted’accès 3
Ressource
Authorization
Server
Client App
4
2
4
2
Code d’autorisation
Authentification
Redirection pour
authentification
Ressource
Server
Ressource
Requête
(Access Token)
7
9
Validation
Access Token
8
10

Protocoles mis en œuvre – OAUTH
OAuth2
 Quatre entités intervenant
 Propriétaire des ressources (RO), utilisant l’application cliente
 Serveur d’autorisation (AS), contrôlant l’accès aux ressources
 L’application Cliente, souhaitant accéder aux ressources
 Le serveur de ressources (RS), où sont stockées les ressources
 Protocole d’autorisation et de pseudo-authentification
 Le propriétaire d’une ressource sécurisée par un serveur d’autorisation
(ex : informations d’identité) donne son accord à une application tierce pour y accéder
 L’application a alors accès aux ressources de l’utilisateur
sans qu’il ne partage ses identifiants
 Processus non autoporteur
 L’authenticité des jetons est vérifiée par le serveur de ressource directement auprès du
serveur d’autorisation, sans passer par l’utilisateur final

API Management
Partenaires Utilisateurs MobilePortail
Portail
Système d’information

Presentation Title | Date
API Management, un périmètre sécurité étendu : OAuth2 et OpenID
Connect
API
API Consumer
API Gateway
Security
API API
API Consumer
Authentication
Authorization
WAF
Throttling
Quotas
DDOS Protection
Patch Deployment
API Security

API Management
Régimes Utilisateurs MobilePortail PCI
API Manager
(Authorization server)
API Manager
(Resource server)
Identity
Provider
 Les APIs peuvent être protégés en
utilisant les protocoles de fédération
et via les APIs Managers
 Les APIs Managers contiennent
un composant Authorization Server
qui permet de valider l’assertion
SAML et généré un jeton OAUTH
 Le jeton OAUTH sera utilisé par
l’application pour accéder à la
ressource demandée.
 Dans le cas d’OpenID Connect le
composant authorization server
valide le token OAUTH via l’identity
provider et génère un jeton OAUTH
pour accéder à la ressource

Authentification via France Connect
Accès à Mon Espace Personnel Login Avec un Fournisseur Externe

Authentification via France Connect

Démarche projet
Perspective
Où sommes-nous actuellement?
Comprendre les processus, la
technologie et les environnements
Notre cible ?
Comprendre les facteurs opérationnels
et cas d'affaires de haut niveau
Comment pouvons-nous y arriver?
Prioriser les activités critiques
VISION
Comment les données d'identité sont
stockées et utilisées (de haut niveau)
Inventaires des Processus et Systèmes
Contrôles d'accès
Inventaire des données d’identité
Vision Document IAM
Définir les objectifs stratégiques, les besoins
et la cible pour un IAM efficace
Établir la gouvernance
Approuver la vision à travers l'organisation et
établir la propriété
Business case
Coûts et avantages
Charte Programme IAM
Projection Feuille de route et Organisation
Politiques & Standars
Politiques
Tenez Politiques d'identité seuls
dans tous les domaines d'identité
Normes
Définir les normes qui seront
utilisées (cadre d'interopérabilité)
COMMUNICATE
La revue
accord d'audience
Communiquer
Communiquer au plus large
public
Vérification
Niveau d'acceptation de la
politique
Architecture
Comment les données d'identité sont créées,
stockées et utilisées
Refonte des processus
Revue des Rôles modèles, contrôles d'accès
Définir les systèmes et composants
technologiques nécessaires
Base pour l'évaluation des produits
Comment les systèmes doivent être construits
architecture de référence IAM
IMPLEMENTATION
Exigences fonctionnelles
Design Haut niveau
Evaluation de produits
Detailed Design
Design détaillé
Développement
Tests
Déploiement
Fonctionnement

Solutions On-Premise
 Microsoft ADFS
 Shibboleth
 Ping Federate (Ping Identity)
 NetIQ Access Manager
 Entrust GetAccess (Entrust)
 iWelcome
 OpenAM (ForgeRock)

Solutions IDaaS

Questions / Réponses

www.capgemini.com
The information contained in this presentation is proprietary and confidential.
It is for Capgemini and Sogeti internal use only. Copyright © 2016 Capgemini and Sogeti. All rights reserved.
Rightshore® is a trademark belonging to Capgemini.
No part of this document may be modified, deleted or expanded by any process or means without prior written permission from Capgemini.
www.sogeti.com
About Capgemini and Sogeti
With more than 180,000 people in over 40 countries, Capgemini is a
global leader in consulting, technology and outsourcing services. The
Group reported 2015 global revenues of EUR 11.9 billion. Together
with its clients, Capgemini creates and delivers business, technology
and digital solutions that fit their needs, enabling them to achieve
innovation and competitiveness. A deeply multicultural organization,
Capgemini has developed its own way of working, the Collaborative
Business Experience™, and draws on Rightshore®, its worldwide
delivery model.
Sogeti is a leading provider of technology and software testing,
specializing in Application, Infrastructure and Engineering
Services. Sogeti offers cutting-edge solutions around Testing,
Business Intelligence & Analytics, Mobile, Cloud and Cyber
Security. Sogeti brings together more than 23,000 professionals in
15 countries and has a strong local presence in over 100 locations
in Europe, USA and India. Sogeti is a wholly-owned subsidiary of
Cap Gemini S.A., listed on the Paris Stock Exchange.

Cwin16 - Paris - fédération d'identités

Contenu connexe

Tendances

En vedette

Similaire à Cwin16 - Paris - fédération d'identités

Plus de Capgemini

Cwin16 - Paris - fédération d'identités