Lors de la mise en œuvre d'une solution de fédération ou du remplacement d'une solution existante, examinons comment "penser le problème différemment" peut améliorer les choses.
Un client actuel dispose d'une plateforme de SSO et de fédération relativement complexe. Il s'agit d'une implémentation Siteminder à laquelle ont été ajoutés les composants de fédération CA. Bien que la solution fonctionne, le client souhaite éliminer les coûts de licence et simplifier son infrastructure. Nous mettons en œuvre AD FS pour eux afin de servir de moteur de fédération. Les objectifs à plus long terme comprennent la migration de l'ensemble des applications SSO vers SAML 2.0, et les applications seront sensibles aux réclamations dans la mesure du possible. Si ce n'est pas possible, certaines applications pourront être converties à Kerberos ou à l'authentification intégrée de Windows.
Une partie de ma philosophie architecturale est axée sur la simplification. La simplicité, lorsqu'elle est mise en œuvre à bon escient, est plus stable et plus fiable, plus facile à prendre en charge et (devrait être) plus facile à comprendre.
Bien que l'architecture Siteminder en place présente des avantages et des points forts indéniables, le client n'exploitait pas l'ensemble des fonctionnalités disponibles dans la solution CA. Ces fonctionnalités ne sont pas réellement nécessaires pour atteindre les objectifs de son projet. Pourquoi payer pour des fonctionnalités que vous n'utilisez pas et que vous n'avez pas l'intention d'utiliser un jour ?
Dans la nouvelle solution, AD FS prend en charge la logique de politique via son moteur de fédération et les applications fédérées en aval gèrent leur propre logique d'autorisation (comme elles le faisaient avec l'ancienne solution). Les applications non fédérées font l'objet d'une rétro-proxie derrière un filtre ISAPI Siteminder et utilisent une simple variable d'en-tête avec un numéro d'identification d'employé comme valeur. Cette façon de faire n'est ni sûre ni moderne.
Passer par le proxy et vérifier en permanence l'état du cookie Siteminder, c'est bien, mais comment résoudre le problème du passage de la valeur de l'en-tête de l'ID de l'employé ? Est-ce que SSL est "suffisant" ? Je ne suis pas à l'aise avec ce niveau de sécurité (ou d'absence de sécurité), mais nous devons travailler pour l'instant avec ce que les applications en aval prennent en charge.
Si notre client décide de migrer vers un autre produit ou d'externaliser la fonctionnalité de fournisseur d'identité vers un fournisseur de services en nuage, cette solution fonctionnera sans code supplémentaire ni modification ! L'administrateur du client n'a qu'à mettre à jour deux lignes dans un fichier de configuration et il est prêt à consommer les assertions SAML d'un nouveau fournisseur d'identité !
Examinons les éléments clés de l'architecture et de la conception de cette solution :
- Je n'ai pas utilisé WIF (Windows Identity Foundation). Bien que WIF soit au cœur du développement basé sur les revendications pour les applications .NET, il ne correspondait pas aux concepts clés de ma conception. J'en ai déjà mentionné un : nous évitons d'être liés à AD FS.
- Je voulais augmenter les performances en utilisant du code compilé plutôt que de l'ASP interprété. J'avais prévu d'écrire l'application en C#, mais je la voulais sous forme d'assemblage. Il y a d'autres raisons de compiler le code que nous verrons bientôt.
- Le code est un gestionnaire HTTP personnalisé, plutôt qu'un filtre ou une autre interface. Le traitement s'effectue sans nécessiter de fichiers html ou aspx ni de scripts. L'interface du gestionnaire accepte les connexions adressées à un type de fichier virtuel.
- La solution est simplement un fournisseur de services ou "SP" dans la terminologie SAML 2.0, ce que Microsoft appellerait un "Relying Party" dans le langage AD FS. Notez que les composants supplémentaires d'une plate-forme de fédération typique ne sont pas présents car ils ne font pas partie de l'objectif de la conception - nous résolvons un problème particulier, nous n'essayons pas de créer une solution de fédération à composants multiples. Notamment, j'avais l'intention de faire en sorte que la conception prenne en charge plusieurs partenaires de fédération de fournisseurs d'identité.
- Je voulais que la solution soit aussi légère et indépendante des autres composants que possible. Quand je dis "léger", il faut par exemple considérer que le code n'utilise pas et ne nécessite pas de base de données SQL en arrière-plan ! Il n'y en a pas besoin, comme je l'expliquerai plus loin ! Considérez comment cela peut améliorer les performances - il n'y a tout simplement pas d'attente pour une connexion à la base de données, une requête et une réponse. Des catégories entières de modes de défaillance sont éliminées par cette simplification.
- Bien entendu, le code est extensible : si une autre interface d'application en aval est souhaitée, elle peut être ajoutée au code sans qu'il soit nécessaire de réécrire ce qui est déjà en place.
- Outre l'exigence évidente que le serveur du gestionnaire HTTP soit IIS et prenne en charge .NET 3.5 ou une version plus récente, je n'ai pas lié le code à un langage d'application de serveur web particulier - le serveur web avec lequel mon code SP s'interface peut utiliser VB, C# ou peut-être PHP, Python ou tout autre langage. Que l'application que nous rendons compatible avec SAML se trouve sur le même serveur IIS ou sur un serveur distinct exécutant Weblogic ou Apache, la solution est "agnostique" sur le plan de la plate-forme.
- Comme vous pouvez le deviner, je ne voulais pas que la solution réside sur un seul domaine Active Directory avec l'IdP, ni même qu'elle ait besoin d'Active Directory. Considérez qu'en tant que SP autonome, il n'y a aucune exigence inhérente à l'utilisation d'un annuaire par l'application fédérée ! Certes, l'une des options de connexion que j'ai ajoutées est une recherche LDAP qui crée un jeton de contexte d'utilisateur ASPX, car une implémentation en avait besoin.
- En relation avec le point 5, le SP est configuré via un simple fichier web.config - le plus simple étant le mieux, c'était mon objectif de conception. Un serveur IIS avec les prérequis présents : .NET 3.5 ou plus, un compte de service prêt à être assigné à l'App Pool, des informations sur l'IdP (ou plusieurs IdP !) peut être configuré et opérationnel en moins de 5 minutes !
- Évolutivité. J'espérais que, tout en respectant les objectifs de conception décrits ici, je pourrais créer une solution facilement extensible. Nous verrons les avantages et les inconvénients de mon approche "simple". L'absence de base de données de configuration centrale signifie qu'il faut gérer un fichier de configuration pour chaque serveur SP ajouté (chaque serveur a un web.config), mais le système fonctionnera très bien avec seulement quelques serveurs, et le problème de la synchronisation de quelques fichiers a été résolu de manière approfondie et devrait être bien compris. Même si vous disposiez d'une base de données de configuration centrale, certains éléments de la configuration des n-serveurs doivent toujours être traités sur chaque système.
Limites :
Actuellement, seul le SSO initié par l'IdP est pris en charge avec la liaison POST. Il ne s'agit pas vraiment d'une limitation puisqu'un IdP est sûr de prendre en charge cette liaison - c'est la liaison SAML la plus couramment utilisée. Le code peut être mis à jour pour supporter le SSO initié par le SP ou même la redirection HTTP (la capacité de support des chaînes de requêtes est déjà présente), mais je n'ai pas l'intention de supporter la résolution d'artefacts ou le binding SOAP - ils ajoutent juste de la complexité et ne sont pas si communs. Dans tous mes projets de fédération, je n'ai encore jamais vu personne insister sur la résolution d'artefacts ou même demander SOAP.
Notes :
Le fichier .dll a actuellement une taille modeste de 20 kb. Le temps de traitement typique d'une assertion SAML n'est que de 5 ms, avec une moyenne observée d'environ 20-27 ms. Ce temps de traitement comprend la consommation complète de l'assertion SAML 2.0, y compris les étapes nécessaires telles que la vérification de la (des) signature(s) cryptographique(s) et toute la logique concernant la transmission à l'application en aval.
