Windows Azure AppFabric Access Control (ou plus simplement ACS) est un service “dans le nuage” qui a pour but de simplifier et de fédérer l’authentification des utilisateurs sur vos applications web. Plutôt que d’implémenter vous-même un mécanisme de connexion spécifique à votre site, vous pouvez vous reposer sur ACS et des providers d’identités publics tels que Facebook, Live, Yahoo, Google ou un provider d’identité privé basé sur votre annuaire d’entreprise.

Dans cette série d’article, je vais présenter ce que je sais d’ACS, en commençant par la configuration du service sur le portail Azure, puis la configuration de la solution pour qu’ACS soit utilisable dans votre application et pour que celle ci soit déployable sur Azure. Enfin, je reviendrais sur quelques astuces de développement, qui ne concerneront pas seulement ACS mais plus globalement WIF (Windows Identity Foundation).

Tout commence sur le portail Azure, dans la section “Service Bus, Access Control & Caching” puis “Access Control”. Vous avez ici la liste des subscriptions pour lesquelles vous êtes à minima co-administrateur. Vous devez commencer par créer un namespace pour votre application. Un namespace correspond au endpoint auquel votre service est disponible, soit une adresse du type http://votrenamespace.accesscontrol.windows.net.

Une fois le namespace créé, le portail de gestion d’ACS est accessible soit via le gros bouton “Access Control Service” en haut de la fenêtre, ou alors en entrant directement l’adresse du endpoint.

Une fois connecté au portail d’administration d’ACS, la première chose à faire est de définir les providers d’identité qui seront utilisables par nos applications. Windows Live ID est le provider par défaut.

En cliquant sur le bouton « Add », on accède à la liste des providers qui n’ont pas encore été configuré. Pour ce blogpost, je laisse de côté l’intégration avec AD FS et je vais plutôt me concentrer sur le scénario d’un site web grand public. Nous pouvons donc ajouter une application Facebook, Google et Yahoo.

Pour commencez, parlons du cas Google et de Yahoo. Leur configuration est simple puisque seules les informations d’une section « Login Page Settings » sont définissables. L’option Login link test correspond à ce qui sera affichée sur la page de login standard d’ACS ou à ce qui sera renvoyé par le flux JSON de la liste des providers (voir en fin d’article), même chose pour l’image URL. Dans un premier temps, vous pouvez donc laisser leurs valeurs par défaut.

Choisissez maintenant d’ajouter une application Facebook. C’est un cas particulier puisqu’il demande plus de configuration.

Premier point important, on parle ici d’ajouter une application Facebook en tant que fournisseur d’identité, et non pas ajouter Facebook en tant que fournisseur d’identité. Si vous avez ajouté Google et/ou Yahoo en provider et que vous retournez sur la page “Identity Providers” puis cliquez sur “Add”, ces choix sont maintenant grisé. Par contre, vous pouvez ajouter de multiples applications Facebook.

Le champ « Display name » correspond au nom qui sera utilisé ailleurs pour ce provivder dans le portail d’administration ACS (dans les pages de définition des règles à appliquer aux claims par exemple).

L’application ID et l’application secret sont deux éléments fournis par Facebook à la création d’une application. Pour pouvoir intégrer l’authentification Facebook à votre site web, vous devez donc créer en premier lieu une application Facebook.

Petit détail qui a son importance, dans le portail développeur de Facebook (https://developers.facebook.com), vous devez renseigner la callback url (qui correspond à votre adresse du portail d’administration d’ACS).

Dernière particularité propre à Facebook, le jeu de permissions que les utilisateurs devront attribuer à votre application. Cela vous permettra d’interagir plus profondément avec l’API Facebook, sachant que vous récupérerez dans les claims un accesstoken.

La prochaine étape consiste à enregistrer votre site internet en définissant une application dans le portail. C’est grace à cela que ACS sera capable de reconnaître votre site comme étant un site de confiance.

Dans cet écran, commencez par renseigner les champs Realm et Return URL : c’est à dire l’adresse du site pour lesquels les token de sécurité seront valides et l’adresse de la callback vers laquelle les utilisateurs seront redirigés.

Un token de securité est renvoyé par un provider d’identité ou par ACS pour signifier que l’authentfiication d’un utilisateur a réussie. Vous n’avez pas le contrôle sur le format des tokens renvoyés par des providers tels que Google ou Facebook vers, mais vous pouvez chosir le format de ceux renvoyés par ACS vers votre application. Dans notre cas, nous laisserons les valeurs par défaut.

Dans la section Authentication Settings, choisissez les providers d’identité que vous souhaitez activer pour cette application. Puis cochez la case “create new rule group”, la suite de cet article explique leur utilité.

Il peut être intéressant de configurer deux applications sur le portail : une pour votre environnement de développement (qui pointe vers 127.0.0.1:81), et une autre pour votre environnement de production (qui pointe vers votresite.cloudapp.net).

Le choix des informations (claims) qui seront récupérées par ACS puis retransmises vers votre application se fait au travers de la définition de règles. Dans notre, cas nous avons deux jeux de règles, un pour chaque application que nous avions déclaré.

A sa création, le jeu de règles est vide. Deux solutions pour un ajouter : les créer from scratch en cliquant sur Add, ou les générer automatiquement. Choisissez cette deuxième option.

L’outil vous propose maintenant de choisir les providers d’identé pour lesquels des règles doivent être générés.

Une fois le formulaire précédent validé, l’outil a su générer des claims pour chaque provider en fonction des informations mises à disposition.

Une règle est définie de a manière suivante.

Si l’émetteur du claim est A et si le type du claim est B et si la valeur du claim est C…

… Alors le type du claim en sorti est D, sa valeur est E.

Le dernier champs de cette page est la description de la règle telle qu’elle apparaitra sur la page du jeu de règle.

Ainsi, dans l’exemple ci dessous, je remplace le claim de type emailadress (venant de Google) par un type de claim custom (http://myclaims/emailaddress).

La section Application Integration contient la liste des endpoint de votre sevice pour les différents protocoles supportés par ACS.

Cliquez sur Login Pages.

Les URL d’intégration pour le login de vos utilisateurs sont relatives aux applications que vous avez précédemment déclarées dans la section « Relying parti applications ». Dans notre cas, il y a donc celles pour l’application déployée dans ma fabrique locale et celle déployée en production.

Le détail de la page « Login Page Integration » contient une URL vers une page de connexion générique et une URL vers un flux JSON.

Le flux JSON contient la liste des providers d’identité déclarée pour l’application sélectionnée. Pour chaque provider, on retrouve un nom, l’adresse de connexion (qui, selon les providers, contient des infos sur les claims à récupérer ou encore l’adresse de callback), et l’URL vers l’image du provider telle que définie plus tôt.

[
{
"Name":"Windows Live™ ID",
"LoginUrl":"https://login.live.com/login.srf?wa=wsignin1.0...",
"LogoutUrl":"https://login.live.com/login.srf?wa=wsignout1.0",
"ImageUrl":"",
"EmailAddressSuffixes":[]
},
{
"Name":"Google",
"LoginUrl":"https://www.google.com/accounts/o8/ud?openid.ns=http%3a%2f%...",
"LogoutUrl":"",
"ImageUrl":"",
"EmailAddressSuffixes":[]
},
{
"Name":"Facebook",
"LoginUrl":"https://www.facebook.com/dialog/oauth?client_id=1188... ",
"LogoutUrl":"",
"ImageUrl":"","EmailAddressSuffixes":[]
}
]

A présent, votre service ACS est prêt à être utilisé par votre application !