Quand un utilisateur s'authentifie sur un site utilisant ADFS, il doit sélectionner le provider d'identité (IdP) qu'il souhaite utiliser (AD, LiveID, etc.), si ADFS est configuré pour utiliser plusieurs IdP. Pour que l'utilisateur n'ait pas à sélectionner à chaque connexion l'IdP, ADFS va sauvegarder ce choix dans un cookie. Pour pouvoir de nouveau sélectionner un IdP, l'utilisateur devra attendre l'expiration du cookie ou le supprimer, utiliser un autre navigateur ou utiliser une navigation InPrivate.

Dans certains scénarios, on va avoir besoin de désactiver cette sauvegarde pour que la sélection d'un IdP soit nécessaire à chaque connexion, notamment si un ordinateur est utilisé par plusieurs utilisateurs.

(lire plus…)

WIF (Windows Identity Foundation) permet de sécuriser un service WCF via le mécanisme de fédération d’identité en utilisant le standard SAML pour échanger les informations entre le STS et le service (pour plus d’informations : http://sebastienollivier.fr/blog/federation-didentite/service-wcf-claims-aware/).

Par contre, WIF ne permet pas (encore ?) de sécuriser un service WCF en utilisant le standard SWT. On va voir dans ce post comment remédier à ce manque.

(lire plus…)

Hormis le fait que ADFS 2 et ACS soient respectivement des STS (Security Token Service) version On-Premise et version Cloud de Microsoft, ces deux services proposent des fonctionnalités légèrement différentes.

(lire plus…)

Lorsqu’on utilise Live ID comme Identity Provider sur ACS, le seul Claim renvoyé par Live ID est un hash de l’UID du compte Live utilisé. Les informations telles que l’adresse email, le nom ou le prénom ne sont pas renvoyées.

Pour retrouver ces informations, la plupart des sites internet utilisant Live ID propose un formulaire d’enregistrement où l’utilisateur authentifié pourra renseigner ses informations (au moins son email). Au delà du fait qu’on oblige l’utilisateur à renseigner des informations qu’il a déjà renseignées à la création de son compte Live, cette solution n’est pas fiable puisqu’on ne peut pas vérifier que l’email renseigné correspond à l’email avec lequel l’utilisateur s’est logué, à moins d’envoyer un email à cette adresse contenant une URL de validation d’inscription… mais là le processus d’inscription devient infernal pour l’utilisateur.

Le SDK Live permet d’accéder aux informations du compte Live ID de l’utilisateur logué, en utilisant le même principe de consentement que Facebook et GMail.

(lire plus…)

Lorsque l’on fait de la fédération d’identité, deux scénarios sont possibles pour authentifier un utilisateur: la fédération passive et la fédération active.

La fédération passive consiste à utiliser le protocole WS-Federation via les mécanismes HTTP de redirection et de POST (ce scénario convient donc plutôt à des applications Web). De cette manière, l’application ne possède aucune logique d’authentification et n’est pas responsable des données d’authentification de l’utilisateur.

Avec la fédération active, l’application possède la logique de récupération des données d’authentification de l’utilisateur et en est donc responsable. Le protocole WS-Trust est utilisé pour récupérer un token auprès du STS. Ce scénario convient donc à des applications de type service Windows contactant un service web fédéré.

La première étape lors d’une fédération active est donc de récupérer un token auprès du STS. Pour cela, le framework WIF fournit, dans le namespace Microsoft.IdentityModel.Protocols.WSTrust, l’interface IWSTrustContract permettant d’envoyer un message WS-Trust au STS, via la méthode Issue.

(lire plus…)

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.

(lire plus…)

Pour que le scénario de fédération d’identité soit valide de bout en bout, il faut que l’application ait déclaré (via le fichier de configuration) que le STS (Security Token Service), à qui est délégué la gestion de l’authentification et de l’identité, est un STS de confiance (c’est à dire que l’application “croît” les informations renvoyées par ce STS), et il faut que le STS ait enregistré l’application comme Relying Party (c’est à dire que le STS accepte d’authentifier et de renvoyer les informations d’identité de l’utilisateur à l’application).

Ce double trust est essentiel puisqu’il permet au STS de ne pas gérer l’authentification d’applications non enregistrées (et donc de ne pas renvoyer de données d’identité à n’importe quelle application) et il permet à l’application de ne pas accepter les informations d’identité émit par n’importe quel STS.

Ce post explique comment enregistrer une application dans ADFS. Pour avoir les informations sur l’enregistrement d’une application dans ACS d’Azure, c’est ici : Enregistrer une application dans ACS.

(lire plus…)

Pour que le scénario de fédération d’identité soit valide de bout en bout, il faut que l’application ait déclaré (via le fichier de configuration) que le STS (Security Token Service ), à qui est délégué la gestion de l’authentification et de l’identité, est un STS de confiance (c’est à dire que l’application “croît” les informations renvoyées par ce STS), et il faut que le STS ait enregistré l’application comme Relying Party (c’est à dire que le STS accepte d’authentifier et de renvoyer les informations d’identité de l’utilisateur à l’application).

Ce double trust est essentiel puisqu’il permet au STS de ne pas gérer l’authentification d’applications non enregistrées (et donc de ne pas renvoyer de données d’identité à n’importe quelle application) et il permet à l’application de ne pas accepter les informations d’identité émit par n’importe quel STS.

Ce post explique comment enregistrer une application dans ACS d’Azure. Pour avoir les informations sur l’enregistrement d’une application dans ADFS, c’est ici : Enregistrer une application dans ADFS.

(lire plus…)

A l'installation du SDK Windows Identity Foundation (WIF), l'utilitaire Windows Identity Foundation Federation Utility est déployé. Cet utilitaire permet de rendre une application claims-aware en quelques clics. Un addon Visual Studio est installé avec l'utilitaire.

Nous allons voir comment, grâce à cet utilitaire, déléguer l'authentification d'une application ASP.NET à un STS (Security Token Service).

(lire plus…)