Integrar con SharePoint 2010/2013

Cómo integrar SharePoint 2010/2013, incluida la configuración, la solución de problemas, el acceso a los registros y los próximos pasos.

Auth0 puede ayudar a simplificar radicalmente el proceso de autenticación de SharePoint. En este tutorial, aprenderá a agregar Inicio de sesión único (SSO) a SharePoint mediante Auth0. Sus usuarios podrán iniciar sesión con cualquiera de nuestros Proveedores de identidad social (Facebook, X, Github, etc.), Proveedores empresariales (LDAP, Active Directory, ADFS, etc.) o con un nombre de usuario y contraseña.

Auth0 ya no admite el Auth0Claims Provider para SharePoint 2010 / 2013. Este paquete está obsoleto para los inquilinos existentes y no está disponible para los nuevos.

​

Configuración

​

Paso 1. Añadir la integración a su cuenta

Lo primero que debe hacer es ir a la sección Integraciones de SSO del Dashboard y elegir SharePoint de la lista de aplicaciones.

​

Paso 2. Siga la documentación interactiva

Si su servidor de SharePoint no tiene acceso a Internet, descargue manualmente los archivos de instalación. (Más información sobre la instalación sin conexión).

En la pestaña Settings deberá introducir la URL de la aplicación web de SharePoint y la URL externa (normalmente, el endpoint de Internet en sus Alternate Access Mappings).

La documentación interactiva comienza con la instalación de Auth0 CmdLets para SharePoint:

Una vez instalados, podrá habilitar o deshabilitar Auth0 y el Claims Provider para las distintas aplicaciones web. Deberá habilitar la autenticación con Auth0:

A continuación, instale el Claims Provider para asegurarse de que People Picker y los permisos funcionen correctamente:

Una vez ejecutados estos scripts, completará la configuración en Administración central:

Tenga en cuenta que el comando Enable-Auth0 se puede adaptar para:

• Cambiar el identificador único de los usuarios (como el correo electrónico o un id de usuario)
• Permitir que se transmitan claims adicionales a SharePoint
• Habilitar o deshabilitar la autenticación predeterminada de Windows

El siguiente ejemplo también agrega el claim Role a la asignación de claims y permite la autenticación de Windows:

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

​

Paso 3. Ahora ya tiene SharePoint configurado

Ha configurado SharePoint para usar Auth0 como intermediario de SSO. Cuando sus usuarios visiten su sitio, se les mostrará una página de inicio de sesión con todas las conexiones habilitadas para esa aplicación.

En función de los claims que se hayan asignado al instalar el proveedor de claims, esta información adicional también estará disponible en la página de configuración personal del usuario:

Tenga en cuenta que puede adaptar la llamada a Enable-Auth0 para:

• Cambiar el identificador único de los usuarios (como el correo electrónico o el id de usuario)
• Permitir que se pasen claims adicionales a SharePoint
• Habilitar o deshabilitar la autenticación de Windows predeterminada

Este ejemplo también agrega el claim Role al mapeo de claims y permite la autenticación de Windows:

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 ahora usará Auth0 como broker de SSO.

​

Personalización de la página de inicio de sesión

Puede personalizar la página de inicio de sesión siguiendo las instrucciones de Auth0 Universal Login.

Puede que desee ofrecer una forma para que los usuarios se autentiquen con SharePoint mediante autenticación de Windows, sin pasar por Auth0. Puede hacerlo personalizando la página de inicio de sesión y agregando un enlace al endpoint de autenticación de Windows (normalmente similar a https://yoursharepointserver/_windows/default.aspx?ReturnUrl=/_layouts/15/Authenticate.aspx).

Una forma de hacerlo es usar jQuery para modificar el widget Lock y agregar un enlace al endpoint de autenticación de Windows.

Debe agregar una referencia a jQuery al inicio de la sección <body> de la página de inicio de sesión personalizada.

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

Antes de llamar a lock.show(), agregue código para modificar el DOM del HTML y añadir el enlace.

// construir Lock
// var lock = ...
[...]
// Uno o más IDs de cliente de SharePoint para los que desea
// un botón de autenticación de 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];
    };
    // obtener el host de la URL de callback
    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();

​

Solución de problemas

Al trabajar con claims adicionales y autorización, puede resultar útil ver los claims del usuario actual. El artículo Claims Viewer Web Part, de Liam Clearly, profesional de Microsoft, puede usarse para diagnosticar cualquier problema con los claims del usuario:

​

Registros en SP2010

Los errores y las advertencias se registran en el Unified Logging Service de SharePoint, y se pueden usar herramientas como ULS Viewer para solucionar cualquier problema que pueda surgir al usar Claims Provider.

Para obtener más información sobre ULS Viewer y consultar sus especificaciones, vea la documentación de Microsoft ULS Viewer.

​

Registros en SP2013

En SharePoint 2013 ya no usamos Unified Logging Service para los registros; en su lugar, hemos pasado a Event Tracing for Windows. Esto ofrece un mejor rendimiento y le proporciona varias formas de capturar todos los eventos registrados.

Para ver los registros en tiempo real, puede descargar el Procesador de registros de Auth0 desde GitHub. Ejecute esta herramienta en sus servidores de SharePoint para ver cada llamada que SharePoint realiza al Claims Provider:

​

Próximos pasos

​

Autorización

Los claims que se pasan desde Auth0 también pueden usarse para la autorización en SharePoint. Por ejemplo, un usuario con el claim Role que contiene Fabrikam HR debería tener acceso o ser colaborador en un sitio específico.

Tomemos Azure AD como ejemplo. En este directorio en la nube, los usuarios pueden pertenecer a grupos, y David pertenece a Fabrikam HR.

Cuando David inicia sesión con su cuenta de Azure AD (y el atributo Security Groups está habilitado para esa conexión), las pertenencias a grupos se almacenarán en el atributo groups del perfil del usuario.

Si queremos que estos grupos estén disponibles como Roles en SharePoint, tendremos que escribir una Rule que agregue esto a la configuración de SAML. Esta Rule solo se ejecutará para la aplicación llamada 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);
}

Esto agregará una claim saliente adicional http://schemas.microsoft.com/ws/2008/06/identity/claims/role que contendrá groups y que SharePoint usará para la autorización.

Al instalar el Claims Provider, debemos permitir que la claim de rol se transfiera a SharePoint añadiéndola a la lista de asignación de 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

De forma predeterminada, un usuario no tendrá acceso al sitio.

Ahora, en lugar de agregar ese usuario concreto a un grupo de SharePoint (por ejemplo, Colaboradores), podemos agregar un rol a un grupo de SharePoint. Aquí tienes un script de PowerShell de ejemplo que muestra cómo agregar miembros de “Fabrikam HR” al grupo Colaboradores:

$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)

Después de agregar este valor de claim al grupo Contributors, David podrá acceder al sitio y editar su contenido.

​

Sincronización del perfil de usuario

De forma predeterminada, SharePoint puede sincronizar la información del perfil de usuario procedente de Active Directory. Ahora, con Auth0, los usuarios pueden provenir de distintos tipos de conexiones (desde conexiones sociales hasta empresariales), lo que requiere un enfoque diferente para sincronizar los perfiles de usuario.

Un primer enfoque sería crear una tarea programada que se ejecute cada pocas horas, consulte el endpoint de usuarios de Auth0 y sincronice la información del perfil de esos usuarios.

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)
        {
            // Llamar a la Management API de Auth0 - 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();
            }
        }
    }
}

Como alternativa, esta lógica también se podría implementar como un HttpModule que se ejecuta cada vez que el usuario inicia sesión:

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)
    {
        // Usar e.ClaimsPrincipal
    }
}