Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe


Poster un commentaire

L’authentification fédérée par claims, les grands principes

Jusqu’à récemment les choses étaient simples: les entreprise maîtrisaient et hébergeaient elle-même les applications utilisées par son personnel. Il suffisait donc d’installer un AD quelque part, créer un compte et on pouvait accéder à des dizaines d’applications en se loguant une seule fois très facilement. En tout cas si l’application prend en charge l’authentification Windows!!!!

Les choses sont en train de changer depuis l’arrivée du cloud. Les applications ne sont alors plus gérées par l’entreprise et se trouvent à l’extérieur de son réseau. De nouvelles questions surgissent alors:

  • Comment assurer des services d’authentification sans être obligé de mettre en place un compte pour chaque application?
  • Chaque application cloud peut aussi avoir son propre protocole. Faudra t’il les comprendre et les gérer? Comment alors gérer les identités
  • Que faire lorsqu’une personne quitte l’entreprise? On doit supprimer un nombre indéterminé de compte?
  • Comment donner accès à un partenaire à notre application, comment gérer ses droits, son départ de chez le partenaire?

On voit vite que même dans une petite entreprise utilisant une demi douzaine d’applications le problème devient vite un challenge.

La réponse est la fédération des identités (ou authentification unique). Il s’agit un ensemble de mécanismes, de standards et de patrons bâtis autour des normes WS-* qui définissent différentes façons de partager des informations relatives à l’identité d’un utilisateur entre différentes applications.

Ainsi un organisme, pas forcément votre employeur, joue le rôle de fournisseur d’identité (Identity Provider, Idp ou issuer). Celui est chargé de gérer votre identité et de renvoyer un jeton à l’application demandeuse si l’authentification a réussi. On appelle application par partie de confiance ou Relying Party une telle application.
L’application n’a jamais accès à vos credentials, elle ne verra de vous que les informations que le fournisseur veut bien lui envoyer. Elle sait juste que le fournisseur d’identité auquel elle fait confiant à dit OK.

Notez bien l’utilisation du mot confiance, c’est cela qui est sous-jacent à la solution technique que je vais essayer de décrire dans cet article. Cette relation de confiance est peut aussi s’appeler une relation d’approbation. Elle est établie entre deux domaines d’approbation (trust domain).

 

Le jeton est aussi appelé jeton de sécurité. Il porte les informations sur l’identité d’une personne. Par exemple son nom, son adresse, sa date de naissance… Dans le cadre de cet article on ne considère que les jetons présentés sous la forme d’une collection de claims.

2014-11-22_14-08-45

L’intérêt des jetons par claims est que le format est nettement moins rigide et est évolutif de façon naturelle. Si on a besoin d’un claim supplémentaire, il suffit de l’ajouter ce qui est plus difficile par exemple avec un jeton Kerberos. Reste ensuite à gérer le transfert de ces jetons, il existe différentes solutions:

Protocole Description
SAML SAML 2.0 est un protocole très général: formats de jeton, profil, des protocoles…
WS-Federation Protocole à large portée comme SAML, mais autre implémentation. Protocole spécialisé dans l’authentification des applications Web.
WS-Trust Spécialisé dans l’authentification des services SOAP. WCF par exemple.
OAuth OAuth 2.0 est spécialisé dans la gestion de la délégation d’autorisation de services Web REST. Souvent détourné pour faire de l’authentification.
Open Id Connect Ajoute l’authentification à OAuth.

 

Edit 31/03/2017: J’ai commencé à écrire quelques articles démontrants de façon pratique certains concepts démontrés ici:

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

 

Lire la suite


Poster un commentaire

Gérer l’authentification et les authorisations avec les claims

Il est important de comprendre ce que sont les claims (revendications) pour une raison simple: les outils d’authentification modernes se basent dessus.

En tant que développeur nous y serons inévitablement confrontés.

Je vais essayer de synthétiser tout ce que j’ai pu apprendre à ce sujet. Après tout les claims sont déjà dans nos applications, alors apprenons à manipuler le code qui va avec.

Lire la suite


Poster un commentaire

L’authentification WS-Federation avec Azure Windows Active Directory

Dans un précédent article j’ai montré comment créer une application capable d’exploiter Windows Azure Active Directory (Waad):

https://amethyste16.wordpress.com/2014/08/23/mettre-en-place-lauthentification-avec-visual-studio-2013-partie-ii/

Nous ne sommes pas vraiment allé voir fonctionner le code et nous sommes passé rapidement sur certains détails. Je propose de reprendre cet exemple, mais plus calmement et d’essayer de comprendre son fonctionnement.

Nous allons également voir comment on peut le simplifier considérablement avec OWIN.

 

Avant de lire la suite, il sera peut être profitable de lire l’article de présentation de Waad:

https://amethyste16.wordpress.com/2014/08/21/decouverte-de-windows-azure-active-directory-waad/

Ainsi que le tutoriel qui montre comment créer un tenant Azure:

https://amethyste16.wordpress.com/2014/08/19/provisionner-un-repertoire-azure-active-directory-waad/

Lire la suite


Poster un commentaire

Les jetons JWT, ce qu’un développeur doit connaître

Techniquement un jeton (un token) est simplement une String.
Cette chaîne peut être une suite unique de caractères, mais ce n’est pas le cas le plus intéressant. La plupart du temps les jetons emportent une structure.

On peut mettre beaucoup de choses dans un jeton et donc l’utiliser dans de nombreuses situations. Le principal usage est l’authentification et la gestion des autorisations. Nous allons rester dans ce contexte par la suite. Mais les jetons sont aussi des moyens pratiques pour permettre à des applications d’échanger certaines information de façon sécurisées.

Vous savez qu’il existe deux façons de gérer l’authentification côté serveur d’une application Web.

  1. La création d’un cookie d’authentification
  2. la création d’un jeton d’authentification

 

En pratique nous sommes surtout habitués à manipuler des cookies. Pourquoi changer?

Les jetons apportent une solution plus souple à certaines problématiques, plus particulièrement celle des applications mobiles et de la délégation. C’est donc la voie qui tend de plus en plus à être suivie et en particulier OAuth qui est une norme orientée jeton.

 

JWT (JSON Web Token) est simplement un format de jetons (on prononce comme le mot anglais jot).

Un jeton JWT est une façon de représenter des claims (ou revendication) pour les transférer entre deux parties dans un format compact et compatible uri. Un claim est simplement une collection de paires nom/valeur contenant des informations sur un utilisateur ou tout autre sujet selon l’usage qui est fait du jeton.

Dans un jeton JWT, les claims sont sérialisés en JSON.

Le format d’un jeton JWT est particulièrement bien adapté pour circuler dans une uri et donc pour les applications REST.
JWT est actuellement utilisé par beaucoup de monde et en particulier par Microsoft pour requêter Windows Azure Active Directory via Graph Api. On le rencontre également avec ACS ou le web SSO. Il s’agit également du format standard de OAuth 2 et OpenID Connect.

Comme vous le voyez, en tant que développeur, vous serez amenés à souvent rencontrer JWT. Il est donc important d’avoir quelques lumières à son sujet.

 

Lire la suite