K2 et l’Authentification par revendication (claims)

Claims

L’arrivée de SharePoint 2013 a introduit pour beaucoup d’entre nous la notion d’authentification par revendication. Pour plus d’information concernant les notions d’Identité, d’authentification et d’autorisation, suivez ce lien.

Historiquement, SharePoint 2010 a introduit l’authentification par revendication chez Microsoft, mais NTLM et Kerberos étaient aussi supportés. Dans SP 2013 online, seul l’authentification par revendication persiste. Le format des jetons est spécifique, appelé SAML (pour Security Assertion Markup Language, c’est le seul accepté par K2 et SP). Par ailleurs, K2 fait partie des rares applications à supporter les échanges entre plusieurs versions de SP.

Aussi, avec SP 2013, le modèle App est introduit. C’est la seule solution pour afficher du contenu tiers dans les interfaces de SP. Plus rien n’est installé dans SP (SP 2010 nécessitait l’ajout de features K2). L’App K2 repose sur les SmartObject pour communiquer avec SP, l’authentification au niveau des connecteurs K2  (les instances de Service Broker) est configurée pour utiliser OAuth (authentification par revendication avec un niveau de sécurité associant des droits directs (Trust) entre K2 et SP).

Les Flux dans un scénario d’intégration SharePoint 2013 avec K2.

flux K2 avec SP2013
Le schéma ci-dessus présente les interactions entre le poste client, le serveur K2 et le Fournisseur d’identité. C’est un cas général qui s’applique dans tous les scénarios d’applications dont l’authentification est basée sur les revendication.

Dans un premier temps, le poste client demande au serveur K2 les prérequis d’autorisation nécessaire pour la bonne authentification (1).  Le serveur K2 répond à cette première requête (2).

Ensuite, les informations de l’utilisateurs sont envoyés afin de permettre la demande du jeton claims (3). Le Fournisseur d’identité valide alors la création d’un jeton (4), via le dispositif de sécurité (STS).  Si l’utilisateur est correctement authentifié dans le gestionnaire d’identité (ici l’Identity Manager) alors les informations d’authentification et d’autorisation sont renvoyés au STS (5). Ce dernier génère alors la création d’un jeton qu’il transmet au poste client (6).

Enfin, le jeton est transmis au serveur K2 (7), il est alors passé (8) au Windows Identity Foundation (WIF) afin de résoudre son contenu (9). La validation est alors communiquée à l’application K2 (10) et se termine sous la forme d’un cookie avec les données d’authentification sur le poste du client (11).

Claims-Based Authentication (CBA) ou l’authentification basée sur les revendications

Claim est nécessaire lorsque l’on sort de l’environnement Windows ou lorsque l’on veut accéder à SP 2013. Si la CBA doit être mise en place dans l’entreprise, toutes les applications devront être configurées pour la supporter.
Les avantages du CBA :

  • L’authentification unique ou Single Sign-On (SSO)
  • La possibilité de décentraliser complètement l’architecture de l’infrastructure applicative
  • La Fédération, la possibilité d’avoir plusieurs Fournisseurs d’Identité pour une même application
  • Il n’est plus nécessaire de dupliquer les Identités pour chaque application.

 C’est tout pour cette fois, cheers !

benjamin

Technical Specialist @t K2 France ----- Twitter : @benjaminbertram ----- LinkedIn : Benjamin Bertram

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.