Authentification à distance dans SharePoint Online à l’aide de l’authentification basée sur les revendications

Résumé :  Découvrez comment s’authentifier auprès de Microsoft SharePoint Online dans les applications clientes à l’aide des modèles objets côté client de SharePoint.

Dernière modification : mercredi 22 avril 2015

S’applique à : Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Dans cet article
Présentation de l’authentification à distance dans SharePoint Online à l’aide de l’authentification basées sur les revendications
Vue d’ensemble rapide de l’authentification SharePoint
Évolution de l’authentification basée sur les revendications
Séquence d’authentification basée sur les revendications SharePoint
Utilisation du modèle objet client pour l’authentification à distance dans SharePoint Online
Examen de l’exemple de projet de code
Conclusion
À propos de l’auteur
Ressources supplémentaires

Fourni par :  Robert Bogue, Thor Projects, LLC (MVP Microsoft SharePoint)

Table des matières

• Présentation de l’authentification à distance dans SharePoint Online à l’aide de l’authentification basées sur les revendications

• Vue d’ensemble rapide de l’authentification SharePoint

• Évolution de l’authentification basée sur les revendications

• Séquence d’authentification basée sur les revendications SharePoint

• Utilisation du modèle objet client pour l’authentification à distance dans SharePoint Online

• Examen de l’exemple de projet de code

• Conclusion

• Ressources supplémentaires

• À propos de l’auteur

  Télécharger du code : Authentification à distance dans SharePoint Online à l’aide du modèle objet client

Présentation de l’authentification à distance dans SharePoint Online à l’aide de l’authentification basées sur les revendications

La décision de s’en remettre aux services basés sur le Cloud, tels que Microsoft SharePoint Online, n’est pas une décision à prendre à la légère et est souvent entravée par le problème de l’accès aux données de l’entreprise pour des besoins internes. Dans cet article, je vais traiter ce problème majeur en fournissant une structure et un exemple de code permettant de créer des applications clientes capables d’authentifier à distance les utilisateurs auprès de SharePoint Online à l’aide du modèle objet côté client de SharePoint 2010.

Je passerai en revue les méthodes d’authentification de SharePoint 2010, fournirai des détails sur certaines opérations de SharePoint 2010 avec l’authenthification basée sur les revendications, puis décrirai une approche permettant de développer un ensemble d’outils pour autoriser l’authentification à distance sur le serveur afin de l’utiliser avec le modèle objet côté client.

Vue d’ensemble rapide de l’authentification SharePoint

Dans Office SharePoint Server 2007, il existait deux types d’authentifications : l’authentification Windows, qui reposait sur les informations d’identification transmises via les en-têtes HTTP, et l’authentification basée sur les formulaires. L’authentification basée sur les formulaires utilisait les rôles et l’appartenance de Microsoft ASP.NET pour gérer les utilisateurs et les rôles (ou groupes). Cela représentait une grande amélioration en matière d’authentification dans la version 2003 des technologies SharePoint, laquelle reposait exclusivement sur l’authentification Windows. Toutefois, il restait difficile d’accomplir de nombreux scénarios, tels que l’authentification fédérée et l’authentification unique.

Pour se rendre compte de l’inconvénient de compter uniquement sur l’authentification Windows, imaginez un environnement qui n’utilise que l’authentification Windows. Dans cet environnement, les utilisateurs, dont les ordinateurs ne sont pas joints au domaine et dont la configuration n’est pas définie de sorte à transmettre automatiquement les informations d’identification, sont invités à entrer les informations d’identification pour chaque application Web auxquelles ils accèdent, ainsi que pour chaque programme auxquels ils accèdent à partir de ces applications. Par exemple, s’il existe un intranet basé sur SharePoint sur intranet.contoso.com et que Mes Sites se trouvent sur my.contoso.com, les utilisateurs doivent entrer leurs informations d’identification à deux reprises. S’ils ouvrent un document Microsoft Word sur chaque site, ils sont invités à les entrer deux fois de plus, et encore deux fois de plus pour Microsoft Excel. Il est donc évident qu’il ne s’agit pas ici de la meilleure expérience utilisateur.

Toutefois, si le même réseau utilise l’authentification basée sur les formulaires, une fois que les utilisateurs sont connectés à SharePoint, ils ne sont pas invités à s’authentifier auprès d’autres applications telles que Word et Excel. Par contre, ils le sont sur chacune des deux applications Web.

Les systèmes de connexion fédérée comme Windows Live ID existaient déjà, mais les intégrer à Office SharePoint Server 2007 était difficile. Le mécanisme basé sur les formulaires était essentiellement conçu pour s’authentifier auprès d’utilisateurs locaux, ce qui veut dire qu’il ne l’était pas pour authentifier les identités selon un système fédéré. Dans SharePoint 2010, le problème a été contourné en ajoutant un support direct pour l’authentification basée sur les revendications. Cela permet à SharePoint 2010 de s’appuyer sur une tierce partie pour authentifier les utilisateurs et fournir les informations sur leurs rôles.

Évolution de l’authentification basée sur les revendications

Étant donné que les ordinateurs sont conçus pour servir à plusieurs utilisateurs, les autorisations ont toujours représenté un challenge. D’abord, le système d’exploitation validait l’utilisateur. Ensuite, il disait à l’application qui était l’utilisateur. Il s’agissait de la toute première revendication, effectuée par le système d’exploitation pour l’application. L’essence de cette revendication était l’identité de l’utilisateur. Le système d’exploitation avait identifié l’utilisateur, probablement grâce à un mot de passe que l’utilisateur avait fourni. L’application n’avait pas à établir qui était l’utilisateur, elle faisait tout simplement confiance au système d’exploitation.

Ce processus d’authentification fonctionnait bien jusqu’à ce que les utilisateurs aient besoin d’utiliser des applications sur des systèmes auxquels ils ne s’étaient pas connectés. À partir de là, les applications durent procéder à leur propre authentification. Elles commencèrent en utilisant la même approche que les systèmes d’exploitation, c’est-à-dire en exigeant un nom d’utilisateur et un mot de passe. Ce type d’authentification fonctionne bien, mais il requiert que chaque application valide le nom d’utilisateur et le mot de passe. Gérer plusieurs bases de données d’authentification distinctes devint problématique, car les utilisateurs souhaitaient entrer le même nom d’utilisateur et le même mot de passe pour toutes les applications.

Créer des comptes avec le même nom d’utilisateur et le même mot de passe est un problème gérable. Cependant, au fur et à mesure que la question de la sécurité prenait de l’ampleur, la nécessité pour les utilisateurs de changer leur nom d’utilisateur et leur mot de passe régulièrement aboutit à une situation ingérable, dans laquelle les utilisateurs trouvaient difficile de continuer à synchroniser leur mot de passe entre les différentes applications. Des mécanismes d’authentification partagée furent développés pour résoudre ce problème. Une fois encore, les applications durent s’appuyer sur une tierce partie pour authentifier les utilisateurs.

L’approche la plus connue en matière de base de données d’authentification partagée est l’approche qui utilise le protocole Kerberos. Le protocole Kerberos fournit des mécanismes qui permettent aux utilisateurs de s’authentifier auprès d’un serveur centralisé, puis transmet leur identité via un ticket signé par ce même serveur. L’avantage de cette approche est que le serveur centralisé est le seul qui doit connaître le mot de passe de l’utilisateur ainsi que toute autre information d’identification. Cette approche fonctionne bien pour fournir des informations d’identification, mais elle repose sur un seul espace de stockage pour l’identité des utilisateurs.

Aujourd’hui, certains utilisateurs de votre application utilisent des identités que vous ne contrôlez pas. Prenons l’exemple d’une entreprise qui fournit des services de paie ou de plan de retraite pour d’autres entreprises. Ces mêmes entreprises doivent probablement accepter des utilisateurs qui appartiennent à de nombreuses autres entreprises et qui ne nécessitent pas de s’authentifier individuellement. La seule chose qu’ils doivent savoir est que l’entreprise avec laquelle ils ont un contrat peut identifier les utilisateurs. Dans le cas présent, il n’existe pas de serveur centralisé pour les authentifications ; il n’existe pas non plus d’entité centralisée capable de valider chaque utilisateur.

De même, si vous avez un site Web extranet conçu pour être utilisé par plusieurs partenaires, vous ne voulez peut-être pas gérer les comptes d’utilisateurs de tous les employés de vos partenaires, ni même laisser les partenaires le faire. En fait, vous voulez juste prendre la revendication de l’identité des utilisateurs émise par le serveur distant.

Il s’agit là d’une des grandes fonctionnalités d’une connexion basée sur les revendications. Un autre système, en lequel votre propre système a confiance, fournit une revendication de l’identité des utilisateurs.

Il existe de nombreuses normes, telles que WS-Federation, WS-Security et WS-Trust, qui définissent comment ce type d’arrangement doit fonctionner. La norme WS-Federation est la plus appropriée parce qu’elle décrit une approche spécifique de l’échange de l’authentification fédérée. SharePoint 2010 implémente la norme WS-Federation, tout comme de nombreux autres produits Microsoft et non-Microsoft. Cela signifie que l’implémentation de revendications SharePoint peut communiquer avec de nombreux autres systèmes.

En plus des informations d’authentification décrites plus haut, il existe la possibilité pour l’infrastructure d’émettre d’autres revendications sur les utilisateurs, notamment sur les propriétés de profil comme le nom et l’adresse de messagerie. La revendication peut également inclure les rôles, ou groupes, auxquels appartiennent les utilisateurs. Du coup, les applications, y compris SharePoint 2010, peuvent utiliser ce que le fournisseur de revendications ( ou « partie émettrice ») reconnaît comme fiable sur les utilisateurs et définir ainsi des autorisations sur les rôles qui seront transmises dans le jeton de revendications.

La capacité d’une revendication à transmettre plus qu’une simple identité exige d’appliquer des règles sur les types de revendications qu’une application acceptera d’une tierce partie. La norme WS-Trust accepte l’idée qu’une tierce partie puisse compter sur une autre tierce partie, comme décrit précédemment. En outre, elle autorise le principe de chaîne d’approbation selon laquelle une application, telle que SharePoint 2010, fait confiance à un fournisseur interne, tel que Services ADFS (Active Directory Federation Services) 2.0, qui, à son tour, fait confiance à une autre tierce partie voire même à plusieurs. ADFS 2.0 crée son propre jeton de revendications pour SharePoint, en se basant sur les informations qu’il a reçues de la partie émettrice en laquelle il a confiance. Point particulièrement utile, car ADFS 2.0 est un moteur de transformation de revendications. Par exemple, il peut changer une revendication, telle qu’une propriété, en une autre revendication, telle qu’une appartenance à un rôle. ADFS 2.0 peut également filtrer les revendications émises par une tierce partie afin d’empêcher celle-ci de transmettre une revendication à l’application dont l’utilisateur est l’administrateur.

Séquence d’authentification basée sur les revendications SharePoint

Maintenant que nous connaissons les avantages de l’authentification basée sur les revendications, nous pouvons examiner ce qui se passe concrètement lorsque vous utilisez un système de sécurité basé sur les revendications dans SharePoint. Lorsque vous faites appel à une authentification classique, vous vous attendez à ce que SharePoint émette un code d’état HTTP 401 au client, indiquant les types d’authentifications HTTP que le serveur prend en charge. Toutefois, en mode revendications, une interaction plus complexe se produit. Voici ci-après une description détaillée de la séquence que SharePoint réalise lorsqu’il est configuré à la fois pour l’authentification Windows et Windows Live ID via des revendications.

1. L’utilisateur sélectionne un lien sur le site sécurisé et le client transmet la demande.

2. Le serveur répond avec un code d’état HTTP 302, indiquant une redirection temporaire. La page de destination est /_layouts/authenticate.aspx, avec un paramètre de chaîne de requête Source qui contient l’URL source relative du serveur que l’utilisateur a initialement demandé.

3. Le client demande /_layouts/authenticate.aspx.

4. Le serveur répond avec une redirection temporaire 302 vers /_login/default.aspx avec un paramètre de chaîne de requête ReturnUrl qui inclut la page d’authentification et sa chaîne de requête.

5. Le client demande la page /_login/default.aspx.

6. Le serveur répond avec une page qui invite l’utilisateur à sélectionner la méthode d’authentification. Il agit ainsi parce qu’il est configuré pour accepter les revendications de plusieurs services d’émission de jeton de sécurité, notamment le service intégré de SharePoint et le service de Windows Live ID.

7. L’utilisateur sélectionne le fournisseur de connexion approprié dans la liste déroulante et le client publie la réponse sur /_login/default.aspx.

8. Le serveur répond avec une redirection temporaire 302 vers /_trust/default.aspx avec un paramètre de chaîne de recherche trust avec le fournisseur d’approbation que l’utilisateur a sélectionné, un paramètre ReturnUrl qui inclut la page authenticate.aspx, ainsi qu’un paramètre de chaîne de requête supplémentaire avec encore la source. La source fait toujours partie du paramètre ReturnUrl.

9. Le client suit la redirection et obtient /_trust/default.aspx.

10. Le serveur répond avec une redirection temporaire 302 vers l’URL du fournisseur d’identités. Dans le cas de Windows Live ID, l’URL est https://login.live.com/login.srf, accompagnée d’une série de paramètres qui identifient le site vers Windows Live ID et d’un paramètre wctx qui correspond à la chaîne de requête ReturnUrl déjà fournie.

11. Le client et le serveur itèrent un échange d’informations en se basant sur l’opération de Windows Live ID puis sur l’utilisateur, pour donner au final une publication sur /_trust/default.aspx, qui a été configurée dans Windows Live ID. Cette publication inclut un jeton SAML (Security Assertion Markup Language) qui contient l’identité de l’utilisateur et la signature Windows Live ID, laquelle indique que l’identité est correcte.

12. Le serveur répond avec une redirection vers /_layouts/authenticate.aspx, fourni au départ comme URL de redirection dans le paramètre de chaîne de requête ReturnUrl. Cette valeur revient du fournisseur de demandes en tant que wctx sous la forme d’une variable de publication de formulaire. Au cours de la redirection, la page /_trust/default.aspx écrit au moins deux cookies d’authentification chiffrés et codés qui sont retransmis à chaque demande sur le site Web. Ces cookies se composent d’un ou plusieurs cookies FedAuth et d’un cookie rtFA. Les cookies FedAuth autorisent l’autorisation fédérée tandis que le cookie rtFA autorise la déconnexion de l’utilisateur de tous les sites SharePoint, même si le processus de déconnexion démarre d’un site non-SharePoint.

13. Le client demande /_layouts/authenticate.aspx avec un paramètre de chaîne de requête de l’URL source.

14. Le serveur répond avec une redirection temporaire 302 vers l’URL source.

Cookies d’authentification de SharePoint Online

Un point important de ce processus, celui-là même qui rend difficile mais pas impossible l’utilisation de l’authentification à distance pour SharePoint Online dans les applications côté client, est que les cookies FedAuth sont écrits avec une balise HTTPOnly. Cette balise est conçue pour empêcher les attaques par script de site à site (XSS, cross-site scripting). Dans une attaque par script de site à site, un utilisateur malveillant injecte un script qui transmet ou utilise des cookies disponibles sur la page active à des fins de nuire. La balise HTTPOnly sur le cookie empêche Internet Explorer d’autoriser l’accès à ce cookie par le biais d’un script de site à site. Microsoft .NET Framework reconnaît également la balise HTTPOnly, ce qui rend impossible la récupération du cookie directement depuis le modèle objet .NET Framework.

Utilisation du modèle objet client pour l’authentification à distance dans SharePoint Online

Lorsque vous souhaitez utiliser le modèle objet côté client SharePoint pour procéder à une authentification à distance, la première étape consiste à obtenir un objet ClientContext. C’est précisément cet objet de contexte client qui lie les autres opérations du modèle objet au serveur et au site spécifié. Dans un scénario d’authentification HTTP Windows, le contexte client se comporte de la même manière qu’Internet Explorer, à savoir qu’il transmet automatiquement les informations d’identification sur le serveur si celui-ci se trouve dans la zone intranet. Dans la plupart des cas, cela fonctionne correctement. Le serveur traite les informations d’identification et authentifie automatiquement les utilisateurs.

Dans un environnement d’authentification basée sur les formulaires, il est également possible d’utiliser l’objet FormsAuthenticationLoginInfo pour fournir une authentification basée sur les formulaires au serveur. Toutefois, cela ne fonctionne que pour l’authentification basée sur les formulaires. Cela ne fonctionne pas dans les scénarios de revendications basées sur la fédération, car SharePoint ne dispose pas de l’actuel processus d’authentification.

Créer un objet ClientContext authentifié est une procédure qui se compose de plusieurs étapes. Pour commencer, l’utilisateur doit être en mesure de se connecter au système distant de manière interactive. En premier lieu, l’utilisateur se connecte à SharePoint via le fournisseur d’authentification fédérée et SharePoint doit émettre ses cookies d’authentification. En deuxième lieu, le code doit récupérer les cookies d’authentification. En troisième lieu, ces cookies doivent être ajoutés à l’objet ClientContext.

Autoriser la connexion utilisateur pour l’authentification à distance

Le .NET Framework inclut un objet System.Windows.Forms.WebBrowser conçu pour autoriser l’utilisation d’un navigateur Web au sein d’une application. Pour autoriser l’utilisateur à se connecter au fournisseur d’authentification fédérée, cet objet doit être crée et affiché. Le but est, toutefois, de récupérer les cookies d’authentification émis par SharePoint Online. Pour savoir quand le processus de connexion est terminé, vous devez inscrire un gestionnaire sur l’événement Navigated. Cet événement se déclenche une fois que le navigateur a fini de naviguer. Le gestionnaire d’événements attend que l’utilisateur soit renvoyé à l’URL à partir de laquelle il avait commencé sa navigation. Une fois fait, le code sait que l’utilisateur a terminé la séquence de connexion.

Récupérer les cookies d’authentification SharePoint

Étant donné que les cookies FedAuth sont écrits avec une balise HTTPOnly, ils ne sont pas accessibles du .NET Framework. Pour récupérer les cookies, un appel doit être effectué à WININET.dll. Le .NET Framework peut appeler des méthodes DLL basées sur COM via PInvoke (appel de code non managé). Dans le cas qui nous intéresse, la méthode à appeler est InternetGetCookieEx. Cette méthode peut retourner des cookies normaux et des cookies avec la balise HTTPOnly. Attention, elle ne fonctionne qu’à partir d’Internet Explorer 8. Une fois que le cookie est récupéré, il doit être ajouté au contexte client.

Pour plus d’informations sur PInvoke, voir Appel à des fonctions natives à partir de code managé.

Ajouter des cookies d’authentification SharePoint à l’objet ClientContext

La dernière étape consiste à récupérer les cookies d’authentification de la connexion utilisateur et de les attacher au contexte client. Malheureusement, il n’existe aucun moyen direct d’ajouter des cookies à la demande. Par contre, il existe un événement, ExecutingWebRequest, qui est appelé avant que l’objet ClientContext ne fasse une demande au serveur. En ajoutant un gestionnaire d’événements à cet événement, vous pouvez ajouter un nouvel en-tête de demande avec les cookies d’authentification. Une fois terminé, l’objet ClientContext peut être utilisé normalement, et le reste du code ignore complètement que l’authentification est basée sur une authentification fédérée.

Examen de l’exemple de projet de code

L’exemple de code qui accompagne cet article illustre cette technique d’ajout des cookies d’authentification SharePoint à l’objet ClientContext. Il inclut un ensemble de classes que vous pouvez utiliser pour effectuer une authentification fédérée des utilisateurs. Vous pouvez commencer par l’exemple de programme pour voir quels sont les changements que vous devez faire lorsque vous utilisez ce code, par rapport à l’utilisation d’un serveur Web authentifié HTTP.

Exemple d’application client avec authentification SharePoint Sp_Ctx

Le projet Sp_Ctx est un programme de ligne de commande qui utilise un objet ClientContext SharePoint pour extraire des informations sur la page web vers lequel le contexte pointe.

Le projet fait référence à la bibliothèque ClaimsAuth mais à part ça, c’est le même. En fait, le code principal est presque identique au code que vous trouveriez dans une application cliente standard.

01: static void Main(string[] args)
02: {
03:   if (args.Length < 1) { Console.WriteLine("SP_Ctx <url>"); return; }
04:   string targetSite = args[0];
05:   using (ClientContext ctx = ClaimClientContext.GetAuthenticatedContext(targetSite))
06:   {
07:     if (ctx != null)
08:     {
09:       ctx.Load(ctx.Web); // Query for Web
10:       ctx.ExecuteQuery(); // Execute
11:       Console.WriteLine(ctx.Web.Title);
12:     }
13:   }
14:   Console.ReadLine();
15: }

Dans ce code, la seule différence que vous trouveriez par rapport à une application cliente standard est à la ligne 05. Au lieu de créer un nouvel objet ClientContext, nous appelons ClaimClientContext.GetAuthenticatedContext. La grande différence est qu’appeler ClaimClientContext.GetAuthenticatedContext affiche un formulaire pour permettre à l’utilisateur de fournir ses informations d’identification au système distant, capture les cookies d’authentification nécessaires pour authentifier les demandes, et ajoute cet en-tête au contexte client.

ClaimClientContext dans l’exemple d’authentification de SharePoint Online

En examinant la prochaine couche du code, remarquez l’objet ClaimClientContext qui a été appelé. Sont présentes deux méthodes, qui correspondent à celles utilisées dans l’exemple, GetAuthenticatedContext et GetAuthenticatedCookie. GetAuthenticatedCookie est appelé par GetAuthenticatedContext. En réalité, GetAuthenticatedContext appelle GetAuthenticatedCookie pour obtenir les cookies, puis les encapsule dans un contexte.

GetAuthenticatedCookie ouvre la boîte de dialogue qui affiche le site Web et regarde la demande d’authentification s’effectuer de manière à pouvoir par la suite récupérer les cookies d’authentification.

ClaimsWebAuth dans l’exemple d’authentification de SharePoint Online

La classe ClaimsWebAuth obtient les cookies d’authentification. Elle encapsule un formulaire et un objet WebBrowser. La première étape, effectuée pendant la construction de l’objet, consiste à réunir les pages de connexion et de fin de navigation. C’est la méthode GetClaimParams qui s’en charge en faisant une demande Web avec une méthode OPTIONS HTTP.

Lorsque la méthode Show est appelée, l’objet WebBrowser est créé et un gestionnaire d’événements est ajouté pour l’événement Navigated. Ce même événement est appelé chaque fois que l’objet WebBrowser a fini de naviguer. Le gestionnaire d’événements détecte lorsque le navigateur Web est arrivé à l’URL de fin de navigation. Le récepteur d’événements appelle CookieReader, lequel lit WinINET pour obtenir le cookie FedAuth HTTPOnly.

Avec le récepteur d’événements en place, WebBrowser est parcouru jusqu’à l’URL de connexion et le processus d’authentification commence. Une fois terminé, les cookies d’authentification sont renvoyés à l’appelant.

CookieReader dans l’exemple d’authentification de SharePoint Online

La dernière partie de l’exemple de code concerne la classe CookieReader, qui contient l’appel à WinINET.dll et une fonction d’assistance pour obtenir le cookie. La fonction d’assistance, nommée GetFedAuthCookie, retourne une chaîne qui représente le cookie sous la forme « Name=Value ». GetFedAuthCookie appelle la méthode WinINET.dll InternetGetCookieEx pour récupérer le cookie.

InternetGetCookieEx retourne false si la taille de la mémoire tampon de la chaîne qui est passée n’est pas assez grande. Elle définit également le paramètre de la taille de la mémoire tampon dont elle a besoin. En conséquence, GetFedAuthCookie devra peut-être appeler InternetGetCookieEx deux fois pour obtenir la valeur du cookie, si la mémoire tampon initiale est trop petite.

Conclusion

Cet article décrit comment effectuer une authentification basée sur les revendications pour Microsoft SharePoint Online dans les applications clientes en utilisant des modèles objets côté client de SharePoint 2010. SharePoint Online propose une option intéressante et adaptable pour les entreprises qui veulent utiliser la plateforme de collaboration de SharePoint en évitant les coûts de fonctionnement associés à l’hébergement de logiciels sur site. Par ailleurs, avec les techniques que nous avons abordées dans cet article, les développeurs peuvent utiliser les modèles objets côté client de SharePoint pour créer des applications clientes capables de procéder à une authentification à distance sur SharePoint Online.

À propos de l’auteur

Robert Bogue fait partie du programme MVP Microsoft depuis 8 ans. Son dernier livre en date est The SharePoint Shepherd’s Guide for End Users. Rendez-vous sur http://www.SharePointShepherd.com pour en savoir plus sur ce livre. Le blog de Robert se trouve à l’adresse http://www.thorprojects.com/blog. Vous pouvez le contacter à l’adresse Rob.Bogue@thorprojects.com.

Ressources supplémentaires

Pour plus d’informations sur l’authentification à distance dans SharePoint Online à l’aide de l’authentification basée sur les revendications, consultez les ressources suivantes :

• Télécharger du code : Authentification à distance dans SharePoint Online à l’aide du modèle objet côté client

• Référence générale SharePoint Online

• Conseils relatifs aux revendications 1 : authentification basée sur les revendications dans SharePoint 2010

• Développement général de SharePoint