Planear la autenticación de aplicaciones en SharePoint Server
SE APLICA A:
2013 2016 2019 Subscription Edition 
SharePoint en Microsoft 365
La autenticación de aplicaciones consiste en la validación de una identidad externa de aplicación para SharePoint y en la autorización tanto de la aplicación como del usuario asociado cuando la primera solicita el acceso a un recurso de SharePoint seguro. La autenticación de aplicaciones tiene lugar cuando un componente externo de una aplicación de Tienda SharePoint o Catálogo de aplicaciones, como puede ser un servidor web ubicado en la intranet o en Internet, intenta acceder a un recurso de SharePoint seguro. Por ejemplo, una aplicación para SharePoint que incluye un componente que se ejecuta en Microsoft Azure es una aplicación externa. La autenticación de aplicaciones permite un nuevo conjunto de funcionalidades y escenarios que pueden lograrse al permitir que las aplicaciones incluyan datos de recursos de SharePoint en los resultados que la aplicación procesa y muestra a los usuarios.
Para ofrecer los recursos solicitados de una aplicación para SharePoint, siga este procedimiento en el servidor que ejecute SharePoint Server:
Comprobar que la aplicación solicitante es de confianza.
Para autenticar la aplicación solicitante, tiene que configurar el servidor que ejecute SharePoint Server para confiar en la aplicación que envía sus solicitudes. Se trata de una relación de confianza unidireccional.
Comprobar que el tipo de acceso que está solicitando la aplicación está autorizado.
Para autorizar el acceso, SharePoint Server confía en un conjunto de permisos de la aplicación, que se especificó en el archivo de manifiesto de la aplicación cuando esta se instaló, y los permisos asociados al usuario en cuyo nombre actúa la aplicación. SharePoint Server también se basa en los permisos que se otorgaron a SPAppPrincipal cuando se estableció la confianza con el cmdlet Set-SPAppPrincipalPermission PowerShell.
Tenga en cuenta que la autenticación de aplicaciones en SharePoint Server es independiente de la autenticación de usuarios y, por lo tanto, los usuarios de SharePoint no la usan como protocolo de autenticación de inicio de sesión. La autenticación de aplicaciones usa el protocolo Open Authorization (OAuth) 2.0 y no lo agrega al conjunto de protocolos de autenticación de usuarios o de inicios de sesión, como WS-Federation. No hay ningún protocolo de autenticación de usuarios nuevo en SharePoint Server. La autenticación de aplicaciones y OAuth no aparecen en la lista de proveedores de identidades.
Introducción
La planeación de la autenticación de aplicaciones consta de las siguientes tareas:
Identificar el conjunto de relaciones de confianza que se tiene que configurar en una granja de servidores que ejecuta SharePoint Server y que se corresponda con las aplicaciones externas que solicitarán recursos de SharePoint.
Proporcionar acceso entrante desde aplicaciones externas hospedadas en Internet.
Importante
Las aplicaciones web donde se incluyen puntos de conexión de autenticación de aplicaciones (para solicitudes entrantes de aplicaciones para SharePoint) tienen que configurarse para usar la Capa de sockets seguros (SSL). Puede configurar OAuth en SharePoint Server para que no se necesite SSL. Pero solo le recomendamos hacerlo durante la evaluación, con el fin de facilitar la configuración o para crear un entorno de desarrollo de aplicaciones.
Nota:
Solo tiene que planear la autenticación de aplicaciones en una granja de servidores de SharePoint si esta utiliza uno o más aplicaciones para SharePoint externos que necesiten de sus recursos.
Identificación del conjunto de relaciones de confianza
Deberá configurar la granja de servidores de SharePoint de modo que confíe en los tokens de acceso que se correspondan con las solicitudes de recursos que envían los siguientes tipos de aplicaciones externas:
Las aplicaciones hospedadas por proveedores se ejecutan en sus propios servidores en Internet o en la intranet, están registradas en Microsoft Azure y utilizan el ACS para acceder al token.
En el caso de las aplicaciones hospedadas por proveedores, deberá configurar la granja de servidores de SharePoint de modo que confíe en la instancia del ACS de la aplicación hospedada por el proveedor.
Para más información sobre las aplicaciones hospedadas por un proveedor, vea (OLD) Overview of apps for SharePoint 2016.
Las aplicaciones de confianza alta usan el protocolo de servidor a servidor para solicitar recursos en nombre de un usuario. En el caso de las aplicaciones de confianza alta, configure la granja de SharePoint con el punto de conexión de metadatos de notación de objetos JavaScript (JSON) del servidor que hospeda la aplicación. O bien, puede configurar manualmente la confianza. Para obtener más información, vea Configurar la autenticación de aplicaciones en SharePoint Server.
Para obtener más información sobre las aplicaciones de elevada confianza, vea Crear complementos de SharePoint 2013 de elevada confianza.
Elegir métodos de autenticación de usuario para aplicaciones locales
Una aplicación local es una aplicación hospedada por el proveedor en un servidor local o una aplicación hospedada en SharePoint. En la tabla 1 se muestran los diferentes métodos de usuario de autenticación de SharePoint Server y se indica si los métodos se pueden usar para aplicaciones locales de SharePoint Server.
Tabla 1. Métodos de autenticación de usuario y compatibilidad con aplicaciones locales
| Método de autenticación | Compatible con aplicaciones hospedadas por SharePoint | Compatible con aplicaciones hospedadas por proveedores |
|---|---|---|
| NTLM |
Sí |
Sí |
| Kerberos |
Sí, pero solo cuando se configura para usar NTLM como método de autenticación de reserva. Kerberos solo no es compatible. |
Sí |
| Básica |
Sí |
Sí |
| Anónimo |
Sí |
Sí |
| Autenticación basada en formularios usando el proveedor de ASP.NET predeterminado |
Sí |
Sí |
| Autenticación basada en formularios usando el protocolo ligero de acceso a directorios (LDAP) |
Sí |
Sí |
| Autenticación del lenguaje de marcado de aserción de seguridad (SAML) |
Sí, si el proveedor de identidades admite el registro de localizador uniforme de recursos (URL) de devolución de caracteres comodín y respeta el parámetro wreply . . Sí $p = Get-SPTrustedIdentityTokenIssuer$p.UseWReplyParameter = $true$p.Update()
> [! NOTA]> La versión 2.0 de Servicios de federación de Active Directory (AD FS) no admite caracteres comodín para el registro de direcciones URL de devolución. |
Yes |
Proporcionar acceso entrante desde aplicaciones externas hospedadas en Internet
Si las aplicaciones externas hospedadas por proveedores están ubicadas en Internet, deberá configurar un proxy web inverso para poder llevar a cabo la autenticación de las aplicaciones y solicitar recursos desde las granjas de servidores de SharePoint de la intranet. Un proxy web inverso configurado en el extremo de la red deberá permitir conexiones HTTP entrantes, en lugar de SSL (HTTPS), de las aplicaciones a las granjas de servidores de SharePoint. Generalmente, se identifican las direcciones URL basadas en HTTPS a las que tendrán acceso las aplicaciones externas y se configura el proxy inverso para publicar estas direcciones URL y proporcionar la seguridad adecuada.
Consideraciones del servicio de aplicación de perfiles de usuario de direcciones
Las aplicaciones de elevada confianza generan sus propios tokens de acceso, que incluyen una aserción de la identidad del usuario en cuyo nombre actúan. El servidor que ejecuta SharePoint Server y los servicios que solicita el recurso entrante tienen que ser capaces de resolver la solicitud que se realiza a un usuario de SharePoint específico, un proceso conocido como la rehidratación de la identidad del usuario. Tenga en cuenta que este proceso es distinto de la autenticación de aplicaciones hospedadas por proveedores, en las que se identifica al usuario, pero no se afirma su identidad.
Para rehidratar la identidad del usuario, un servidor que ejecute SharePoint Server acepta las notificaciones del token de acceso entrante y las resuelve para un usuario de SharePoint específico. De forma predeterminada, SharePoint Server usa la aplicación de servicio de perfiles de usuario integrada como la resolución de identidad.
El nombre principal de usuario (UPN) de los Servicios de dominio de Active Directory (AD DS)
El identificador de seguridad (SID) de Windows
El nombre principal de usuario (UPN) de los Servicios de dominio de Active Directory (AD DS)
Dirección del protocolo simple de transferencia de correo (SMTP)
Por este motivo, la aplicación deberá incluir, como mínimo, uno de estos atributos de usuario y dicho atributo deberá estar actualizado en los perfiles de usuario.
Por este motivo, la aplicación deberá incluir, como mínimo, uno de estos atributos de usuario y dicho atributo deberá estar actualizado en los perfiles de usuario. Se recomienda realizar una sincronización periódica de la aplicación de servicio de perfiles de usuario desde los almacenes de identidad.
Además, SharePoint Server espera una única entrada en la aplicación de servicio de perfiles de usuario para una determinada consulta de búsqueda basada en uno o más de estos cuatro atributos. De lo contrario, devolverá una condición de error indicando que se encontraron varios perfiles de usuario. Por lo tanto, tendrá que eliminar de forma periódica los perfiles de usuario obsoletos de la aplicación de servicio de perfiles de usuario para evitar que haya varios perfiles de usuario.
Si un usuario ya tiene un perfil de usuario y las pertenencias a grupos relevantes no están sincronizadas, es posible que se deniegue el acceso cuando se suponga que al usuario se le va a otorgar acceso a un determinado recurso. Por todo esto, asegúrese de que las pertenencias a grupos están sincronizadas con la aplicación de servicio de perfiles de usuario.
Vea también
Conceptos
Introducción a la autenticación para el servidor de SharePoint