Tres sistemas de autorización para complementos de SharePoint
En SharePoint, un complemento de SharePoint es una entidad de seguridad de identidad al igual que un usuario, y debe autenticarse y autorizarse para usar recursos de SharePoint. Hay tres sistemas de autorización que un complemento puede usar. No son mutuamente excluyentes.
Información sobre los tres sistemas de autorización y cuándo usarlos
Baja confianza
Un complemento de SharePoint hospedado por el proveedor puede registrarse con Microsoft Azure Access Control Service (ACS), que emite un token de acceso al complemento que permite al complemento acceder a los recursos del inquilino o granja de servidores de SharePoint en los que está instalado el complemento. Azure ACS es el emisor del token de confianza de un "flujo" de OAuth 2.0 Framework que incluye SharePoint y los componentes remotos del complemento. Los complementos que usan este sistema se pueden vender en la Tienda Office. El sistema de confianza baja está pensado principalmente para los complementos cuyos componentes remotos están hospedados en la nube.
Importante
Azure Access Control (ACS), un servicio de Azure Active Directory (Azure AD), se retirará el 7 de noviembre de 2018. La retirada de este producto no afecta al modelo de complemento de SharePoint, que usa el nombre de host https://accounts.accesscontrol.windows.net (que no est? afectado por esta retirada). Para obtener más información, vea Impacto de la retirada de Azure Access Control para Complementos de SharePoint.
Para más información sobre la creación de un complemento de SharePoint que use el sistema de baja confianza, vea Crear complementos de SharePoint que usan la autorización de baja confianza.
Nota:
El cliente que instala el complemento debe tener una cuenta de Office 365. Esto es necesario para dar acceso al complemento a Azure ACS. Sin embargo, el cliente no necesita usar la cuenta para ningún otro propósito y el complemento se puede instalar en una granja de sharePoint local después de algunas tareas de configuración sencillas en la granja de servidores.
Elevada confianza
Un complemento hospedado por el proveedor puede establecer la confianza con SharePoint mediante certificados digitales. El sistema de alta confianza está pensado principalmente para complementos cuyos componentes remotos se hospedan en el entorno local. El complemento se puede instalar en una granja de SharePoint que no está conectada a Internet. El complemento no se puede instalar en SharePoint Online ni venderse en la Tienda Office.
Para obtener más información sobre cómo crear un complemento de SharePoint que use el sistema de elevada confianza, vea Crear complementos de SharePoint que usan la autorización de elevada confianza.
Biblioteca entre dominios
Cuando la lógica de negocios del complemento está en JavaScript, tiene la opción de usar la biblioteca entre dominios de SharePoint en lugar de, o como complemento a, los sistemas de confianza baja y alta confianza. La biblioteca también está pensada para escenarios donde el complemento tiene componentes hospedados en la nube, pero donde el firewall de la empresa del cliente dificulta el uso del sistema de confianza baja. El explorador del usuario bloquea los scripts de otros dominios, pero la biblioteca encapsula un sistema seguro para evitar esta restricción. Los complementos que usan la biblioteca se pueden vender en la Tienda Office y se pueden instalar en SharePoint Online o sharePoint local.
Para obtener más información sobre cómo crear un complemento de SharePoint que use la biblioteca entre dominios, vea:
Crear complementos de SharePoint que usen la biblioteca entre dominios
Entrada de blog sobre cómo solucionar problemas entre dominios en complementos de SharePoint
Información general sobre marco OAuth 2.0 y su implementación en SharePoint
Dos de los tres sistemas de autorización usan OAuth 2.0 Framework. OAuth 2.0 es un entorno abierto de autorización. OAuth permite la autorización segura desde aplicaciones de escritorio, dispositivo y web de una manera estándar. OAuth permite a los usuarios autorizar a una aplicación para que actúe en su nombre sin compartir su nombre de usuario y contraseña.
Por ejemplo, permite a un usuario compartir sus recursos o datos privados (lista de contactos, documentos, fotos, vídeos, etc.) de un sitio con otro sitio, sin que sea necesario que el usuario proporcione sus credenciales (normalmente, el nombre de usuario y la contraseña) al otro sitio.
OAuth permite a los usuarios proporcionar tokens de acceso a los datos hospedados en un proveedor de servicios determinado (como SharePoint). Cada token otorga acceso a un proveedor de recursos concreto (como SharePoint) para recursos específicos (por ejemplo, los documentos de una biblioteca de documentos de SharePoint) y durante un lapso determinado (por ejemplo, 12 horas). Esto permite a un usuario conceder a una aplicación web o de escritorio de terceros acceso a la información que se almacena con otro recurso o proveedor de servicios (como SharePoint) y hacerlo sin compartir su nombre de usuario y contraseña, y sin compartir todos los datos que tiene con el proveedor.
SharePoint usa el marco OAuth 2.0, que usa "flujos" de transmisión de tokens para:
Autorizar solicitudes por un complemento de SharePoint para obtener acceso a recursos de SharePoint.
Autenticar complementos en la Tienda Office, un catálogo de complementos o un espacio empresarial de desarrollador.
Para más información y antecedentes sobre OAuth y la terminología de OAuth, vea OAuth.net y el Protocolo de autorización web (OAuth).
En resumen, hay un servidor de recursos que hospeda un recurso protegido, un propietario del recurso, una aplicación cliente que quiere acceder al recurso y un servidor de autorizaciones que emite tokens de acceso al recurso cuando el propietario del recurso se lo indica.
En la documentación oficial de OAuth se suele a asumir un escenario en el que hay un único propietario de un recurso que concede acceso al recurso desde la aplicación cliente cada vez que esta se ejecuta. También se da por hecho que la persona que usa la aplicación cliente es el propietario del recurso.
La implementación de SharePoint tiene en cuenta que un recurso de SharePoint, tal como una lista, se comparte entre varios usuarios. Además, en la implementación de SharePoint, se concede acceso al complemento de SharePoint cuando se instala, no cada vez que se ejecuta, y puede ser ejecutado por usuarios distintos de la persona que lo instaló y le concedió acceso. (En el caso de los complementos que no se instalan en SharePoint, pero que acceden a los recursos de SharePoint (por lo que son "Complementos de SharePoint" solo en un sentido amplio), el usuario que ejecuta el complemento no tiene que conceder permisos cada vez que se ejecuta el complemento).
Por lo tanto, en la implementación de SharePoint, los roles de OAuth los desempeñan los componentes siguientes:
El componente remoto de un complemento de SharePoint hace el papel de aplicación cliente.
Los usuarios SharePoint hacen el papel de propietario del recurso.
SharePoint tiene el rol del servidor de recursos.
Azure ACS desempeña el rol del servidor de autorización cuando se usa el sistema de autorización de baja confianza. Cuando se usa el sistema de alta confianza, el propio complemento (junto con un certificado digital) se convierte en el servidor de autorización.
Los tokens de acceso no son tokens de inicio de sesión
Como se describió anteriormente, para acceder a los recursos, un complemento tiene que solicitar un token de acceso de un servidor de autorización de OAuth que el propietario del recurso haya designado previamente como emisor de tokens de seguridad (STS) de confianza. Por el contrario, los STS de WS-Federation y los STS de inicio de sesión pasivo del lenguaje de marcado de aserción de seguridad (SAML) están destinados principalmente a emitir tokens de inicio de sesión.
En SharePoint, no se usa un STS de OAuth para emitir tokens de inicio de sesión; es decir, no se usan como proveedores de identidades. Por lo tanto, no verá un STS de OAuth en la página de inicio de sesión del usuario, en la sección Proveedor de autenticación de Administración central o en el selector de personas de SharePoint.
Los administradores de SharePoint pueden usar comandos de Windows PowerShell para habilitar o deshabilitar un STS de OAuth, de forma similar a como habilitan o deshabilitan proveedores de inicio de sesión de confianza en SharePoint.