Article original publié le jeudi 16 août 2012

Tout d’abord, permettez-moi de révéler un de mes plaisirs dans l’écriture d’un blog sur les mystères des entrailles de SharePoint : je peux employer un registre des plus familiers, comme le titre de mon article. Il s’agit d’un penchant auquel il est presque impossible d’échapper, sauf si par exemple vous créez une nouvelle version de SharePoint. Voit-on d’amusants messages sociaux SharePoint 2013 ? « Désolé du retard, j’ai presque fini » et autres expressions du genre. Je trouve ça encore plus amusant car c’est parsemé de choses du style le HRESULT obtenu par mon copain Tom l’autre jour. Hmm…Plus ça change, plus c’est pareil. 

Mais revenons à nos moutons. J’ai déjà mentionné une ou deux fois oAuth dans ce blog lorsque j’ai abordé les nouvelles fonctionnalités de SharePoint 2013. Et bien que je ne compte pas vous faire le numéro complet sur la question « oAuth, qu’est-ce que c’est » (nous avons toute une équipe de rédacteurs qui s’y consacre), je vais néanmoins revenir très rapidement sur certaines de ses utilisations. Le meilleur exemple d’une approbation oAuth concerne probablement l’index SharePoint distant pour la recherche : cet index permet à une personne dans une batterie de serveurs d’émettre une requête qui est acheminée vers une autre batterie de serveurs SharePoint, puis, dans cette batterie de serveurs distante SharePoint, il est capable de reconstruire l’identité de l’utilisateur pour que les résultats de recherche puissent être soumis à un découpage de sécurité correct. Il est aussi employé dans d’autres scénarios, comme le nouveau modèle d’application (c.-à-d. cet utilisateur dispose-t-il des droits d’accès au contenu que l’application demande), entre deux applications serveur comme SharePoint et Exchange (cet utilisateur dispose-t-il de droits sur le contenu de la boîte de réception) et beaucoup d’autres. Pour moi, l’index SharePoint distant est un bon exemple car j’estime qu’il s’agit peut-être du meilleur scénario à utiliser pour prévoir pourquoi il faut faire ce qu’on fait pour que tout fonctionne comme prévu. 

Commençons donc par le commencement : comment BatterieA peut-elle « créer un Stéphane » qui ressemble à « Stéphane » sur BatterieA ? Tout commence avec l’application de profil utilisateur. Supposons donc que Stéphane est sur BatterieB et envoie une requête. Cette requête est envoyée à BatterieA, accompagnée d’attributs sur Stéphane. Par défaut, ces attributs vont être l’adresse SMTP de Stéphane, son adresse SIP, son nom de compte et son identificateur de nom. Lorsque BatterieA reçoit cette demande, la première chose qu’elle va faire est une recherche dans son application de profil utilisateur locale ; elle va rechercher un profil qui correspond aux valeurs de Stéphane qui ont été envoyées. C’est pourquoi il est si important de vous assurer que votre application de profil utilisateur est intègre et complétée dans SharePoint 2013 ; c’est aussi la raison pour laquelle j’écris cet article de blog pour y parvenir :  http://blogs.msdn.com/b/sharepoint_fr/archive/2012/09/20/mappage-de-profils-d-utilisateurs-saml-avec-une-importation-depuis-ad-dans-sharepoint-2013.aspx.

Supposons maintenant que BatterieA a trouvé le profil utilisateur de Stéphane. Que va-t-elle en faire ? À partir d’ici, la réponse est « ça dépend ». C’est pourquoi il est donc essentiel de planifier cet aspect de votre organisation. « Ça dépend » en fait du type d’authentification que vous utilisez. Voici comment :

  • Revendications Windows : si vous utilisez les revendications Windows, pour l’essentiel, tout ce dont vous avez besoin se trouve dans le profil utilisateur. Il contient votre nom de compte et vos appartenances de groupe AD. J’expliquerai plus bas ce que j’entends par « pour l’essentiel ». Pour la version courte : si vous utilisez les revendications Windows, vous êtes plutôt bien parti.
  • Revendications d’authentification basée sur les formulaires (FBA) : si vous utilisez cette forme d’authentification, il faut que vous sachiez certains éléments. D’abord, il vous faut une méthode pour remplir votre application de profil utilisateur et la maintenir à jour. Si vous utilisez l’application de profil utilisateur avec les fournisseurs LDAP et votre annuaire est Windows Active Directory, alors vous êtes sur la bonne voie. Vous pouvez créer une connexion de profil vers Active Directory et l’associer simplement au fournisseur d’authentification basée sur les formulaires de la même manière que celle décrite dans l’article dont j’ai indiqué le lien ci-dessus. Dans la plupart des cas cependant, AD ne sera pas votre fournisseur. Autrement dit, vous devrez écrire du code pour remplir l’application de profil utilisateur. Cette opération devrait suffire pour obtenir le seul attribut dont il faut réellement se préoccuper pour les utilisateurs de l’authentification basée sur les formulaires, en l’occurrence le nom de compte. Comme vous le savez, « pour l’essentiel » (là encore, je vais l’expliquer plus bas), le reste de vos données provient de votre fournisseur de rôle. Lorsqu’on réhydrate un utilisateur de l’authentification basée sur les formulaires, on invoque également les fournisseurs de rôles associés : tout se passe alors comme si l’utilisateur de l’authentification basée sur les formulaires s’était connecté localement. Ceci nous permet de récupérer toutes les revendications de rôle d’un utilisateur de l’authentification basée sur les formulaires.
  • Revendications SAML : ce cas est comparable à FBA, dans la mesure où la première chose à faire est de remplir votre application de profil utilisateur. Avec un peu de chance, vos utilisateurs sont dans AD et vous pouvez donc les importer directement en suivant les conseils de l’article de blog en lien ci-dessus. Si la chance n’est pas de votre côté, vous devez trouver un moyen de vous connecter à un annuaire source et d’y effectuer l’importation. Bien entendu, cette affaire est probablement très compliquée avec les revendications SAML, car vous pourriez avoir des annuaires un à plusieurs, voire même ne pas être propriétaire de tous (c.-à-d. il se peut que vous ayez des partenaires, soyez fédérés avec ACS et utilisiez Facebook ou un autre fournisseur, etc.). Quoi qu’il en soit, si vous voulez que ça marche, vous devez trouver un moyen de remplir votre application de profil utilisateur. Il y a pourtant encore un point plus important ici : lorsque vous vous connectez en tant qu’utilisateur SAML, vous obtenez un ensemble de revendications de la part de votre fournisseur d’identité (IdP). Ce processus de réhydratation d’utilisateur n’a aucun moyen de simuler cette connexion. C’est simplement dans la nature de SAML : vous pouvez être redirigé une à plusieurs fois et fournir un nombre quelconque d’invites d’authentification et de types d’authentification (comme l’authentification à deux facteurs) qu’on ne pourra jamais comptabiliser. Qu’est-ce que cela signifie pour vous ? Vous devez vraiment ajouter vos revendications par augmentation de revendications si vous voulez les utiliser pour sécuriser votre contenu et en autoriser l’accès par ce processus de réhydratation d’utilisateur. Vous n’allez pas récupérer de revendications du fournisseur IdP pendant la réhydratation donc si vous les voulez, vous les accordez localement. Il s’agit de l’aspect « pour l’essentiel » que je mentionnais plus haut et que je vais expliquer maintenant.
  • « Pour l’essentiel » : qu’est-ce que cela signifie ? Maintenant, j’espère que c’est plus clair. Que vous soyez un utilisateur de Windows, de l’authentification basée sur les formulaires ou de SAML, en plus des revendications obtenues auprès de votre fournisseur d’authentification, vous pouvez aussi avoir des revendications supplémentaires ajoutées par augmentation : http://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx. L’autre étape à accomplir au cours du processus de réhydratation est d’appeler tous les fournisseurs de revendications personnalisées inscrits, pour pouvoir également récupérer les éventuelles revendications supplémentaires que l’utilisateur réhydraté aurait reçu s’il s’était connecté localement et avait fait appel à ces fournisseurs.

C’est pourquoi j’aime tant le scénario de l’index Remote SharePoint distant pour expliquer la planification nécessaire ici. Comme vous pouvez l’imaginer, dans une batterie de serveurs, vous pouvez accorder des droits au contenu selon un groupe Windows, un rôle d’authentification basée sur les formulaires, une revendication SAML ou toute autre revendication ajoutée par augmentation. Si vous ne possédez pas ces revendications lorsque vous interrogez du contenu, alors ce dernier sera soumis à un découpage de sécurité et vous ne pourrez pas le voir. Vous pouvez donc mesurer à quel point il est important que chaque revendication qui vous est accordée en vous connectant localement vous soit aussi accordée lorsque nous réhydratons une version de vous.

Il faut beaucoup de planification pour que tout cela marche, donc j’espère que cet article va vous aider à déterminer les principaux éléments pour que vous sachiez sur quoi focaliser votre attention.

Cet article de blog est une traduction. Vous trouverez la version originale à l’adresse OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That and What do I Need to Know