Tutoriel : Contrôle d’accès granulaire avec Windows Azure AppFabric

Contexte

Lors du précédent tutoriel, vous avons vu comment intégrer rapidement une solution de contrôle d’accès au service de données OGDI (Open Government Data Initiative) grâce à Windows Azure AppFabric, et plus particulièrement le service de contrôle d’accès (Access Control Service).

Pour rappel, pour accéder au service de données OGDI, l’application cliente devait d’abord contacter le service ACS (avec lequel une relation de confiance a été préalablement établie) pour soumettre ses crédentités (credentials), à savoir login et mot de passe pour simplifier le tutoriel, même s’il est tout à fait possible de soumettre une assertion SAML ou une clé symétrique, voir la documentation MSDN). Une fois identifié auprès d’ACS, le client recevait un jeton SWT qu’il pouvait ensuite injecter dans ses requêtes auprès du service de données OGDI et ainsi avoir un accès complet au service.

Cette fois-ci, nous vous proposons d’illustrer un scénario où le contrôle d’accès serait plus granulaire. Imaginons un service de données qui proposerait deux jeux de données différents : un jeu de données « people » donnant accès à une liste de personnes et un jeu de données « budget » contenant des données budgétaires. Dans le scénario envisagé, l’entité qui expose ces jeux de données, souhaiterait par exemple autoriser l’entité A à accéder seulement au jeu de données « people », l’entité B à accéder seulement au jeu de données « budget » et enfin l’entité C à accéder aux deux jeux de données.

On pourrait donc imaginer un système ou chaque entité aurait son propre login et mot de passe à soumettre auprès du serveur ACS, et que chaque login/mot de passe correspondrait en retour à un jeton SWT avec des niveaux d’accès différents. L’étape suivante vous l’imaginer aisément est la fédération d’identité avec des fournisseurs d’identités en entreprise (on-premise) ou sur le Web tels que Windows Live ID, Google, Yahoo et Facebook. Nous y revenons à la fin de ce tutoriel.

Pour obtenir ce niveau de contrôle d’accès plus granulaire, il va falloir configurer ACS pour prendre en compte les nouvelles identités avec les crédentités associées (nouveaux logins et mot de passe), ainsi que les nouvelles règles de mappage entre les crédentités fournies en entrée et les jetons SWT émis en sortie.

Il va nous falloir aussi légèrement retoucher le code du service de données écris lors du tutoriel précédent.

Configuration d’ACS

Commencez par vous identifier sur le portail de gestion d’ACS.

Une fois identifié, cliquez sur Service identities sur le ruban de gauche.

Sélectionnez acssample et cliquez sur le bouton Delete pour supprimer cette identité.

Maintenant cliquez sur Add pour ajouter la première des trois nouvelles identités que nous allons rajouter.

1. Dans le champ Name, saisissez people.
2. Dans Type, sélectionnez Password.
3. Dans le champ Password, saisissez pass@word1.
4. Cliquez sur le bouton Save pour valider.
5. Cliquez encore une fois sur le bouton Save sur la page Edit Service Identity.

Répétez la même procédure deux fois pour les logins budget et people+budgetet les mots de passe respectifs associés pass@word2 et pass@word3.

Maintenant cliquez sur Rule groups dans le ruban de gauche pour éditer les règles de mappage entre les crédentités fournies en entrée (que vous venez de configurer) et les jetons SWT à émettre en sortie.

Cliquez sur Default Rule Group for XXX pour éditer l’ensemble des règles affectées à votre service de données et supprimez la règle existante.

Cliquez maintenant sur le bouton Add pour générer la première des trois règles :

1. Sous Input claim issuer, sélectionnez Access Control Service.
2. Sous Input claim type, sélectionnez Select type (nameidentifier).
3. Sous Input claim value, saisissez people.
4. Sous Output claim Type, sélectionnez Select type et choisissez authorizationdecision dans la liste déroulante.
5. Sous Output claim value, saisissez people.
6. Cliquez sur le bouton Save pour valider.

Répétez le même processus deux fois, mais cette fois-ci avec les valeurs budget pour le champ Input claim value et budget pour le champ Output claim value pour la première fois. Puis people+budget pour le champ Input claim value et people,budget pour le champ Output claim value pour la seconde fois.

Sur la page Edit Rule Group, cliquez sur Save pour valider les règles.

A ce stade, vous avez fini de configurer ACS. Vous avez ainsi créé les nouvelles identités puis configuré les règles qui seront affectées en sortie au jeton SWT.

Nous allons maintenant pouvoir passer à la retouche du code du service de données OGDI.

Modification du code du service de données OGDI

Commencez par ouvrir votre solution Ogdi.sln dans Visual Studio 2010, puis ouvrez le projet Services_WebRole dans le dossier DataService.

Ouvrez ensuite le fichier Global.asaxet rajoutez la méthode suivante à la classe Global.

private void CheckAuthorization(string claimValue)

{

    string[] values = claimValue.Split(',');

    //Vérification de la structure de l'URL : v1/{OgdiAlias}/{EntitySet}/{*remainder}

    if (Request.Url.AbsolutePath.Split(new[] { '/' }, StringSplitOptions.RemoveEmptyEntries).Length >= 3)

    {

        //Extraction du nom du jeu de données

        string entitySet = Request.Url.AbsolutePath.Split(new[] { '/' }, StringSplitOptions.RemoveEmptyEntries)[2];

        //Si le jeu de données auquel on tente d'accéder n'est pas dans la liste des permissions du jeton,

        //on restreint l'accès.

        if (!values.Contains(entitySet))

        {

            ReturnUnauthorized();

        }

    }

Toujours dans le fichier Global.asax, dans la méthode Application_BeginRequest remplacez les dernières lignes de code :

// vérifier la valeur de la revendication

if (!actionClaimValue.Equals(this.requiredClaimValue))

{

    this.ReturnUnauthorized();

    return;

}

Par la ligne de code suivante :

CheckAuthorization(actionClaimValue);

Et voilà, c’est terminé pour cette extension du tutoriel sur le contrôle d’accès à OGDI avec Windows Azure AppFabric et son service ACS.

Vous pouvez tester les différentes crédentités (logins et mots de passe) avec le client fourni lors du précédent tutoriel et voir par vous-même l’efficacité du contrôle d’accès.

Les principes de base du contrôle d’accès d’ACS n’ont désormais plus de secret pour vous et vous êtes désormais capable de contrôler l’accès à votre service de données et de gérer aussi les autorisations des différents accès.

L’étape suivante consiste à ne plus gérer les identités au niveau d’ACS mais à déléguer au contraire l’authentification à des partenaires de confiance, à savoir des fournisseurs d’identités en entreprise (on-premise) ou sur le Web tels que Windows Live ID, Google, Yahoo et Facebook. Vous rentrez alors pleinement dans la fédération des identités, un domaine pleinement couvert par le contrôle d’accès de Windows Azure AppFabric, avec des fonctions avancées.

Pour décrire tout cela et étendre le scénario ainsi proposé à ce stade, nous vous invitons à consulter le guide A Guide to Claims-Based Identity and Access Control - 2nd Edition sur les chapitres dédiés à ACS.