Desplegar un .sppkg sin ser administrador global
Última actualización:
Sí se puede. Subir un .sppkg al catálogo de aplicaciones del tenant y desplegarlo requiere el rol de administrador de SharePoint, no el de administrador global. Y aprobar las solicitudes de permiso de API que trae el paquete se hace desde el centro de administración de SharePoint, que ese mismo rol también alcanza.
Esto importa más de lo que parece, porque suele ser justo lo que atasca un despliegue: quien quiere la herramienta se lo pide a TI, TI da por hecho que hace falta consentimiento de administrador global sobre todo el tenant, y la petición entra en la cola que no avanza nunca. En la mayoría de los casos nadie tiene que tocar el rol de administrador global — un rol que una organización bien llevada deja a propósito en dos o tres personas y con gestión de acceso privilegiado por encima.
Qué rol hace cada cosa
| Tarea | Rol mínimo |
|---|---|
| Crear el catálogo de aplicaciones del tenant (una vez, si no existe) | Administrador de SharePoint |
| Subir el <code>.sppkg</code> a <em>Aplicaciones para SharePoint</em> | Administrador de SharePoint |
| Desplegarlo en todos los sitios de la organización | Administrador de SharePoint |
| Aprobar las solicitudes de permiso de API del paquete | Administrador de SharePoint |
| Añadir la app a un sitio concreto | Propietario del sitio |
| Conceder consentimiento de administrador a una aplicación de Entra ID directamente | Administrador global o administrador de roles con privilegios |
La última fila es de donde viene la confusión. Conceder consentimiento a una aplicación de Entra ID desde el portal de Entra sí es una acción de administrador global. Pero un paquete de SharePoint Framework no te pide eso: registra su solicitud de permiso a través de SharePoint, y se aprueba desde Centro de administración de SharePoint → Avanzado → Acceso a API, que el rol de administrador de SharePoint sí alcanza.
La secuencia real
- Comprueba que existe el catálogo de aplicaciones. Centro de administración de SharePoint → Más características → Aplicaciones. Si no hay catálogo, créalo: uno por tenant, y solo ocurre una vez en la vida del tenant.
- Sube el paquete a la biblioteca Aplicaciones para SharePoint.
- Elige el alcance del despliegue. El diálogo ofrece hacer la solución disponible para todos los sitios de la organización. Si conviene marcarlo depende del paquete.
- Aprueba los permisos de API, si el paquete pide alguno: Centro de administración de SharePoint → Avanzado → Acceso a API. Lee el scope solicitado antes de aprobar, no después.
Eso es todo. Donde las organizaciones pierden semanas no es en estos cuatro pasos, que son diez minutos: es en el ticket, en la revisión de seguridad y en la reunión para decidir de quién es la decisión.
Cuándo sí hace falta un administrador global
- Para asignar el propio rol de administrador de SharePoint. Alguien con administrador global o administrador de roles con privilegios tiene que concederlo primero.
- Para consentir una aplicación de Entra ID que no viene de un paquete de SharePoint: por ejemplo, un producto SaaS independiente que pide permisos de Microsoft Graph sobre todo el tenant.
- Para cualquier cosa que toque la identidad del tenant: acceso condicional, métodos de autenticación, roles de directorio.
Si un proveedor te dice que su web part de SharePoint necesita consentimiento de administrador global, pregúntale qué permiso y por qué. Muchas veces la respuesta honesta es que el producto quiere acceso a tus datos vía Microsoft Graph, que es una conversación muy distinta de desplegar un componente de render — y que conviene tener antes de subir el paquete, no después.
Preguntas frecuentes
¿Aprobar el acceso a API le da al proveedor acceso a nuestros datos de SharePoint?
Depende por completo de qué se esté pidiendo, y por eso hay que leer el scope. Una solicitud de permisos de Microsoft Graph como Sites.Read.All sí da acceso amplio a tu contenido. Una solicitud acotada a la propia API del proveedor solo permite al web part obtener un token dirigido a ese proveedor, lo que no concede nada sobre tu tenant. Las dos aparecen en la misma pantalla, así que lo que importa es el nombre del recurso y el scope.
¿Puede un propietario de sitio instalar un paquete sin implicar al administrador de SharePoint?
No. Un propietario de sitio puede añadir una app a su sitio, pero solo cuando el paquete ya está en el catálogo del tenant, y eso requiere el rol de administrador de SharePoint. Existe un catálogo de aplicaciones a nivel de sitio en algunas configuraciones, pero está desactivado por defecto en la mayoría de tenants y no cambia quién aprueba los permisos de API.
¿Y si no tenemos catálogo de aplicaciones?
Entonces es que nunca se ha creado, algo habitual en tenants que solo han usado SharePoint de serie. Un administrador de SharePoint lo crea desde el centro de administración en un par de minutos. Es algo puntual para todo el tenant, no por paquete.
¿Cómo revisamos un paquete antes de desplegarlo?
Descárgalo e inspecciónalo: un .sppkg es un archivo zip con los manifiestos y los assets de cliente. Los manifiestos declaran las solicitudes de permiso de API, los identificadores de los componentes y si la solución permite script personalizado. Un proveedor que no te deja descargar el paquete antes de comprometerte te está diciendo algo. Sharelio publica su paquete, su SHA-256 y el manifiesto completo de permisos en sharelio.com/es/seguridad.