SharePoint 2013: Flujo de autenticación en aplicaciones (I)!

Hace unos meses os comentaba el concepto de autorización en aplicaciones que introduce el nuevo modelo de aplicaciones de SharePoint, hablábamos también sobre los ámbitos y permisos de aplicación por ámbito y en general lo que implica “autorizar” a una aplicación para que actúe en nombre de un usuario. En este post, vamos a ver cuál es el flujo normal de autenticación en aplicaciones teniendo en cuenta:

  • Los opciones de autorización qué se permiten en SharePoint 2013.
  • Los tipos de aplicaciones que podemos tener.
  • Los requerimientos qué se necesitan para poder hacer uso del modelo de autorización (AuthZ) de SharePoint 2013.

Os recuerdo qué SharePoint 2013 permite qué además de los usuarios, se puedan autenticar aplicaciones, es decir, les está dando una ideantidad. El flujo de autenticación es el que se muestra en la siguiente figura (Nota: Lo podéis encontrar en los materiales de los traininig de desarrollo e IT de Microsoft para SharePoint 2013).

image

Y ahora al lio:

  • En primer lugar, vamos a recordar los tipos de aplicaciones que podemos crear:
    • SharePoint-Hosted, es decir, residen y se ejecutan en un sitio de SharePoint aislado.
    • Auto-Hosted, es decir, las aplicaciones residen y se ejecutan en Windows Azure. En este caso, SharePoint Online es un simple punto de acceso a dichas aplicaciones.
    • Provider-Hosted, es decir, las aplicaciones residen y se ejecutan en una infraestructura de nube pública como puede ser Windows Azure, de nube propietaria o bien en un entorno de hosting.
  • ¿Qué opciones de autorización se permiten en SharePoint 2013?
    • Sólo Usuario, es decir, se utiliza autenticación por medio de usuario y contraseña. Esta opción aplica a los tres modelos.
    • Usuario y Aplicación , es decir, se usa OAuth como protocolo de autenticación. Esta opción aplica a aplicaciones Auto-Hosted y Provider-Hosted.
    • Sólo Aplicación, es decir, de nuevo se hace uso de OAuth. Esta opción aplica a aplicaciones Auto-Hosted y Provider-Hosted.
    • Anónimo (sin OAuth), y que aplica a cualquier modelo.
  • ¿Cuáles son los requerimientos para poder establecer una identidad en una aplicación? El requerimiento fundamental es qué la aplicación web “Host” esté configurada con autenticación basada en Claims.

Visto esto, vamos a explicar con más detalle el flujo de autenticación de SharePoint 2013 de la figura diferenciado entre peticiones realizadas por un usuario y peticiones realizadas por una aplicación:

Peticiones de usuario

  • Cuando SharePoint 2013 recibe una petición entrante qué requiere autenticación, lo primero que hace es comprobar si dicha petición contiene un token SAML con la identidad del usuario.
  • Si encuentra dicho token, SharePoint asume que la petición procede de un usuario y no de una aplicación.
  • A continuación, analiza la URL de la petición para determinar si se trata de una URL estándar de un sitio de SharePoint o se trata de una URL de aplicación:
    • En el caso de una URL estándar, el flujo de autenticación y autorización que tiene lugar es el mismo que ya conocíamos para SharePoint 2010.
    • En el caso de una URL de aplicación, SharePoint 2013 inicia el contexto de llamada para la identidad del usuario y para la identidad de la aplicación.´

Peticiones de aplicación

  • En este caso, la petición entrante no contiene un token SAML, por lo que SharePoint 2013 interpreta que no ha sido un usuario quien ha iniciado la petición.
  • A continuación, SharePoint inspecciona la petición para ver si contiene un token de seguridad que identifique a la aplicación. Este token en aplicaciones de tipo Autohosted se crea usando OAuth y usando los elementos que provee Office 365 para su uso (ACS, Azure Control Service). En el caso de una aplicaicón Provider-Hosted, la idea es la misma: se necesita un token OAuth válido y posiblemente hacer configuraciones extra entre servidores (S2S, Sever to Server).
  • En cualquiera de los dos escenarios, SharePoint 2013 usa el token de seguridad para establecer un contexto de llamada al menos para la aplicación (opcionalmente para el usuario).

SharePoint 2013: ¿Es bidireccional la sincronización de documentos con SkyDrive Pro?

Pues la respuesta es que sí, y aquí tenéis la prueba del algodón:

  • En un equipo en el que hayamos hecho una sincronización de una biblioteca de documentos de SharePoint 2013 (On-Premise u Online en Office 365), iniciamos Microsoft SkyDrive Pro (os recuerdo que se instala como parte de Office 2013) de manera que se abre el explorador de Windows con la biblioteca sincronizada y su contenido.
  • Agregamos un documento cualquiera en la carpeta sincronizada y fijaros como inicialmente dicho documento no aparece con el “tick” verde de qué se ha sincronizado (hay que darle tiempo a SkyDrive Pro para que lo haga y también vamos a depender de qué ancho de banda tengamos).
  • Al cabo de unos segundos de haber copiado el documento, podremos comprobar que el documento ya presenta el tick lo que indica que o bien se está sincronizando en la biblioteca de documentos de SharePoint o bien se ha sincronizado ya.
image image image
  • Si navegamos a la biblioteca sincronizada, podremos comprobar como efectivamente el documento aparece allí :-)…cool.

image

SharePoint Online: Nuevos límites SW para los distintos tipos de planes!

Cómo sabéis, Microsoft se encuentra en plena actualización  de los servicios de Office 365. Uno de los servicios qué será actualizado es SharePoint Online de manera que se adopte como plataforma base SharePoint 2013 y a la vez haya mejoras a tener en cuenta en lo que a límites SW se refiere. También hay que tener en cuenta los distintos tipos de planes de que dispondremos y que difieren de la generación actual de servicios de Office 365. Podéis acceder  a la información de los límites desde este enlace.

image

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>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

    • 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.

SharePoint 2013: ¿Qué cantidad de memoria máxima debería poner a nivel de SQL Server?

Como diría alguno, buena pregunta y difícil respuesta para la misma. Por suerte, hace unos días estuve asistiendo al WebCast Tuning SQL Server 2012 for SharePoint 2013 Jump Start (presentado por Bill Baer y Brian Alderman) que podéis encontrar en Microsoft Virtual Academy. Entre otros muchos contenidos interesantes, me quedé con una fórmula interesante para determinar que cantidad de memoria máxima deberíamos fijar a nivel de SQL Server:

image

En mi caso, interpretando qué la función CEILING devuelve el entero más pequeño que no es menor que el argumento el valor máximo de memoria que debería tener configurado a nivel de SQL Server es:

SQL Max Memory = 10.240 MB (Memoria física disponible) – (256 * 2 MB) –1024 MB * CEILING (2/4) = 10.240 – 512 – 1.024 = 8.704 MB = 8.5 GB.

Frente a este valor, fijaros en el valor por defecto que tiene configurado SQL Server….vamos, que si le dejas se lo come todo :P.

image image

SharePoint 2013 & SharePoint Online: Q & A sobre la creación y publicación de aplicaciones en el Office Store (I)!

Aunque todavía queda camino por recorrer antes de qué el Office Store de aplicaciones para SharePoint, Office y Office 365 esté plenamente operativo, hay ciertas cuestiones en el aire a las qué es necesario dar respuesta sobre todo para que los desarrolladores tengan claro cuáles son los pasos a seguir para crear y poder publicar las aplicaciones en el Store. En este posts y los siguientes iré incluyendo una serie de FAQs que aclaren al máximo estas cuestiones:

  • [Q] ¿Qué necesito como pre-requisito para pode publicar aplicaciones en el Office Store?

Para poder publicar aplicaciones en el Office Store se necesita disponer de un sitio de desarrollador de Office 365 (Office 365 Developer Site). Para obtener este sitio, hay varias opciones que vienen descritas en este enlace. Este sitio se necesita para construir aplicaciones para SharePoint Online, pero también para los clientes de Office. Por lo tanto, cualquier desarrollador de aplicaciones para el Office Store necesita un sitio de desarrollador de Office 365 para poder enviarlas al Office Store.

  • [Q] ¿Tienen que pagar los desarrolladores por un sitio de desarrollador de Office 365?

Depende de la opción que elijan/tengan disponible para acceder a un sitio de desarrollador:

    • Se puede optar por usar por la versión trial de 30 días, recomendable para sesiones de training.
    • Se puede conseguir un sitio de desarrollador de Office 365 por un año si se dispone de una subscripción MSDN (Visual Studio Premium / Visual Studio Ultimate).
    • Si el desarrollador pertenece a una organización qué dispone de un tenant de Office 365, pueden solicitar a un administrador que cree un sitio de desarrollador utilizando la plantilla disponible para ello. El administrador, una vez creado el sitio, deberá dar los permisos adecuados al desarrollador.
    • Finalmente, tenemos la opción de adquirir una subscripción de este tipo por un importe de 99 $ anuales.
  • [Q] ¿Se pueden publicar actualmente aplicaciones en el Office Store?

Depende del tipo de aplicación:

    • Ahora mismo, las aplicaciones de tipo SharePoint Autohosted (aplicaciones para SharePoint Online) únicamente pueden ser desplegadas y depuradas contra sitios de desarrollador de Office 365. Sin embargo, todavía no se pueden enviar al Office Store. Esta capacidad estará disponible próximamente.
    • En principio, las aplicaciones de tipo SharePoint-Hosted, Provider-Hosted y para Office se pueden publicar a través del Office Store.
  • [Q] En el caso de aplicaciones de tipo Autohosted: ¿Es posible acceder a la subscripción de Windows Azure que hospeda elementos de la aplicación como páginas, servicios, BDs de SQL Azure, etc?

La respuesta es qué no:

    • El despliegue de estos elementos en Azure es realizado completamente por SharePoint Online cuando la aplicación es publicada y de forma transparente para el usuario que no tiene acceso a la instancia correspondiente. Cuando un usuario instala/desinstala la aplicación, los elementos de Azure son desplegados/borrados de forma automática.
    • En el caso de BD’s SQL Azure, sucede lo mismo. SharePoint Online se encarga de todo el proceso de creación de la BD y el desarrollador no tiene acceso a la misma. De nuevo, cuando la aplicación se instala/desinstala, la BD se crea/borra.
  • [Q] De nuevo para aplicaciones Autohosted: ¿Es posible de dotarlas de recursos adicionales de Azure en el caso en qué sea necesario?

No hay forma de hacer esto y tampoco hay información conocida sobre los límites de capacidad para sitios web, servicios o BDs. En cualquier caso, las aplicaciones de tipo Autohosted están pensadas como soluciones para grupos de trabajo, equipos, departamentos pequeños, etc qué no van a requerir de muchas capacidades. Por ejemplo, serían soluciones como Seguimiento de Eventos, Inventarios, Aplicaciones de Productividad, Seguimiento de recursos, etc.

  • [Q] ¿Cuántas aplicaciones Autohosted se pueden publicar en Office 365?

De momento este dato es desconocido y no se sabrá hasta que se libere el modelo de precios/costes que Microsft va a aplicar.

  • [Q] ¿Cuándo se recomienda crear aplicaciones de tipo Provider-Hosted?

Una respuesta simple es la siguiente: en aquellos escenarios en los que la capacidades de las aplicaciones de tipo SharePoint-Hosted y Provider-Hosted no sean suficientes y se necesite disponer de más control y más capacidades para los elementos de la aplicación qué se desplieguen. En una aplicación Provider-Hosted, los elementos de la misma se pueden desplegar en un servidor propio dedicado o bien en Windows Azure de manera que en este caso si es posible tener un control sobre los recursos que se necesitan.

Desde el punto de vista conceptual, también es importante recordar la flexibilidad que nos dan las aplicaciones de este tipo ya que pueden ser simples aplicaciones web hospedadas en IIS o aplicaciones PHP ejecutándose en la pila de LAMP en un escenario On-Premise.

  • [Q] ¿Cómo se publica una aplicación en el Office Store?

Desde el sitio de desarrollador de Office 365 se puede acceder al Seller Dashboard dónde cada usuario, con una cuenta activa en el mismo, puede dar de alta nuevas aplicaciones, obtener métricas de las aplicaciones ya desplegadas, etc. Para acceder al Seleer Dashboard es necesario usar un Live ID válido para publicar aplicaciones (Por ejemplo, el asociado a una subscripción MSDN con el beneficio del sitio de desarrollador de Office 365. Más información sobre publicación de aplicaciones en este enlace.

  • [Q] ¿Existen pautas/consideraciones/políticas a tener en cuenta a la hora de diseñar una aplicación qué pueda ser publicada en el Office Store?

Sí, Microsoft ha preparado una guía al respecto que puedes consultar aquí. La aplicación tiene que cumplir las políticas descritas para poder ser aprobada y publicada en el Office Store. Además, a través de la página de acceso al Seller Dashboard podemos encontrar otras pautas a tener en cuenta como:

Y de momento esto es todo respecto a crear y publicar aplicaciones en el Office Store.

SharePoint 2013 & SharePoint Online: ¿Puede un usuario externo publicar aplicaciones?

Como por fin parece que el desarrollo de aplicaciones para SharePoint y Office comienza a coger impulso, empiezan a aparecer cuestiones en el aire como la qué da título a este pots y que de tener una respuesta positiva facilita bastante la prueba y despliegue de aplicaciones a usuarios que no necesariamente dispongan de una subscripción de Office 365 o un entorno de desarrollo de SharePoint 2013. Os adelanto que la respuesta es positiva :-)…al lio como diría alguno:

  • Lo primero que tenemos que hacer es asegurarnos de invitar a un usuario externo (qué tenga un Windows Live ID) a nuestro sitio de desarrollo de Office 365 (creado con la plantilla “Sitio de desarrollador”).
  • Para que el usuario pueda desplegar aplicaciones en el sitio, es necesario que al menos sea “propietario del sitio”. A continuación, en Visual Studio 2012 procedemos crear un proyecto de tipo “Aplicación para SharePoint 2013”. En el asistente de configuración especificamos la url del sitio de Office 365 y pulsamos el botón “Validar” de manera qué se abre una ventana para qué indiquemos las credenciales de acceso al sitio de Office 365. Aquí es necesario darse cuenta de qué para acceder con un usuario externo hay que pulsar el enlace  “Iniciar sesión con una cuenta de Windows Live ID”.
  • A continuación, simplemente especificamos los datos de acceso del usuario externo y pulsamos “Iniciar sesión”
image image image
  • Puede ser qué al pulsar “Iniciar sesión”, la ventana de credenciales del sitio no se cierre y se muestre el sitio de Office 365. Para evitar que esto suceda, marcad en la ventana de “Iniciar sesión” el check de “Mantener la sesión iniciada”.
  • Si todo ha ido bien, el asistente concluirá con la creación del proyecto en Visual Studio 2012.
  • Personalizamos la aplicación ligeramente y procedemos a publicarla. Aquí si no habéis tenido cuidado de agregar el usuario al grupo de propietarios del sitio os podéis encontrar con un error al desplegar en cuanto a que el usuario no tiene los permisos necesarios para instalar la aplicación.
image image image
  • Solventada cualquier cuestión relativa a permisos necesarios para instalar la aplicación, se abrirá el navegador web con la página ya conocida en la que se pide confirmación de acceso a la aplicación desplegada.
  • Pulsamos el botón “Confiar” y listo, ya tenemos la aplicación creada por el usuario externo disponible en Office 365…cool.
image image