PDF de programación - CompartiMOSS #25

Nº25 septiembre 2015

REVISTA ESPECIALIZADA EN TECNOLOGÍAS SHAREPOINT

Entrevista An-
dré Lage

SharePoint
y Azure -
Operational
Insights

Aplicaciones
empresariales
en Office 365

Desarrollo de
Aplicaciones
con Office 365
API

1

Enr Contenido
03
Editorial
07

Desarrollo de Aplicaciones
con Office 365 API
14
Introducción a los Grupos de
Office 365 – Trabaja como
una red (Parte IV)
23

Entrevista André Lage
31
Generando máquinas como churros:
Azure DevOps y Powershell Desired
State Configuration (DSC)
37

Por un SharePoint Sostenible –
Controla tus listas y bibliotecas,
Conjunto de documentos

45
5 razones por las que es
importante clasificar la
información

04

Aplicaciones High Trust -
Parte III
11
Trabajando
programáticamente con
tipos de contenido en C#
18
Integración Continua para
Apps Office 365 con Visual
Studio Online y Azure
25

SharePoint y Azure -
Operational Insights
35

Aplicaciones empresariales
en Office 365
42

Machine Learning: Usos y
Aplicaciones
47

La importancia de diseñar y aplicar
un buen uso de Gobernanza en
nuestro entorno SharePoint 2013 (
3ª Parte ).

02
Staff

CompartiMOSS es una pu-
blicación independiente de
distribución libre en forma
electrónica. Las opiniones
aquí expresadas son de es-
tricto orden personal, cada
autor es completamente
responsable de su propio
contenido.

DIRECCIÓN GENERAL

• Gustavo Velez
• Juan Carlos Gonzalez
• Fabian Imaz
• Alberto Diaz

DISEÑO Y DIAGRAMACIÓN

• Santiago Porras Rodríguez

Contacte con
nosotros

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

BLOGS
http://www.gavd.net
http://geeks.ms/blogs/jcgonzalez
http://blog.siderys.com
http://geeks.ms/blogs/adiazmartin

REDES SOCIALES
Facebook:
http://www.facebook.com/group.
php?gid=128911147140492
LinkedIn:
http://www.linkedin.com/groups/
CompartiMOSS-3776291
Twitter:
@CompartiMOSScom

2

03

Editorial

Llegando al momento en el que SharePoint 2016 On-Premises comienza a estar disponible, podemos sacar algunas con-
clusiones sobre el futuro de SharePoint. Y, para ser honrados, aunque Microsoft nos ha dado algo de esperanzas de que la
versión On-Premises seguirá existiendo por algún tiempo más, lo que hemos podido ver de la nueva versión no es precisa-
mente para estar saltando de la alegría.

Desde la conferencia Ignite en marzo se conocen las nuevas especificaciones de SharePoint 2016. Si no lo ha hecho ante-
riormente, puede ver un resumen de lo que hay nuevo o modificado en el artículo de Bill Baer (http://blogs.technet.com/b/
wbaer/archive/2015/05/12/what-s-new-in-sharepoint-server-2016-installation-and-deployment.aspx). Como podrá obser-
var, los cambios entre SharePoint 2013 y 2016 son mínimos, y principalmente enfocados a infraestructura.

Esto nos presenta con un problema: nuestros clientes no tendrán ninguna motivación para moverse a la nueva versión. De
igual forma, si alguna compañía que tenga planes de implementar un nuevo sistema de SharePoint On-Premises (si es que
queda alguna en el mundo) y que ya disponga de licencias de 2010 o 2013, no tendrá ninguna razón para crear el sistema en
2016 teniendo que pagar por nuevas licencias.

Mejor dicho, y perdonen si hoy estamos siendo pesimistas, aunque Microsoft salvó a SharePoint de una muerte inminente
hace un par de meses, el paciente sigue con pronóstico reservado y es mejor ir pensando en donde va a ser enterrado. Algo
así como Silverlight, y muchas otras tecnologías brillantes que Microsoft ha dejado que se mueran solas, de pura vejez y
falta de mantenimiento.

Así que, si no se habían dado cuenta, la única opción viable que nos queda es SharePoint Online en Office 365. Pero no
esperen muchos cambios (o cambios radicales) en el futuro. SharePoint Online está siguiendo los pasos de Office: es un
producto maduro, que permanecerá sin cambios radicales (e interesantes) por muchos años. Los tiempos de la aventura
llamada SharePoint han desaparecido.

Esperamos que se diviertan tanto, como de costumbre, leyendo a CompartiMOSS, como nosotros nos divertimos haciéndola
(aunque ahora nos divertimos mucho menos programando a SharePoint).

EL EQUIPO EDITORIAL DE COMPARTIMOSS

3

04 Las aplicaciones High-Trust (II)

En el último artículo hablé sobre las aplicaciones high-trust
o de alta confianza (también conocidas como S2S, server-
to-server) en los entornos de SharePoint 2013. Por defec-
to, estas aplicaciones usan la autenticación Windows. Ve-
remos lo que hay que hacer para utilizar otro proveedor de
autenticación para la app.
La identidad en una high-trust app
Tal como vimos en el artículo anterior, en las high-trust
apps es la responsabilidad de la propia app establecer el
token del usuario. Es decir, la app le dice explícitamente
a SharePoint que usuario está accediendo a ella. Por de-
fecto, la implementación del TokenHelper de las apps de
SharePoint en Visual Studio sólo funciona para los usua-
rios de Windows ya que usa la clase WindowsIdentity in-
ternamente. En la mayor parte de los despliegues de una
high-trust app, todos los usuarios dispondrán de su usua-
rio de Windows así que no nos preocuparemos mucho. Sin
embargo, cuando no usamos la autenticación Windows es
cuando vamos a tener problemas.

Desde SharePoint 2010 existe la posibilidad de utilizar
un proveedor de identidad que soporte Claims (o tokens
SAML) para la autenticación en las aplicaciones web de
SharePoint. De hecho, SharePoint 2013 las usa por defec-
to. Es relativamente fácil conectar SharePoint con un pro-
veedor de identidad (IdP) compatible como puede ser Ac-
tive Directory Federation Services (ADFS) o el gratuito pero
excelente Identity Server de la empresa Thinktecture1.

El ejercicio de conectar SharePoint a un proveedor de
identidad alternativo pasa por establecer el proveedor de
autenticación como proveedor de identidad de confianza.
Además, el proveedor de autenticación tiene que registrar
SharePoint como “relying party” o consumidor de autenti-
cación de fiar. En uno de los anteriores números de Com-
partiMOSS, Diego Gatti explicó como conectar SharePoint
con ADFS2.

Imaginad que disponemos de un SharePoint habilitado
para reconocer los usuarios “federados” identificados por
un token SAML expedido por un proveedor de identidad
ADFS que está disponible en la URL https://idp.migran-
ja.com. Ahora queremos que la app que está alojada en
miapp.migranja.com se autentique mediante identidad
federada contra SharePoint.

en el artículo anterior y la lanzamos desde SharePoint,
identificados como un usuario federado, la app pedirá cre-
denciales de Windows al ser redireccionada. Como acabo
de explicar, el código estándar utiliza WindowsIdentity y la
app en el web.config tiene puesto que se use el módulo de
autenticación de Windows.

En las high-trust apps es la responsabili-
dad de la propia app establecer el token
del usuario

Arreglando la autenticación de la
app
¿Qué podemos hacer para arreglar la autenticación? El pri-
mer paso será cambiar la autenticación de la app de Win-
dows a autenticación federada por SAML. Es decir, hay que
sustituir en el apartado <system.web> del web.config de
la app la línea de autenticación de Windows y poner esta:

<authentication mode=»None» />

Con esto le decimos a la app que no use ninguna autenti-
cación. Pero entonces, ¿cómo va a saber la app que usua-
rio está autenticado? Tenemos que añadir dos paquetes
de NuGet que habilitan la autenticación federada e insta-
lan las librerías necesarias:

• Microsoft Token Validation Extension for .NET 4.5.
• Microsoft ASP.NET Identity Core.

Imagen 1.- El paquete Microsoft.AspNet.Identity.Core.

Si hacemos una high-trust app normal como la que vimos

Imagen 2.- El paquete System.IdentityModel.Tokens.ValidatingIssuerNameRegistry.

4

Con estas dos librerías instaladas hay que cambiar otra vez
el web.config para habilitar la autenticación federada que
se instala como un módulo HTTP.

Al principio de todo del fichero, en la sección <configSec-
tions>:

<configSections>
<section name=”system.identityModel”
type=”System.IdentityModel.Configuration.
SystemIdentityModelSection, System.
IdentityModel, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=B77A5C561934E089” />
<section name=”system.identityModel.services”
type=”System.IdentityModel.Services.Configuration.
SystemIdentityModelServicesSection, System.
IdentityModel.Services, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=B77A5C561934E089” />
</configSections>

Aquí hay que especificar cuatro parámetros que diferirán
entre varios entornos de federación y las apps.

• El identificador de la app como Relying Party en el pro-
veedor de identidad (uri:miapp.migranja.com). Puede
ser un URI o una URL. Esto sirve para que el proveedor
de identidad sepa que app le está pidiendo autentica-
ción.

• La URL del proveedor de identidad (idp.migranja.com).
• La URL de la federación del proveedor de identidad
(http://idp.migranja.com/adfs/services/trust). La app
usará esta URL para realizar la autenticación.

• La huella del certificado digital con el que se fir-
man los tokens del proveedor de identidad (ABC-
DEF123456789...). Esto sirve para que la app pueda
validar que el token está bien firmado y que no está
falseado.

Justo después del elemento </system.web> hay que poner
este fragmento que habilita los módulos de autenticación:

Una última edición del fichero web.config para configurar
bien las cookies de autenticación:

<system.webServer>
<modules>
<add name=”WSFederationAuthenticationModule”
type=”System.IdentityModel.Services.
WSFederationAuthenticationModule, System.
IdentityModel.Services, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089”
preCondition=”managedHandler” />
<add name=”SessionAuthenticationM