Scénarios d'utilisation de SAML

La fonction SAML est décrite à l'aide de quatre scénarios d'utilisation basiques. Les trois premiers scénarios présentent la connexion unique dans le cadre des services Web, configurée à l'aide d'un ensemble de règles. Le quatrième scénario décrit la connexion unique SAML personnalisée, qui peut être construite à l'aide de l'API SAML et de l'API de client sécurisé. Les scénarios montrent la façon d'utiliser des blocs SAML et des API pour s'authentifier auprès d'un service de jeton de sécurité (STS), demander des jetons SAML et obtenir l'accès à des services métier.

Généralités

WebSphere Application Server avec SAML contient des blocs de construction et des API destinés à la création de solutions de connexion unique et de fédération d'entité pour les entreprises, à l'aide de jetons SAML. Les blocs sont constitués par les ensembles de règles SAML, utilisables sans la moindre ligne de programmation pour configurer la requête des jetons SAML par les applications de services Web, propager les jetons SAML dans les messages SOAP, et valider et authentifier les jetons SAML.

En utilisant les API SAML et et les API client WS-Trust, vous pouvez programmer la création de jetons SAML, les analyser et les valider, et authentifier les jetons SAML reçus sous des protocoles autres que les messages SOAP des services Web. Spécifiquement, utilisez les API SAML pour traiter les attributs personnalisés des jetons SAML, créer des interfaces d'application personnalisées et attribuer des autorisations à la demande. Utilisez l'API client WS-Trust pour demander des jetons, SAML ou autres, à un service STS, échanger des jetons de sécurité avec un STS et en valider.

Le produit WebSphere Application Server ne contient pas de service STS pour l'émission de jetons de sécurité SAML ou d'autres types. Cependant, WebSphere Application Server avec SAML interopère avec Tivoli Federated Identity Manager et d'autres implémentations de service de jeton de sécurité (STS) tiers.

Scénario 1 : connexion unique (SSO) dans le cadre des services Web

Dans ce scénario d'utilisation de la connexion unique, un utilisateur s'authentifie auprès d'un service STS et demande des jetons SAML en utilisant la méthode de confirmation bearer (porteur). Il se sert ensuite des jetons SAML pour accéder à un fournisseur de services métier. Le fournisseur de services métier valide les jetons SAML et confirme l'identité et les attributs de l'utilisateur sur la base de la relation de confiance établie entre le fournisseur et le service STS émetteur. Les jetons SAML reçus sont valides si leurs certificats signataires sont considérés comme des certificats de confiance par le fournisseur de services métier, et si leur délai d'expiration est inférieur au délai local du fournisseur augmenté d'un décalage d'horloge configurable.

Le fournisseur de services métier peut accéder à des services en aval, selon la configuration de leurs règles, pour le compte de l'utilisateur des jetons SAML. En fonction des règles, il propage les jetons SAML d'origine, ou il génère lui-même des jetons SAML prenant en compte les attributs de l'utilisateur. Pour une description détaillée de la façon de configurer les ensembles de règles et les liaisons pour ce scénario, reportez-vous à la section relative à la configuration des liaisons des clients et des fournisseurs pour le jeton SAML bearer (porteur).

La connexion unique utilisant un jeton SAML bearer présente l'avantage, par rapport à d'autres mécanismes de connexion unique, de faire appel à un jeton de sécurité qui constitue un standard du secteur industriel et est pris en charge par les produits de nombreux fournisseurs. En outre, l'implémentation WebSphere Application Server de la fonction SAML interopère avec Tivoli Federated Identity Manager, DataPower et des produits d'autres fournisseurs.

Ce diagramme présente l'interaction entre le service STS et le fournisseur de services métier dans le scénario d'utilisation de la connexion unique dans le cadre des services Web.
Figure 1. Scénario d'utilisation de la connexion unique dans le cadre des services Web
Scénario de connexion unique (SSO) avec jeton porteur SAML

Vous pouvez ajouter une liaison de demandeur aux modèles de liaison de fournisseur SAML pour sélectionner le jeton SAML reçu représentant l'identité du demandeur. L'environnement d'exécution de sécurité des Services Web utilise l'élément NameId pour représenter l'identité du client et rechercher le nom de sécurité et le groupe d'appartenance de l'utilisateur à partir du registre d'utilisateurs configuré, lors de l'utilisation de la configuration de connexion JAAS system.wss.caller par défaut.

Après l'aboutissement de ce scénario, l'environnement d'exécution WS-Security sauvegarde les jetons SAML de façon à pouvoir les réutiliser pour accéder au même fournisseur de services métier, tant que les jetons sont valides. Un jeton est valide tant que son délai d'expiration est inférieur à la période de mise en cache, qui est configurable. Une fois que le fournisseur a validé et authentifié les jetons SAML reçus, les sujets JAAS et les jetons SAML correspondants sont sauvegardés dans le cache d'authentification. Les jetons SAML restent valides dans le serveur d'applications hôte, quel que soit leur délai d'expiration. Cela signifie que l'environnement d'exécution WS-Security ne vérifie pas le délai d'expiration du jeton SAML à l'intérieur du même processus, parce que les jetons SAML restent valides dans le processus du serveur d'applications tant qu'ils sont dans le cache d'authentification.

Le délai d'expiration des jetons SAML est vérifié lorsque le fournisseur de services métier les utilise pour appeler des services en aval. Les demandes sortantes échouent si le délai d'expiration des jetons est supérieur ou égal au délai en cours augmenté de la période de mise en cache. Cette limitation s'applique aussi lorsque la configuration des règles impose l'utilisation des jetons SAML d'origine. En revanche, elle ne s'applique pas si les règles font appel à des jetons auto-générés, c'est-à-dire des jetons qui sont une reproduction, créée et signée par le fournisseur, des jetons SAML d'origine.

Scénario 2 : connexion unique (SSO) dans le cadre des services Web avec une validation holder-of-key

Le scénario d'utilisation de la connexion unique avec validation holder-of-key (détenteur de clé - HoK) est semblable au scénario d'utilisation SSO précédent. Le scénario de connexion unique avec validation holder-of-key fait appel à des jetons SAML associés à la méthode de confirmation holder-of-key au lieu de la méthode bearer. Les jetons SAML holder-of-key contiennent une clé SAML qui sert au client à prouver qu'il en est le propriétaire, et qu'il est également propriétaire du jeton. Cette clé intégrée peut être une clé partagée (aussi appelée clé symétrique) ou un certificat X.509 avec une clé publique (aussi appelée clé asymétrique). Dans le cas d'une clé partagée, la clé est chiffrée à l'aide de la clé publique du fournisseur cible de services métier, de sorte que seul le service prévu puisse consommer les messages SOAP.

Lorsqu'un client demande à un service STS des jetons SAML avec la clé partagée holder-of-key, le service STS chiffre la clé dans les jetons SAML et envoie au client demandeur la copie de cette même clé dans la réponse WS-Trust. Cette opération est nécessaire, faute de quoi le client n'est pas en mesure de lire la clé chiffrée dans les jetons SAML. Pour prouver qu'il est propriétaire des jetons SAML, le client signe et chiffre les messages de demande SOAP à l'aide de la clé partagée. Les services métier doivent valider la propriété du jeton holder-of-key en extrayant la clé partagée chiffrée et en l'utilisant pour vérifier la signature numérique.

Le diagramme qui suit illustre la manière dont un service Web demande un jeton SAML dans ce scénario.
Figure 2. Services Web 1 demandant un jeton SAML à un service externe
Scénario de connexion unique (SSO) avec validation holder-of-key

 1  L'utilisateur se connecte avec un navigateur Web en utilisant SPNEGO et il est authentifié. Un sujet JAAS est créé.

 2  Les données d'authentification du jeton SPNEGO sont utilisées pour demander un jeton SAML à l'aide de WS-Trust. Le jeton est signé avec la clé privée du serveur de confiance.

 3  La signature du jeton SAML est validée sur la base de la relation de confiance. Les données d'identification sont créées à l'aide des attributs du jeton SAML. La clé cryptographique du jeton SAML sert à déchiffrer le message SOAP.

Comme le montre le diagramme, un client de navigation utilise les données d'identification Kerberos (représentées par le jeton SPNEGO) pour accéder à une application Web. En supposant que les données d'identification Kerberos puissent être déléguées, l'application web peut demander un jeton SAML au service STS pour le compte du client, en utilisant les données d'identification Kerberos client déléguées. Par exemple, l'application Web obtient du centre de distribution de clés un jeton Kerberos (APREQ) de demande d'approbation de client. L'application Web utilise ensuite le jeton APREQ de client pour s'authentifier auprès du service STS et demander un jeton SAML de client au service STS pour le compte du client.

Dans cet exemple, le jeton SAML requiert la méthode de confirmation holder-of-key avec une clé symétrique. L'application Web utilise le jeton SAML pour accéder aux services métier en aval, toujours pour le compte du client, de sorte que le jeton SAML authentifie le client auprès des services en aval et protège les messages de demande à l'aide de la signature numérique et du chiffrement. Pour plus d'informations sur la façon de configurer des liaisons pour le jeton holder-of-key, reportez-vous à la section relative à la configuration des liaisons des clients et des fournisseurs pour le jeton SAML holder-of-key (HoK - détenteur de clé).

Après l'aboutissement de ce scénario, les services métier cibles peuvent utiliser le jeton SAML pour accéder à d'autres services en aval à l'aide de la procédure décrite dans ce scénario, à condition que ces derniers puissent extraire la clé intégrée. Les services métier peuvent aussi être configurés pour accéder aux services en aval avec des jetons SAML auto-générés, de façon à ne pas diffuser la clé privée.

Scénario 3 : gestion des identités fédérées par les services Web

Dans le scénario d'utilisation de la gestion des identités fédérées, un client de navigation accède à une application Web du portail d'une société. Dans ce scénario, les données d'authentification de base de l'utilisateur, par exemple son nom d'utilisateur et son mot de passe, sont utilisées pour demander des jetons SAML à un service STS, puis ceux-ci sont utilisés pour obtenir l'accès aux services métier dans l'ensemble des domaines de sécurité. Le fournisseur de services métier destinataire valide les jetons SAML sur la base de la relation de confiance qu'il a établie avec le service STS émetteur. Il confirme également l'identité et les attributs de l'utilisateur. L'utilisateur n'a donc pas besoin d'être défini au préalable dans l'annuaire des utilisateurs des services métier cibles. Ce scénario présente l'avantage de faciliter la fédération des services métier de plusieurs partenaires, tout en supprimant la nécessité de consolider les utilisateurs dans un service d'annuaire.

Figure 3. Un utilisateur se connecte au portail d'une société et utilise la gestion des entités fédérées pour accéder à des services métier
Scénario de gestion des entités fédérées

 1  L'utilisateur se connecte et s'authentifie au portail de la société à l'aide d'un nom d'utilisateur et d'un mot de passe. Un sujet JAAS est créé.

 2  Le nom d'utilisateur et le mot de passe sont utilisés pour l'authentification auprès du service STS et pour la demande d'un jeton SAML représentant l'utilisateur.

 3  La signature du jeton SAML est validée sur la base de la relation de confiance. Les données d'identification sont créées à l'aide des attributs du jeton SAML. La clé cryptographique du jeton SAML sert à déchiffrer le message SOAP.

La configuration de connexion système par défaut, wss.caller, mappe l'identité des utilisateurs représentées par des jetons SAML à celle des utilisateurs répertoriés dans l'annuaire configuré. Un module de connexion personnalisé doit lui être ajouté pour la confirmation, auprès du serveur d'applications, de l'identité des utilisateurs des jetons SAML provenant d'autres domaines de sécurité. Ce module de connexion personnalisé extrait l'identité de l'utilisateur du jeton SAML, ainsi que d'autres attributs, et construit les propriétés d'assertion utilisées par le serveur d'applications. Deux de ces propriétés, le nom et l'identité de l'utilisateur, sont requises par le serveur d'applications. Ces deux propriétés étant contenues dans la vérification d'identité, le serveur d'applications n'a pas besoin de revalider le nom d'utilisateur à l'aide de l'annuaire local.

En outre, des informations sur l'appartenance à un groupe d'un utilisateur peuvent être fournies au serveur d'applications. Ces informations sont utilisées pour construire l'objet WSCredential représentant les données d'identification au serveur d'applications de l'utilisateur. Les propriétés de l'utilisateur sont transmises au module WSWSSLoginModule du serveur d'applications à l'aide de l'état partagé du LoginContext JAAS. Pour plus d'informations sur ces propriétés, consultez la section relative à la configuration du mappage d'identités entrantes.

Scénario 4 : solutions personnalisées de connexion unique (SSO)

Le scénario d'utilisation de la connexion unique personnalisée fait appel aux API de bibliothèque de jetons, aux API client WS-Trust, et à d'autres API et SPI de serveur d'applications pour construire des solutions de connexion unique adaptées à un environnement informatique métier spécifique. Le diagramme de ce scénario présente un exemple dans lequel les utilisateurs sont authentifiés et reçoivent des jetons SAML en provenance d'un fournisseur d'identité disposant d'une relation de confiance avec le serveur d'une société. Dans ce scénario, une société veut accorder aux utilisateurs des droits d'accès à des applications Web protégées sur la base d'une relation de confiance, sans leur demander plus d'éléments d'authentification.

Les clients Web d'applications, par exemple les navigateurs Web, transmettent les jetons SAML au serveur d'applications à l'aide du protocole HTTPS, au lieu du protocole des services Web. Pour intercepter et transmettre ces demandes, la société construit un intercepteur SAML TAI Trust Association Interceptor) qui implémente l'API TAI. Un intercepteur TAI SAML fait appel à l'API de bibliothèque de jetons SAML pour la validation et l'authentification des jetons SAML. L'intercepteur TAI SAML peut aussi utiliser l'API client WS-Trust pour valider et authentifier les jetons SAML à l'aide d'un service STS externe. Pour plus d'informations sur l'interface TAI, consultez la section relative au développement d'un intercepteur personnalisé pour les relations de confiance. WebSphere Application Server ne contient pas d'intercepteur TAI SAML personnalisé.

Figure 4. Un utilisateur se connecte au serveur d'une société avec un navigateur Web utilisant le protocole HTTPS et il est authentifié à l'aide d'un intercepteur TAI SAML.
Scénario personnalisé de connexion unique (SSO)

 1  L'utilisateur se connecte à un fournisseur d'identité à l'aide d'un nom d'utilisateur et d'un mot de passe. Le fournisseur d'identité émet un jeton SAML pour l'utilisateur.

 2  L'intercepteur TAI SAML valide et authentifie le jeton SAML à l'aide de l'API SAMLTokenFactory pour créer les données d'identification de l'utilisateur. L'intercepteur TAI SAML peut aussi utiliser l'API client WS-Trust pour valider le jeton SAML à l'aide d'un service STS externe.

Pour plus d'informations sur les API SAML, consultez les sections relatives à l'API client WS-Trust et aux API de bibliothèque de jetons SAML.

Solution plus complexe : plusieurs domaines de sécurité

Les sections précédentes de ce document ont porté sur quatre scénarios d'utilisation de base. Toutefois, vous pouvez vouloir vérifier les jetons SAML dans plusieurs limites de domaines de sécurité. Pour plus d'nformations sur cette solution, voir la documentation sur les vérifications SAML dans les domaines de sécurité WebSphere Application Server.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_samlusagescenarios
Nom du fichier : cwbs_samlusagescenarios.html