SharePoint 2013: Permisos en aplicaciones (I)!

Siguiendo a vueltas con el tema de autorización en aplicaciones, es decir, en qué es lo que puede hacer una aplicación del nuevo modelo de aplicaciones en esta ocasión vamos a tratar de ir más al detalle de como se configuran los permisos qué se le pueden dar a una aplicación. Básicamente:

  • Una aplicación va a poder disponer de un conjunto de permisos que hemos indicado a través del correspondiente manifiesto de aplicación:
    • Por defecto, una aplicación tiene control sobre la web que tiene asociada, pero sobre el sitio de SharePoint desde dónde fue agregado. ¿Qué quiere decir esto? Pues qué si desde una aplicación intento acceder a datos de una lista del sitio de SharePoint “host” voy a tener una excepción de acceso denegado porque mi aplicación no tiene permisos para acceder a ese nivel.

image

    • Ahora bien, toda aplicación puede pedir permisos para “ir más allá” de lo qué es la web de la aplicación. Para ello, lo que haremos como desarrolladores es añadir los permisos necesarios en el manifiesto de la aplicación. Por ejemplo, el manifiesto para poder acceder a información de la colección de sitios sería como sigue:
<?xml version="1.0" encoding="utf-8" ?>
<!--Created:cb85b80c-f585-40ff-8bfc-12ff4d0e34a9-->
<App xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest"
     Name="SPOTestApp"
     ProductID="{e388d630-ee74-4e4b-8db1-5f9b4189d767}"
     Version="1.0.0.0"
     SharePointMinVersion="15.0.0.0">
  <Properties>
    <Title>SPOTestApp</Title>
    <StartPage>~remoteAppUrl/Pages/Default.aspx?{StandardTokens}</StartPage>
  </Properties>

  <AppPrincipal>
    <AutoDeployedWebApplication/>
  </AppPrincipal>

  <AppPrerequisites> 
    <AppPrerequisite Type="AutoProvisioning" ID="RemoteWebHost" /> 
  </AppPrerequisites>
  <AppPermissionRequests>
    <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" />
  </AppPermissionRequests>
</App>
    • Cómo veis, la “petición de permisos” se realiza a través de elementos de tipo <AppPermissionRequest> y el atributo Scope, que indica el nivel en el qué la aplicación va a solicitar permisos.
  • Si nos centramos en los permisos que se pueden solicitar, estos son:
    • Lectura / Escritura / Administración / Control Total (Read / Write / Manage / Full Control).
    • Qué equivalen a los niveles de permios Read / Contribute / Design / Full Control típicos de SharePoint.
  • Lo interesante de todo, es qué es muy sencillo definir estos permisos usando el diseñador del manifiesto de aplicación:

image

Anatomía de una petición de permiso de aplicación

Lo siguiente que veremos es cada una de las partes de una petición de permiso necesaria para que una aplicación se ejecute. Básicamente la estructura de la URL que tenemos que indicar en el atributo Scope de la petíción cuenta con los siguientes elementos:

  • Producto, es decir, el producto de Microsoft al que aplica la solicitud: SharePoint, Lync, Exchange.
  • Proveedor del permiso, es decir, si la solicitud de permiso aplica a contenido (colección de sitios, sitio, lista) a a un servicio específico (Búsqueda, Taxonomía, Perfiles de usuario).
  • Objeto objetivo, es decir, sobre que tipo de objeto se va a conceder el permiso solicitado:
  • El atributo Right es el que indica qué se puede hacer sobre el objeto definido: Lectura / Escritura / Administración / Control Total. Además, nos encontraremos que ciertos servicios como el de búsqueda usan permisos especiales (QueryAsUserIgnoreAppPrincipal)

image

 

Entendiendo como se conceden permisos a aplicaciones

Una vez que tenemos claro como se solicitan permisos a las aplicaciones, vamos a analizar lo que implican estos permisos y su concesión:

  • En primer lugar, los permisos para aplicaciones están desconectados de los permisos de usuario. Por lo tanto, son conceptos completamente independientes.
  • Los permisos a aplicaciones se conceden como un “todo o nada” para un cierto ámbito,es decir, no se pueden conceder varios permisos de forma simultanea para un cierto ámbito. Además, si hay varias peticiones de permisos se tienen que conceder todas las peticiones. No es posible conceder permisos de forma parcial.
  • Al contrario que los permisos de usuario, no existen jerarquías de permisos para permisos de aplicaciones. Por lo tanto, los permisos en aplicaciones son tratados siempre como “top-lvenl”.
  • Los ámbitos “normales” de permisos para aplicaciones son lista, sitio y colección de sitios.
  • El usuario que instala la aplicación es el que concede/rechaza permisos durante la instalación. Por supuesto, si los permisos no son concedidos, la aplicación no se instala.

Publicado por

Juan Carlos González

Juan Carlos es Ingeniero de Telecomunicaciones por la Universidad de Valladolid y Diplomado en Ciencias Empresariales por la Universidad Oberta de Catalunya (UOC). Cuenta con más de 12 años de experiencia en tecnologías y plataformas de Microsoft diversas (SQL Server, Visual Studio, .NET Framework, etc.), aunque su trabajo diario gira en torno a SharePoint & Office 365. Juan Carlos es MVP de Office Servers & Services desde 2015 (anteriormente fue reconocido por Microsoft como MVP de Office 365 y MVP de SharePoint Server desde 2008 hasta 2015), coordinador del grupo de usuarios .NET de Cantabria (Nuberos.Net, www.nuberos.es), co-fundador y coordinador del Grupo de Usuarios de SharePoint de España (SUGES, www.suges.es), así como co-director de la revista gratuita en castellano sobre SharePoint CompartiMOSS (www.compartimoss.com). Hasta la fecha, ha publicado 8 libros sobre SharePoint & Office 365 y varios artículos en castellano y en inglés sobre ambas plataformas.

2 comentarios en “SharePoint 2013: Permisos en aplicaciones (I)!”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *