Intégrer SharePoint 2010/2013

Comment intégrer SharePoint 2010/2013, y compris la configuration, le dépannage, l’accès aux journaux et les prochaines étapes.

Auth0 peut simplifier considérablement le processus d’authentification pour SharePoint. Dans ce tutoriel, vous apprendrez à ajouter l’authentification unique (SSO) à SharePoint à l’aide d’Auth0. Vos utilisateurs pourront se connecter avec n’importe lequel de nos fournisseurs d’identité sociaux (Facebook, X, Github, etc.), fournisseurs Enterprise (LDAP, Active Directory, ADFS, etc.) ou à l’aide d’un nom d’utilisateur et mot de passe.

Auth0 ne prend plus en charge le fournisseur Auth0Claims pour SharePoint 2010 / 2013. Ce package est obsolète pour les tenants existants et n’est pas offert pour les nouveaux tenants.

​

Configuration

​

Étape 1. Ajout de l’intégration à votre compte

La première chose à faire est d’aller dans la section Intégrations SSO du Dashboard et de choisir SharePoint dans la liste des applications.

​

Étape 2. Suivez la documentation interactive

Si votre serveur SharePoint n’a pas accès à Internet, téléchargez manuellement les fichiers d’installation. (En savoir plus sur l’installation hors ligne).

Dans l’onglet Settings, vous devrez saisir l’URL de la SharePoint Web Application et l’URL externe (généralement le point de terminaison Internet dans vos Alternate Access Mappings).

La documentation interactive commence d’abord par l’installation des Auth0 CmdLets pour SharePoint :

Une fois l’installation terminée, vous pourrez activer ou désactiver Auth0 et le Claims Provider pour les différentes Web Applications. Vous devrez activer l’authentification avec Auth0 :

Installez ensuite le Claims Provider afin de vous assurer que le People Picker et les permissions fonctionnent correctement :

Une fois ces scripts exécutés, vous terminerez la configuration dans l’Administration centrale :

Notez que l’appel à Enable-Auth0 peut être adapté pour :

• Modifier l’identifiant unique des utilisateurs (comme l’adresse courriel ou un user ID)
• Permettre la transmission de claims supplémentaires à SharePoint
• Activer ou désactiver Windows Authentication par défaut

L’exemple suivant ajoute également le claim Role au mappage des claims et autorise Windows Authentication :

Enable-Auth0
  -auth0Domain:"fabrikam.auth0.com"
  -clientId:"bOFty3tWgpijnwMcltysNFqHgO1ziz1I"
  -webAppUrl:"http://fabrikam-sp/"
  -identifierClaimType:"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  -claims:@(
    "Email|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
    "Role|http://schemas.microsoft.com/ws/2008/06/identity/claims/role", "Client ID|http://schemas.auth0.com/clientID",
    "Given Name|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
    "Surname|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "Picture|http://schemas.auth0.com/picture")
  -allowWindowsAuth

​

Étape 3. SharePoint est maintenant configuré

Vous avez configuré SharePoint pour utiliser Auth0 comme courtier SSO. Lorsque vos utilisateurs visiteront votre site, ils verront une page de connexion affichant toutes les connections activées pour cette application.

Selon les claims qui ont été mappés lors de l’installation du Claims Provider, ces renseignements supplémentaires seront aussi disponibles dans la page des paramètres personnels de l’utilisateur :

Notez que vous pouvez adapter la commande Enable-Auth0 pour :

• Modifier l’identifiant unique des utilisateurs (comme le courriel ou un ID utilisateur)
• Permettre de transmettre des claims supplémentaires à SharePoint
• Activer ou désactiver la Windows Authentication par défaut

Cet exemple ajoute aussi le claim Role au mappage des claims et permet la Windows Authentication :

Enable-Auth0
  -auth0Domain:"fabrikam.auth0.com"
  -clientId:"bOFty3tWgpijnwMcltysNFqHgO1ziz1I"
  -webAppUrl:"http://fabrikam-sp/"
  -identifierClaimType:"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  -claims:@(
    "Email|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
    "Role|http://schemas.microsoft.com/ws/2008/06/identity/claims/role", "Client ID|http://schemas.auth0.com/clientID",
    "Given Name|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
    "Surname|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "Picture|http://schemas.auth0.com/picture")
  -allowWindowsAuth

SharePoint utilisera désormais Auth0 comme courtier SSO.

​

Personnaliser la page de connexion

Vous pouvez personnaliser la page de connexion en suivant les instructions d’Auth0 Universal Login.

Vous voudrez peut-être offrir aux utilisateurs un moyen de s’authentifier dans SharePoint à l’aide de Windows Authentication, en contournant Auth0. Pour ce faire, personnalisez la page de connexion et ajoutez un lien vers l’endpoint Windows Authentication (généralement semblable à https://yoursharepointserver/_windows/default.aspx?ReturnUrl=/_layouts/15/Authenticate.aspx).

Une façon de procéder consiste à utiliser jQuery pour modifier le widget Lock et ajouter un lien vers l’endpoint Windows Authentication.

Vous devez ajouter une référence à jQuery au début de la section <body> de la page de connexion personnalisée.

<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js"></script>

Avant d’appeler lock.show(), ajoutez du code pour modifier le DOM HTML afin d’y ajouter le lien.

// construire Lock
// var lock = ...
[...]
// Un ou plusieurs ID client SharePoint pour lesquels vous souhaitez
// un bouton d'authentification Windows
var sharepointClientIDs = ['your_sharepoint_client_id'];

if (sharepointClientIDs.indexOf(config.clientID) >= 0) {
  lock.on('signin ready', function() { 
    var getParameterByName = function(name) {
      name = name.replace(/[\[]/, "\\\[").replace(/[\]]/, "\\\]");
      var regexS = "[\\?&]" + name + "=([^&#]*)";
      var regex = new RegExp(regexS);
      var results = regex.exec(window.location.search);
      if (results == null) return null;
      else return results[1];
    };
    // récupérer l'hôte à partir de l'URL de rappel
    var parser = document.createElement('a');
    parser.href = config.callbackURL;
    var host = parser.host;
    var windowsAuthURL = "https://" + host + "/_windows/default.aspx?ReturnUrl=/_layouts/15/Authenticate.aspx";
    var wctx = getParameterByName("wctx");
    if (wctx) {
      windowsAuthURL += "&Source=" + wctx;
    }

    $('.auth0-lock-tabs-container') 
    .after('<div><p class="auth0-lock-alternative" style="padding:5px 0;">' + 
      '<a class="auth0-lock-alternative-link" ' + 
      'href="'+ windowsAuthURL + '">' +
      'Login with Windows Authentication!!!</a>' + 
      '</p><p><span>or</span></p></div>').attr('href','https://nowhere');
  });
}

lock.show();

​

Dépannage

Lorsque vous travaillez avec des claims supplémentaires et l’autorisation, il peut toujours s’avérer utile de consulter les claims de l’utilisateur actuel. L’article Claims Viewer Web Part du professionnel Microsoft Liam Clearly peut être utilisé pour dépanner tout problème lié aux claims de l’utilisateur :

​

Journaux de SP2010

Les erreurs et les avertissements sont consignés dans le Unified Logging Service de SharePoint, et des outils comme ULS Viewer peuvent être utilisés pour résoudre les problèmes que vous pourriez rencontrer lors de l’utilisation du Claims Provider.

Pour en savoir plus sur ULS View et obtenir les spécifications, consultez la documentation Microsoft ULS Viewer.

​

Journaux dans SP2013

Pour SharePoint 2013, nous n’utilisons plus le Unified Logging Service pour nos journaux; nous sommes plutôt passés à Event Tracing for Windows. Cela offre un meilleur rendement et vous donne plusieurs façons de capturer tous les événements consignés.

Pour consulter les journaux en temps réel, vous pouvez télécharger le Logs Processor d’Auth0 depuis Github. Exécutez cet outil sur vos serveurs SharePoint pour voir chaque requête que SharePoint envoie au Claims Provider :

​

Prochaines étapes

​

Autorisation

Les claims transmis par Auth0 peuvent aussi servir à l’autorisation dans SharePoint. Par exemple, un utilisateur dont la revendication Role contient Fabrikam HR devrait avoir accès à un site précis ou y être Contributor.

Prenons Azure AD comme exemple. Dans cet annuaire infonuagique, les utilisateurs peuvent faire partie de groupes, et David fait partie de Fabrikam HR.

Lorsque David se connecte avec son compte Azure AD (et que l’attribut Security Groups est activé pour cette connection), les appartenances aux groupes sont stockées dans l’attribut groups du profil de l’utilisateur.

Si nous voulons rendre ces groupes disponibles comme Roles dans SharePoint, nous devrons écrire une Rule qui les ajoute à la configuration SAML. Cette Rule ne s’exécutera que pour l’application nommée Fabrikam Intranet (SharePoint).

function (user, context, callback) {
  if (context.clientName === 'Fabrikam Intranet (SharePoint)') {
    context.samlConfiguration.mappings = {
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier': 'user_id',
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress': 'email',
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name': 'name',
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname': 'given_name',
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname': 'family_name',
        'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn': 'upn',
        'http://schemas.microsoft.com/ws/2008/06/identity/claims/role': 'groups'
    };
  }

  callback(null, user, context);
}

Cela ajoutera une revendication sortante supplémentaire http://schemas.microsoft.com/ws/2008/06/identity/claims/role qui contient les groups et que SharePoint utilisera pour l’autorisation.

Lors de l’installation du Claims Provider, nous devons autoriser la transmission de la revendication Role à SharePoint en l’ajoutant à la liste de mappage des claims :

Enable-Auth0
  -auth0Domain:"fabrikam.auth0.com"
  ...
  -claims:@(
    "Email|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
    "Role|http://schemas.microsoft.com/ws/2008/06/identity/claims/role",
    ...)
  ...
  -Verbose

Par défaut, un utilisateur n’aura pas accès au site.

Désormais, au lieu d’ajouter cet utilisateur en particulier à un groupe SharePoint (p. ex. : Contributors), nous pouvons ajouter un Role à un groupe SharePoint. Voici un exemple de script PowerShell montrant comment ajouter les membres de “Fabrikam HR” au groupe Contributors :

$webName = "http://fabrikam-sp"
$groupName = "Contributors"
$roleClaim = "Fabrikam HR"

$sts = Get-SPTrustedIdentityTokenIssuer "Auth0"
$claimPrincipal = New-SPClaimsPrincipal -ClaimValue $roleClaim -ClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -TrustedIdentityTokenIssuer $sts

$web = Get-SPWeb $webName
$user = New-SPUser -UserAlias $claimPrincipal.ToEncodedString() -Web $web

$group = $web.SiteGroups[$groupName]
$group.AddUser($user)

Après avoir ajouté cette valeur de claim au groupe Contributors, David pourra accéder au site et en modifier le contenu.

​

Synchronisation du profil utilisateur

Par défaut, SharePoint peut synchroniser les renseignements du profil utilisateur provenant d’Active Directory. Avec Auth0, toutefois, les utilisateurs peuvent provenir de différents types de connections (de Social à Enterprise), ce qui exige une approche différente pour synchroniser les profils utilisateur.

Une première approche consisterait à créer une tâche planifiée qui s’exécute toutes les quelques heures, interroge l’endpoint Users d’Auth0 et synchronise les renseignements de profil de ces utilisateurs.

using System;

using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;

using Microsoft.Office.Server;
using Microsoft.Office.Server.UserProfiles;

namespace UserProfileSync
{
    class Program
    {
        static void Main(string[] args)
        {
            // Requête à l'Auth0 Management API - https://docs.auth0.com/api/v2

            using (var site = new SPSite("http://servername"))
            {
                var context = SPServiceContext.GetContext(site);
                var profileManager = new UserProfileManager(context);

                var accountName = "i:05.t|auth0|[e-mail]";
                var userProfile = profileManager.GetUserProfile(accountName);
                userProfile[PropertyConstants.HomePhone].Value = "[phone]";
                userProfile.Commit();
            }
        }
    }
}

Sinon, cette logique pourrait aussi être implémentée sous forme de HttpModule, qui s’exécute chaque fois que l’utilisateur se connecte :

public class PersistUserClaimsHttpModule : IHttpModule
{
    private SPFederationAuthenticationModule FederationModule
    {
        get { return HttpContext.Current.ApplicationInstance.Modules["FederatedAuthentication"] as SPFederationAuthenticationModule; }   
    }

    public void Init(HttpApplication context)
    {
        FederationModule.SecurityTokenValidated += OnFederationSecurityTokenValidated;
    }

    private void OnFederationSecurityTokenValidated(object sender, SecurityTokenValidatedEventArgs e)
    {
        // Utiliser e.ClaimsPrincipal
    }
}