Comment trouver l’id de son tenant

Question importante lorsque l’on a besoin d’écrire une application devant s’authentifier à Azure AD. Comment trouver l’Id du tenant de l’utilisateur.

Voici une liste de solution possibles.

La première chose à savoir est que cet id peut être fournit sous deux formes:

1. un GUID
2. un hostname (nom de domaine)

Le premier est moins poétique, mais présente l’avantage d’être immuable.

Il existe également une valeur réservée: ‘common’. Elle est utilisée dans les scénarios où votre application est multi-tenante.

http://www.cloudidentity.com/blog/2014/08/26/the-common-endpoint-walks-like-a-tenant-talks-like-a-tenant-but-is-not-a-tenant/

Les modules JavaScript: utilisation pratique

J’ai discuté les différentes architectures de module rencontrées en JavaScript dans un précédent article:

https://amethyste16.wordpress.com/2017/06/24/les-architectures-de-modules-en-javascript/

 

OK, maintenant j’ai créé une série de modules. Comment je les intègre de façon concrète dans un vrai projet?

Il y a je pense 3 options:

1. Les chargeurs de module
2. Les constructeurs de bundle
3. Chargement via des <script>

La première installe dans le site lui-même un chargeur de module, comme par exemple RequireJS, qui s’occupera de charger le module et l’ensemble de ses dépendances.

La deuxième vise à rassembler dans un même fichier le module et l’ensemble de ses dépendances dans l’ordre qui convient. On créée un nouveau fichier, appelons le bundle.js, qui est le résultat de la « bundlelisation ». On n’a alors plus besoin de référencer de chargeurs de module, il suffit de référencer bundle.js directement.

La dernière est la méthode traditionnelle si je puis dire. On a N fichiers *.js à charger, on écrit N déclarations <script> et on gère à la main le bon ordre. C’est très simple, très utilisé, mais peut devenir vite laborieux.

Surtout cette méthode encourage guère à écrire des modules propres, c’est à dire avec une empreinte minimale sur le scope global. Laissons de côté cette méthode qui ne concerne en rien cet article.

Les architectures de modules en JavaScript

Les bonnes pratiques modernes de codage en JavaScript poussent de plus en plus vers la structuration du code en modules. En général on débute avec les modules est via certains patterns comme Revealling Pattern Module (RPM), mais il est important de connaître d’autres architectures plus performantes.

Les 4 plus fréquentes sont les suivants:

1. Revealling Pattern module (UMD)
2. CommonJS
3. AMD
4. Modules ES6

 

RPM est pour l’essentiel l’exploitation des capacités de closure proposées par les fonctions Javascript tandis que les modules ES6 sont des extensions du langage… mais des extensions assez récentes donc pas toujours supportées. On les trouvent mises en œuvre dans TypeScript par exemple.

 

CommonJS et AMD c’est différent, il s’agit de spécifications. Pour les mettre en œuvre on doit utiliser un framework capable de gérer des modules au format CommonJS ou AMD. Différents chargeur de script existent à cet effet, mais certains sont plus typiques que d’autres.

CommonJS est étroitement lié à NodeJS par exemple, tandis que vous profiterez des joies de AMD avec RequireJS ou Angular 1. Mais cela ne se traduit pas par des barrières pour autant. Un chargeur de scripts est après tout lui-même un module.

Par ailleurs, les chargeurs de scripts sont souvent capables de prendre en charge plusieurs formats.

 

Mais pourquoi plusieurs définitions de modules?

C’est une question de choix personnel et les besoins ne sont pas forcément les même d’ailleurs. Les différents formats de modules ne correspondent pas à des bonnes pratiques ou des patterns en tant que tels. Il s’agit simplement d’implémentations différentes de l’idée de module.

Par exemple CommonJS charge les dépendances de façon synchrone ce qui n’est pas une option favorable dans un contexte Web où l’on préfèrera AMD ou ES6. ES6 n’est pas supporté par tous les navigateurs par contre.

 

Je propose de présenter une démonstration complète de ces 3 architectures dans cet article. Au menu:

• Préparation de l’environnement de test
  Projet de test
  Serveur web
• CommonJS
  Démo Node
  Démo Web avec SystemJS
• AMD
  Démo Node avec RequireJS
  Démo Web
• ES6

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.

Au fur et à mesure que la série s’étoffera, je rajouterai quelques lignes dans cet article.

 

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
• Adal

 

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.