Concepts fondamentaux
Chapitre 7 : Applications
Paru le 11 mai 2004 | Dernière mise à jour le 26 juin 2006
Les applications jouent un rôle important dans la stratégie de gestion des identités et des accès. Les applications utilisent des données d'identité à des fins d'autorisation et d'évaluation des droits qui permettent d'accéder aux ressources. Lors du choix ou du développement des applications, il est essentiel de s'assurer que les applications s'adaptent à l'environnement de gestion des identités et des accès.
En général, on trouve deux types d'applications :
Des applications tierces, commerciales ou prêtes à l'emploi comme Microsoft® Exchange Server 2003.
Des applications personnalisées ou internes à l'entreprise développées pour l'organisation par des développeurs.
Qu'elle ait été achetée ou développée, une application doit être intégrée efficacement dans l'environnement de gestion des identités et des accès de l'organisation. Toutefois, plusieurs critères sont impliqués, en fonction du type d'application que vous essayez d'intégrer.
La difficulté d'intégration d'une application à la plate-forme de gestion des identités et des accès dépend de l'architecture de l'application et des mécanismes qu'elle utilise pour identifier ses utilisateurs. Microsoft recommande d'identifier vos applications, en les classant et en vérifiant leurs dépendances de fonctionnalité et d'infrastructure. Si une application n'est pas compatible avec votre plate-forme de gestion des identités et des accès, vous devez modifier votre application ou votre infrastructure.
Remarque : Le point important du point de vue du développement est que les applications ne doivent pas créer ni implémenter leurs propres stockages d'identités, les protocoles de sécurité (pour l'authentification, l'autorisation et l'audit) ou les mécanismes de protection de données.
Les sections suivantes de ce chapitre présentent les méthodes d'intégration des applications avec la plate-forme Microsoft de gestion des identités et des accès. Elles contiennent également une description détaillées des techniques concernant les applications de développement, de test et de déploiement sensibles à l'identification. Le document « Développement d'applications sensibles à l'identification » du kit détaille les applications que les architectes et les développeurs doivent créer pour intégrer les applications dans l'infrastructure.
Sur cette page
Choix des applications
Développement d'applications
Choix des applications
Lors du choix d'une application, les responsables informatiques souhaitent souvent s'assurer que l'application peut fournir la fonctionnalité requise. Malheureusement, la méthode d'intégration de l'application dans le réseau est souvent négligée, en particulier la gestion des identités.
Les applications tierces peuvent identifier les utilisateurs par :
une intégration au service d'annuaire principal de l'organisation ;
une connexion normalisée au service d'annuaire principal ;
une authentification à un autre service d'annuaire.
une utilisation d'un stockage d'identité dédié.
Exchange Server 2003 est l'exemple même d'une application qui s'intègre complètement à un service d'annuaire. Exchange étend le schéma su service d'annuaire Microsoft Active Directory®, puis ajoute les attributs de boîte aux lettres à des comptes d'utilisateur dans Active Directory. Contrairement à Exchange 5.5, Exchange 2000 Server et Exchange Server 2003 ne tiennent à jour aucune base de données d'annuaires séparée. L'intégration complète à un service d'annuaire est le moyen le plus facile d'implémenter la gestion des identités de l'application.
Certaines applications ne s'intègrent pas complètement à un service d'annuaire, mais peuvent authentifier des utilisateurs à un annuaire à l'aide des connexions normalisées. L'exemple type serait une application pouvant utiliser le protocole d'authentification Kerberos version 5 pour s'authentifier à Active Directory, comme SAP R/3 qui fait partie de l'environnement fictif de Contoso utilisé dans d'autres document de ce kit.
Les applications peuvent être authentifiées à un service d'annuaire qui n'est pas l'annuaire principal de l'organisation. Cette situation n'est pas idéale, étant donné que vous devrez désormais synchroniser votre annuaire principal et l'annuaire que l'application utilise. Un produit de méta-annuaire comme Microsoft Identity Integration Server 2003, Enterprise Edition (MIIS 2003 SP1) peut assurer cette synchronisation par l'intermédiaire d'agents de gestion qui se connectent aux stockages d'identité les plus courants.
L'arrangement le mieux adapté est lorsque l'application dispose d'un stockage d'identité propriétaire dédié et qu'il n'y a aucun outil disponible pour importer/exporter les données d'identité dans/vers un format pris en charge par MIIS 2003 SP1. Dans ce cas particulier, il n'est pas forcément possible d'utiliser MIIS 2003 SP1 pour synchroniser le stockage d'identité d'application au service d'annuaire principal, ainsi la conservation des identités dans le stockage d'identité de l'application devient un processus manuel, onéreux et sujet aux erreurs.
Développement d'applications
Pour développer des applications en interne, il existe trois méthodes fondamentales que les architectes et les développeurs d'application doivent prendre en compte :
Intégration de l'application. Choix entre intégrer l'infrastructure ou interopérer avec elle.
Flux des identités. Choix d'une combinaison appropriée des trois modèles fondamentaux pour l'authentification frontale et dorsale.
Autorisation. Choix d'une combinaison des deux modèles fondamentaux pour l'autorisation.
Les choix possibles pour ces trois domaines ont une influence sur les applications que les développeurs doivent mettre en œuvre pour l'authentification, l'autorisation et l'audit. Dans une application bien intégrée, quasiment aucun code sensible à l'identification ne doit être mis en œuvre, étant donné que l'infrastructure sous-jacente effectue tout le travail.
L'intégration de l'application englobe les facteurs déjà abordés dans la section précédente intitulée « Choix des applications ».
Activation du flux d'identités
Il existe trois modèles différents pour le flux de données d'identité de l'utilisateur authentifié dans les environnements distribués, appelé également flux d'identité. A savoir :
Usurpation d'identité/délégation
Sous-système de confiance
Mappage des informations d'identification
Utilisation du modèle d'usurpation d'identité/délégation
L'usurpation d'identité permet à un processus de serveur de s'exécuter en utilisant les informations d'identification de sécurité du client. En usurpant l'identité du client, le serveur effectue toutes ses opérations en utilisant les informations d'identification du client. Cependant, l'usurpation d'identité ne permet pas au serveur d'accéder aux ressources distantes à la place du client ; ce type d'accès exige une délégation. La délégation est plus puissante et permet à un processus de serveur de passer des appels à d'autres ordinateurs en agissant sous le nom du client.
Utilisation du modèle de sous-système de confiance
Avec ce modèle, ce service de niveau intermédiaire utilise une identité fixe pour accéder aux services et aux ressources en aval. Le contexte de sécurité de l'appelant d'origine ne passe pas par l'intermédiaire du service au niveau du système d'exploitation, bien que l'application puisse choisir de passer l'identité de l'appelant original au niveau de l'application. Cela peut être nécessaire pour prendre en charge les exigences d'audit principal ou l'accès et l'autorisation aux données par utilisateur.
Le nom du modèle provient du fait que le service en aval (peut-être une base de données) donne son approbation au service en amont pour autoriser les appelants.
Utilisation du modèle de mappage d'informations d'identification
Le modèle de mappage d'informations d'identification aligne deux ensembles d'informations d'identification dans une table de mappage. Les informations d'identification mappées peuvent alors être utilisées pour créer une connexion à un autre système. Il existe deux types de modèles de mappage d'informations d'identification : le premier utilise les informations d'identification directes et le second utilise des « tickets » de mappage indirect qui sont échangés ultérieurement contre des informations d'identification. Vous pouvez utiliser le modèle de mappage des informations d'identification si le système cible ne prend pas en charge le protocole d'authentification Kerberos version 5 ou n'utilise pas Active Directory comme stockage d'identité.
Mise en œuvre de l'autorisation
Lorsque votre application a identifié l'utilisateur, elle doit être en mesure de contrôler l'accès de cet utilisateur en utilisant l'autorisation. Les deux modèles d'autorisation d'application sont :
Liste de contrôle d'accès (ACL)
Contrôle d'accès basé sur des rôles (RBAC)
Utilisation du modèle ACL
Le modèle ACL implique la sécurisation d'une ressource (comme un fichier, un dossier, une imprimante ou un objet du service d'annuaire) associant une ACL, c'est-à-dire une liste des utilisateurs et des groupes, à des permissions (autorisation et refus) pour chaque utilisateur ou groupe. Lorsqu'un utilisateur demande l'accès à une ressource, les permissions d'accès de l'utilisateur sont évaluées avec les permissions d'accès de tous les groupes auxquels l'utilisateur appartient. L'utilisateur se voit donc accorder ou refuser l'accès en fonction de ces permissions d'accès.
Le modèle ACL fonctionne correctement avec des objets persistants bien définis, mais pas dans certains environnement tels que les applications métier ou les applications Web. Le traitement de ces types d'applications, des applications de workflow et d'objets temporaires nécessite un modèle différent.
Utilisation du contrôle d'accès basé sur des rôles (RBAC)
Le RBAC utilise le concept de rôles. En général, un rôle correspond à un membre de l'entreprise, comme « responsable », « guichetier » ou « directeur commercial ». Le RBAC mappe ces rôles à des permissions d'application de manière à ce que l'administration du contrôle d'accès puisse être réalisée par rôle d'utilisateur.
Le RBAC transfert alors l'appartenance à un rôle vers des permissions d'application. Étant donné que les permissions sont accordées au niveau du rôle, elles peuvent être demandées ou modifiées pour le rôle sans examen des ressources spécifiques.
Lorsque les administrateurs créent les rôles et attribuent les permissions à ces rôles, il ne devrait pas être nécessaire de modifier les rôles ou les permissions. Les seules modifications consisteront à attribuer des rôles à des utilisateurs (ou groupes).
Le document « Développement d'applications ASP.NET sensibles à l'identification » du kit détaille les applications que les architectes et les développeurs doivent créer pour intégrer des applications dans l'infrastructure.
Télécharger
Téléchargez le kit Microsoft de gestion des identités et des accès
Notifications de mise à jour
Abonnez-vous aux mises à jour et aux nouvelles versions
Commentaires