De la même manière que pour une application ASP.NET, on peut utiliser la fédération d’identité pour sécuriser un service WCF.
On va voir dans ce post comment rendre un service WCF claims-aware, via l’utilitaire Windows Identity Foundation Federation Utility.
Windows Identity Foundation Federation Utility
Pour lancer l’utilitaire, cliquez droit, dans Visual Studio, sur Add STS reference… à partir d’un projet WCF (si l’utilitaire ne se lance pas, vous pouvez l’exécuter depuis le menu Administration Tools de Windows).
Le premier écran présente les informations sur notre service. On doit y renseigner l’emplacement du fichier de configuration (qui sera modifié par l’utilitaire) et l’URL du service.
Le deuxième écran permet de sélectionner le STS responsable de l’authentification. Pour utiliser ACS (Access Control Service, STS version Cloud de Microsoft) ou ADFS (Active Directory Federation Services, STS version On-Premise de Microsoft), on doit sélectionner l’option Use an existing STS et renseigner l’adresse du fichier FederationMetadata.xml du STS, fichier contenant les informations de configuration.
L’écran suivant permet d’activer le cryptage du token SAML (obligatoire pour un service WCF) en fournissant un certificat.
Après validation, l’utilitaire va modifier le fichier de configuration de notre service.
Web.config
Une behaviorExtension est ajoutée. Cette extension permet de surcharger le ServiceHost de WCF en y ajoutant les mécanismes liés à la fédération d’identité.
Le behavior du service va être modifié pour y activer l’extension précédemment déclarée et pour ajouter le certificat sélectionné via l’utilitaire.
Un binding ws2007FederationHttpBinding (basé sur ws2007HttpBinding et supportant la sécurité fédérée) est ajouté.
Ce binding est lié à notre service via un mapping sur le protocol HTTP.
La section microsoft.IdentityModel est la section qui contient toutes les informations de configuration nécessaire au Framework WIF.
Le token SAML renvoyé par le STS contient une audienceUri correspondant à l’URL de l’application (au sens large) pour laquelle le token a été créé. La section audienceUris permet de spécifier la liste des URL qui seront considérées comme appartenant à notre service. Cela permet d’éviter qu’un token créé pour une application ne soit réutilisé dans notre application.
La section issuerNameRegistry contient la liste des STS à qui l’on accepte de déléguer la gestion de l’authentification. Cette section est très importante puisqu’elle permet d’indiquer quels sont les STS de confiance. Les tokens renvoyés par les STS enregistrés dans cette section seront considérés comme valides et l’identité de l’utilisateur se basera sur le contenu de ces tokens.
En plus de modifier le fichier de configuration, l’utilitaire va générer un fichier FederationMetadata.xml qui nous permettra d’inscrire notre application au STS de manière simplifiée.
Claims Identity
Le service utilise maintenant une sécurité basée sur la fédération d’identité. Pour pouvoir appeler une méthode du service, il faudra envoyer dans les header de la requête le token créé par le STS (j’expliquerai dans des posts suivants comment acquérir ce token via fédération passive et active).
L’identité de l’utilisateur accédant au service est disponible via Thread.CurrentPrincipal.
La propriété Claims de la classe ClaimsIdentity permet d’accéder à la liste des claims renvoyée par le STS.
A bientôt :)