Sécuriser ses applications avec Azure AD: la synthèse

Au fil du temps j’ai rédigé plusieurs articles concernant les questions liées à l’authentification. Ces articles sont nombreux et dispersés un peu partout.

Je pense donc qu’il est temps de réaliser un article de synthèse qui va donner des liens vers les différents articles concernés et proposer quelques informations supplémentaires de contexte.

Des informations de synthèse donc, des liens utiles, mais pas de code ici. Au menu:

• Une vision infra
• Identification, authentification et autorisation
• Quels protocoles d’authentification?
• Les claims
• Les deux types de compte
• Je suis devant Visual Studio, je fais quoi?
• Scénarios OAuth 2
• Les jetons

 

Se connecter à une API REST protégée par Azure AD avec un site web – partie II

L’authentification d’une appli web à une Web Api n’est pas très différent de celle d’une application native. Nous avons vu qu’il y a deux façons de s’authentifier qui se distinguent tant par les protocoles possibles, que les propriétés de la connexion:

1. en tant qu’application
   OAuth 2 uniquement
   Scénario: Client Credentials Grant
2. en tant que délégation d’utilisateur
   OpenId Connect ou OAuth2
   Scénario: Authorization Code Grant

 

Le fait que l’on parle d’une application Web implique toutefois quelques différences d’avec les applications natives puisque plusieurs utilisateurs différents peuvent être connectés simultanément sur la même instance. Il va donc se poser la question de la mise en cache des jetons.

Ce n’est pas un problème pour la connexion comme application qui présente une identité unique à la Web Api, mais nous devrons en tenir compte dans le contexte de la délégation. La délégation d’utilisateur présente par ailleurs l’avantage de pouvoir mettre en place une stratégie de sécurité basée sur les rôles puisque l’on connaît l’utilisateur:

https://amethyste16.wordpress.com/2014/11/11/gerer-lauthentification-et-les-authorisations-avec-les-claims/

Je ne vais pas parler spécialement de ce dernier point dans cet article, mais nous allons voir comment fonctionnent les deux stratégies de connexion de façon concrète. La gestion des rôles n’est pas très difficile à faire ensuite.

Générer une page d’aide pour vos Web Api

C’est une fonctionnalité que j’ai découvert par hasard il y a quelques jours: le template de site Web Api installe également un outil de génération de pages d’aide pour nos Api, pas besoin de Swagger ou autre, c’est automatique.

J’ai voulu en savoir plus, d’où cet article qui explique comment ça marche et comment personnaliser les pages.

Se connecter à une API REST protégée par Azure AD avec un site web – partie I

Je poursuis l’exploration des différents scénarios OAuth2 dans le contexte Azure AD.

Cette fois je vais analyser le cas où le client de la Web Api est une application confidentielle, ce qui est le cas le plus fréquent. Je ferai également la démonstration du dernier scénario d’authentification OAuth2 restant à tester.

• Démonstration du scénario OAuth2 : autorisation implicite (implicit grant)
• La librairie Adal.js

 

Il y a pas mal de choses à dire, je vais donc découper cet article en deux parties.

Lancer Chrome en mode incognito depuis Visual Studio

Vous avez rêvé de lancer Chrome en mode incognito lorsque l’on lance une appli Web.

Et bien c’est possible!

La librairie SMO

Dans un récent projet j’ai eu besoin de restaurer et supprimer des bases de données SQL Server via un code C#.

Comment faire? La solution est l’utilisation de la librairie SMO (SQL Server Management Objects) que j’ai découvert pour l’occasion. Cette librairie fournit tout ce dont on a besoin pour ce genre d’opérations et bien d’autres.

Comme j’ai un peu galéré pour trouver des exemples qui fonctionnent, voici un petit article rapide sur le sujet.

Se connecter à une Api protégée par Azure AD avec une application native

Après avoir vu comment protéger un site Web, nous allons voir comment protéger une Api Rest.

 

On pourrait penser qu’il s’agit de la même chose et de fait il y a de nombreuses similitudes.  Il existe une différence importante, c’est que le client sera assez souvent une application native: console, desktop, appli mobile, test unitaire…

Et cela change un certain nombre de choses vis à vis de OAuth et Azure AD. J’expliquais dans l’article qui précède qu’OAuth2 propose 4 schémas d’authentification. Les schémas supplémentaires sont là, entre autre, pour répondre aux besoins des clients natifs.

Pourquoi cela? On a besoin de distinguer deux types de client:

1. les clients confidentiel (confidential client)
   Clients qui tournent sur un serveur comme une application Web. Ces clients on la capacité de conserver en toute sécurité les identifiants
   Ces clients envoient leur Id et le secret dans les requêtes pour obtenir un jeton
2. les clients public (public client)
   Client qui tourne sur la machine ou le périphérique du client
   Il n’est évidement pas question de placer un secret dans la configuration de ce genre de client. On doit obtenir le jeton de façon indirecte, nous verrons comment

 

Voyez cet article comme la suite de celui-ci:

https://amethyste16.wordpress.com/2017/03/30/proteger-une-application-avec-azure-ad/

Je n’y reprendrai en effet pas certaines explications comme l’inscription dans Azure AD d’une application ou la récupération des configurations.

Au programme :

• Création d’une application de démo
• Configuration de l’authentification dans Azure
• Démonstration des schémas de base d’OAuth2 suivants:
  Schéma autorisation via un code (Authorization Code Grant Flow)
       Schéma Autorisation serveur à serveur (Client Credential Grant Flow)
       Schéma autorisation via mot de passe (Resource owner password grant flow)
• Consentement et permissions

 

Dans cet article je vais rester dans le cadre des applications de type line of business (LOB), c’est à dire  mono-tenantes. Attendez vous à un article plutôt dense techniquement. J’y ai passé pas mal de temps pour aller plus loin qu’un « hello world ».

 

Un dernier point, pour toute la suite, les applications seront inscrites avec un compte admin. cela a des impacts sur la gestion des consentements, mais je ne l’aborde pas dans cet article.