What I Learned at SharePoint Saturday Stockholm

As I mentioned in my previous post, last weekend was well spent with the SharePoint Saturday crowd in Stockholm, Sweden. In this post I want to highlight what I have learned from it. It was very difficult to choose which session to attend , as I had my own session to worry about.

What I learned at SharePoint Saturday Stockholm 2015


There were two very good sessions about JavaScript in SharePoint.

The first one was called “SharePoint JavaScript, Doing It Right” and it was presented by Hugh Wood, very knowledgeable guy from Rencore (by the way, they are the makers of SPCAF, pay them a visit). He summarized his detailed posts on SharePoint JS inner workings. If you haven’t read them before, you don’t know what are you missing.

The other session was called “Mixing power of CSR with flexibility of KnockoutJs: three examples” and it was presented by Andrei Markeev. I couldn’t attend it but I spoke with Andrei and I am really looking forward to see the slides and the sample code. Andrei’s GitHub repository has some very good things to have in SharePoint arsenal: a CSR live tool (Cisar) and CAML JS console.


The second thing I learned in Stockholm was just how awesome is the new workflow development experience with Visual Studio. SharePoint 2013 and Office 365 workflows use the new, external engine and all the calls are client-side code, either JS in SharePoint or REST API on your servers.

The session was called “Advanced SharePoint Workflow Scenarios” and was flawlessly presented by Paolo Pialorsi from PiaSys. If you haven’t heard about Paolo, which is very doubtful, he is the guy who wrote The Book on SharePoint Development and he’s one of the brightest SharePoint people I know. Check his slides and source code, there is a trove of information there. Grazie, Paolo!

Full-Trust Code to SharePoint Apps Transformation

Another session I liked was called “Transforming SharePoint Farm Solutions to the App Model” and presented by another Rencore genius and one of the founders of SharePoint Saturday Stockholm, Matthias Einig. He outlined the SharePoint development roadmap and the main obstacles from moving to the cloud. I think that it was a sober assessment of the state of SharePoint development right now.


Were you at SharePoint Saturday Stockholm 2015? What did YOU learn?

SharePoint Code Maintainance and Unit Testing Talk at SPS Stockholm

Last weekend I have attended another SharePoint Saturday, this time in Stockholm. The weather was nicer than the last year, and the attendance was over the top: 300 attendees to learn about and discuss SharePoint topics from the expert speakers.

The speaker lineup for SharePoint Saturday Stockholm

My talk was about how to build SharePoint code that’s both maintainable and testing-friendly. I have approached the talk from the coarse to finer detail, from the distribution of the solution components into SharePoint to the dependency injection mechanisms and principles of SOLID and GRASP object-oriented design.

Me speaking about maintainable and testable SharePoint codeThe attendees at SharePoint Saturday Stockholm

The demo I shared with the attendees was a very simple SharePoint provider-hosted app in ASP.NET MVC that displays the user full name and the login username. I started with a very coupled code that all sat in the Index action in the controller and I ended with a testable design that had the SharePoint ClientContext dynamically injected to the service at runtime, dutifully abstracted behind an interface. I used Unity IoC container and Moq for mocking the dependencies in the tests.

You can find the slides at my SlideShare page, as usual, and the source code for the demo (in a form of a Mercurial repository) on my OneDrive. I have received some very good comments about the topic and the techniques mentioned in the session.

If you have attended my session at SPS Stockholm, I have questions for you.

  • What have you liked most?
  • What haven’t you liked at all?
  • What could be done better?

Let me know how can I improve the talk for future events.

What to Expect from SharePoint 2016

Well, it has been doubted lately but Microsoft has finally spilled the beans on the next on-premise version of SharePoint. Office General Manager Julia White has posted the news under the title “Evolution of SharePoint” on the Office Blogs few days ago and it has stirred the SharePoint blogosphere quite a bit.

I won’t repeat Julia’s post but I would like to comment a little bit on the implications of the SharePoint 2016 as it has been described in it. In one of my prior blog posts I speculated about the future of SharePoint, and I can see that I haven’t been too misguided.

The SharePoint Continuum

One of the most striking things in Julia’s post is this diagram that illustrates the new SharePoint landscape. It has “blue” on-premise pieces and “orange” cloud pieces, connected with the arrow that says “Hybrid”. I have named it “The SharePoint Continuum” (but without Q, for these Trek-leaning among you)


For me it’s one of the most important clarifications in Microsoft messaging to the SharePoint customers in the last couple of years. It shows that Office 365 is not there to replace, but to complement your on-premise capabilities. It took me some time to get this message clear, and I can imagine how out-of-the-blue statements and unclear announcements made this easy to understand for the IT business decision makers (sarcasm intended).

So, now that we know that the next SharePoint Server will be there and it will connect, let’s make an educated guess about what it will bring to us. (Later, when I re-read this post in the light of Ignite announcements, I will check how clear my crystal ball was in making it).

What should IT Pros expect?

I am absolutely sure that IT Pros will have A LOT to learn about how to seamlessly integrate SharePoint Server 2016 with the experiences offered by Office 365. Now that Azure Active Directory (AAD) is emerging as “the” authority for hybrid scenarios for authentication and authorization, the roadmap and the guidance for enabling hybrid SharePoint experiences will become more straightforward and prescriptive. These hybrid experiences will be the lifeline that connects your on-premise environment with all the workloads that are kept “on the ground” with the exclusive experiences only available on your Office 365 tenant. Hopefully, the end user won’t see the seams in between.

Another thing that SharePoint 2016 will vastly improve is the administration, monitoring and diagnostics. This is a logical assumption to make as Microsoft has undoubtedly accumulated a vast know-how about how to run SharePoint core engine as smoothly as possible. I can only imagine that SharePoint 2016 will include this in the form of helpful administration pages, automatic recommendations (a la Health Checks but tapping into Microsoft “recipe” base) and hopefully a streamlined SharePoint log management.

I’d also expect some new and streamlined farm topologies, also drawing from the experience of running Office 365 continously. I am sure that SharePoint core services and processes have been trimmed for any excess resource consumption and we should be able to benefit from it.

What should end users expect?

The end users will hopefully have a very good time with SharePoint 2016. Let me elaborate.

If you don’t connect SharePoint 2016 to the cloud and keep running strictly on-premise, I expect that most of the obnoxious SharePoint annoyances to be rid of. I expect a more direct and clean UI, with prominent navigation (a la Office 365 “jumbo” bar) and deemphasized secondary options that light up as you hover. It would declutter the UI a little bit and would reduce the user distraction. I don’t see revolutionary new features, but a subset of what has already been made available for Office 365. Hopefully, some of the new Cards UI or the NextGen portals interactions will trickle down to SharePoint 2016.

Once your SharePoint 2016 connects in a hybrid on-premise/cloud farm, I expect that the end users won’t be aware of the change. They will consume “the experiences”, irrespective of where they are coming from. If SharePoint experts help design seamless navigation and information architecture, I can hardly wait to see hybrid environments where SharePoint does its best: run behind the scenes and out of spotlight.

The Groups experience is the new overarching “concept” that includes a site, email group, social group, common files and so on. I expect the UI to further deemphasize “sites” and “lists” terminology to favour “groups” and “apps“.

As for social, the message is clear: Yammer is the only official way forward. The on-premise social capabilities will stay at SharePoint 2013 level (as per Jeff Teper’s post at SPC14).

In Search capabilities, I expect hybrid search on-premise/cloud to work without any jarring discrepancies. New display templates inspired in Delve UI could only mean icing on the cake.

I really hope for InfoPath replacement codenamed FoSL (Forms on SharePoint Lists) to be there, but there have been no news about it since it was previewed at SPC14. I wouldn’t bet on it but maybe it will make the way to the SP2016 code.

However, I also can see a few SharePoint Out-of-the-Box capabilities disappearing. For instance, Business Intelligence capabilities will most probably be replaced by the new free PowerBI tier and somehow linked to the powerful cloud BI. PerformancePoint Services? Dead end.

What should developers expect?

I have to admit that my developer community will be the one facing most changes, but they will be good ones. As much as the shift from the full-trust code to cloud app model (or FTM to CAM, to keep Microsoft three-letter-acronym, TLA, strategy in place) is painful, it is also exciting. We will be forced to get out of the cozy SharePoint development box we have been living since the beginning.

I don’t drink app Kool-Aid and I certainly see the painful shortcomings of the new model. But, I have to admit that the Office 365 PnP Guidance is steadily evolving and the gaping API holes in CSOM are being patched. We will have to keep unearthing them and make enough noise so they keep being fixed.

The app model is not going to follow sandboxed code or auto-hosted apps, it will be the backbone of the unified SharePoint development model. I expect the manual steps in the development workflow to become streamlined (being honest, typing AppRegNew.aspx manually is a major PITA inconvenience). The AAD authentication and authorization with OAuth will take the place of ACS middleware, and I also expect high-trust apps to add a few refinements too.

The Office 365 API “abstracts” SharePoint, Exchange and OneDrive into Files, Contacts, Calendar and other business-like entities. I expect this “development continuum” to keep evolving:

  • Azure Active Directory (AAD) as the one-stop authentication and authorisation gate
  • Office 365 API as a task-oriented, high-level API for our apps
  • SharePoint CSOM/REST API as implementation detail, low-level API for our apps
  • And, of course, SharePoint full-trust server object model for these things we still can’t run in the cloud

As I said, developers will also have exciting times with the new SharePoint 2016. And the best thing is that the most of the playing pieces are already available on Office 365 and SharePoint 2013, so that we can future-proof our developments now.


In the official announcement of SharePoint 2016 few days ago I can find confirmation (of what I was thinking will happen) and clarification (of the message to the SharePoint community). I can’t wait to see what new scenarios we will be building on these new foundations.

The sky cloud is the limit!

What do YOU think? Leave a comment to join the discussion!

Modelo de apps en detalle (IV): Construyendo una app High-Trust

En la última entrega de esta serie de posts sobre el modelo de apps en detalle, hablé de las aplicaciones Low-Trust y aplicaciones High-Trust de SharePoint 2013. Pues bien, hoy vamos a meternos en la harina y hacer una aplicación high-trust (también conocida como S2S, server-to-server) desde cero.

Preparando el entorno

Servicio de perfiles

Para comenzar a crear una aplicación high-trust, necesitamos configurar varias cosas en nuestro entorno local de SharePoint 2013. (Recordáis que las app high-trust sólo se pueden tener en un SharePoint on-premise, ¿verdad?). Las configuraciones no son muchas, pero es fácil olvidarse de una de ellas y luego tendremos problemas para investigar de donde viene el error.

Antes que nada, necesitamos que nuestro SharePoint 2013 tenga activo el servicio de perfiles de usuario y que además tenga indexados los perfiles de los usuarios que vamos a utilizar en la aplicación. Esto es necesario porque el servicio de autenticación de una app high-trust necesita “encontrar” el usuario en el servicio de perfiles de SharePoint para poder ejecutar las consultas en su nombre. Si el perfil del usuario no está, la autenticación fallará.


Realmente, el token de acceso que envía la app hacia SharePoint contiene el identificador del usuario, y SharePoint se basa en él para saber si el usuario es válido o no, buscándolo en su base de datos de perfiles. El identificador suele ser el SID del usuario Windows, su UPN o nombre de usuario de Active Directory. Si usamos otros sistemas de autenticación como FBA o Claims, los identificadores serán otros. Es estrictamente necesario que el identificador del usuario esté presente en su perfil y que no haya repeticiones. Si os pica mucho la curiosidad, hay un excelente post de Steve Peschka al respecto.

Certificado SSL

Para poder firmar el token de la app, necesitamos un certificado SSL. Mientras desarrollamos, podemos usar un certificado de desarrollo firmado por nosotros mismos (self-signed certificate). Luego, en producción, usaremos un certificado real.

Además, para que nuestra app se pueda comunicar con SharePoint de manera segura, necesitamos que la comunicación esté encriptada bajo HTTPS. Para ello, necesitaremos otro certificado SSL con la URL de la app. Esto no es necesario en desarrollo, donde podemos relajar la restricción y usar HTTP, pero en producción esto sería una imprudencia seria.

Para crear un certificado autofirmado, iremos a la consola de IIS y bajo el apartado “Server Certificates” y dentro de él la opción “Create Self-Signed Certificate“. Le daremos el nombre CertificadoHighTrust.


Al final, exportaremos el certificado incluyendo la clave privada. Como contraseña le pondremos “password“. Al final, tendremos un fichero PFX con el certificado digital que usaremos en nuestra app. Este fichero tiene que estar en una carpeta accessible desde Visual Studio. En nuestro caso, como estamos desarrollando en una máquina de SharePoint, no tenemos que mover el fichero y lo tendremos en la ruta C:\Certificates\CertificadoHighTrust.pfx.


También haremos una exportación del certificado sin la clave privada, para obtener el fichero CertificadoHighTrust.cer. Para ello, tenemos que ir a “Server Certificates” dentro del IIS, abrir el certificado y en la pestaña “Details” ir a la opción “Copy to file” indicando que no queremos la clave privada.


Ahora vamos a comprobar los permisos necesarios para que SharePoint pueda procesar nuestros certificados. Los requerimientos son dos:

  • El application pool SecurityTokenServiceApplicationPool tiene que tener permisos de lectura sobre la carpeta de los certificados
  • El application pool de la aplicación web en la que instalaremos la app (en nuestro caso, la del puerto 80) tiene que tener permisos de lectura sobre la carpeta de los certificados

En nuestro caso, son las cuentas SPFarm y SQLSvc. Les daremos los permisos correspondientes en la carpeta Certificates.


Ahora tenemos que hacer que SharePoint reconozca nuestro certificado. Abrimos una consola PowerShell de SharePoint y registramos el certificado como de confianza.


Configurar trusted issuer

Una vez que SharePoint se fía de nuestro certificado, vamos a proceder a configurar lo que se conoce como un “emisor de confianza“. Esto no es más que indicarle a SharePoint que los tokens firmados por un “emisor de confianza” son de fiar. Y, ¿cómo sabe SharePoint qué un emisor es de confianza? Primero, el ID del emisor (un GUID que va dentro del token) tiene que existir en la configuración de SharePoint. Segundo, el token tiene que estar firmado por un certificado del que SharePoint se “fía” porque tiene su parte pública. Como esta parte del certificado la hemos hecho ya, sólo falta decirle a SharePoint el ID de nuestro proveedor de confianza. Puede ser cualquier GUID, y aquí vamos a utilizar el aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee (si usamos letras en el GUID, tienen que ser en minúscula). Bonito y fácil de recordar, ¿verdad?

Para registrar nuestro emisor de confianza, hay que ejecutar el siguiente código en PowerShell, a continuación del script de importación del certificado:


Ya podemos proceder a desarrollar la app, pero antes de esto vamos a permitir el uso del certificado autofirmado relajando los permisos de autenticación. (ojo: esto se puede hacer sólo en los entornos de desarrollo, nunca en producción).


Desarrollando la app

La app necesitará el certificado SSL y conocer la contraseña de su parte privada. Además, la cuenta bajo la que se ejecutará la app (el application pool del IIS) tiene que tener permisos para acceder a la ubicación del certificado.

Abrimos Visual Studio 2013 y creamos una app de SharePoint 2013. Al salir el asistente, le indicamos que queremos una app provider-hosted y que la identidad de la app se establecerá mediante certificado.


Ahora tendremos una aplicación (en mi ejemplo, creada con Web Forms) que muestra el nombre del sitio actual de SharePoint donde está instalada la app. La solución consiste en dos proyectos: el proyecto de la app de SharePoint y el proyecto web donde está la lógica de la app.


El código que hace la llamada a SharePoint es muy sencillo:



Como se puede ver, el contexto de SharePoint se establece usando la clase auxiliar TokenHelper con el método GetS2SClientContextWithWindowsIdentity. Esta llamada obtiene un contexto de high-trust app (S2S, server-to-server) usando la identidad del usuario Windows que está ejecutando la aplicación. Esta es la configuración por defecto, pero se puede modificar para usar la identidad federada por ejemplo.

Ejecutando la aplicación, nos sale el diálogo de otorgar permisos a la aplicación, y al aceptarlo, podemos ver el título del sitio de SharePoint, “Home”.


Dentro del TokenHelper

Vamos a ver como nuestra aplicación construye el token. Si miramos el método GetS2SClientContextWithWindowsIdentity, veremos que su cuerpo tiene 4 lineas de código.

Primero se obtiene el dominio (realm) de la aplicación. Acto seguido se obtiene un JWT (JSON Web Token) que contiene los claims del usuario actual de Windows. Una vez que tenemos el token JWT, lo empaquetamos en un token de acceso con el método GetS2SAccessTokenWithClaims. Al final, el token de acceso lo intercambiamos por un contexto cliente de SharePoint.
La parte interesante es ver como se hace el token. Si miramos el método GetS2SAccessTokenWithClaims, veremos que acaba en un método IssueToken, que está construyendo el token de acceso.


El siguiente artículo de MSDN explica las partes del token de acceso que construye nuestra aplicación. En esencia, se construye un token de “actor” que identifica el usuario actual. Este token de actor se hace con los claims del usuario creados previamente. El token se expide para la aplicación actual (parámetro “aud“) y lo firma nuestro certificado (propiedad SigningCredentials). Este token interno se rodea de un token externo que no está firmado digitalmente.
Como se puede ver, el misterioso “token de acceso” es nada más que una cadena de texto con datos en formato JSON que describen una identidad de aplicación y de usuario.
La última parte “misteriosa” es saber como obtiene SharePoint el objeto ClientContext a partir de un token? Es muy sencillo: adjunta el token de acceso en la cabecera de la petición a la API, y al volver ya estará inicializado correctamente el contexto. Ahora lo veremos con Fiddler.

Las pruebas con Fiddler

Si abrimos Fiddler para ver el tráfico HTTP entre la aplicación y SharePoint, veremos que la aplicación hace una llamada a la API CSOM (/_vti_bin/client.svc/ProcessQuery). Si miramos la petición, en las cabeceras veremos un parámetro llamado Authentication con el valor “Bearer: ” seguido de un texto codificado en Base64. Este es nuestro token de acceso.


Si usamos alguna herramienta como JWT.io para descodificar el token, podemos ver su estructura.


Para más información sobre la estructura del token, hay un magnífico post de Kirk Evans al respecto.


Espero haber desmitificado un poco el mundo de las aplicaciones High-Trust con este post. Como veréis, nos permite usar el modelo de apps sin tener que estar en la nube, lo que es un paso importante para poder adaptar nuestros desarrollos a los escenarios híbridos que parece que serán mucho más habituales en el futuro.

¿Habéis trabajado con este modelo? ¿Podéis compartir vuestras experiencias? ¡Los comentarios os esperan aquí mismo, debajo de este post!