SharePoint 2010: Ejemplos de integración con Windows Azure (I)!

Con todo el mundo hablando de la nube en cada esquina y en cada momento, y con SharePoint como producto estrella de Microsoft junto con la versión del mismo en la nube que viene como parte de Office 365, hay una cierta inquietud y ganas de ver las posibilidades de la integración de ambos entornos…por suerte, ya comenzamos a tener los primeros ejemplos al respecto disponibles:

SharePoint2010_thumb

SharePoint 2010: ¿Se pueden llamar servicios desde una solución SandBox “pura”?

Recientemente una de las dudas que ha surgido en torno a las soluciones Sandbox que permiten desplegar artefactos para SharePoint 2010 sin “tocar físicamente" el servidor es si es posible llamar a servicios externos desde una solución sandbox pura, es decir, desde una WebPart o un manejador de eventos por ejemplo…lamentablemente, y como podéis consultar en este enlace, la respuesta es que por defecto no es posible para este escenario, aunque más allá de la alternativa por defecto podríamos superar esta limitación:

  • Creando un proxy “full trust” que actúe como pasarela para interactuar con ese servicio externo.
  • Crear una lista externa que apoyándose en el servicio de BCS actúe como esa pasarela y podamos usar la API de SharePoint para interactuar con el servicio.

Como alguno ya habrá deducido, estas dos aproximaciones solucionan el problema para una solución Sandbox en un escenario On-Premise…¿y con Office 365? Pues en este caso, no podemos usar estas aproximaciones ya que no tenemos la posibilidad de usarlas. Esto en el caso de una solución Sandbox pura, ya que si es cierto que podemos llamar a un servicio externo a través de:

  • La API JavaSript de SharePoint 2010.
  • Desde una aplicación Silverlight residiendo en nuestro sitio de SharePoint.

En ambos cosas, el código que ejecuta las llamadas al servicio externo no reside en el servicio de Sandbox por lo que la limitación desaparece y no es necesario recurrir a crear el proxy full-trust o el workaround con las listas externas. La desventaja es que esta aproximación no es una solución Sandbox pura Triste.

SharePoint 2010: Modelo de seguridad!

Como ya he comentado en este blog, cuando trabajamos con SharePoint 2010 es fundamental tener muy claros los bloques fundamentales de su arquitectura. Uno de estos bloques o piezas clave es el modelo de seguridad que protege el sistema tanto de errores en código como de errores de los usuarios. Los elementos del modelo de seguridad en SharePoint son los siguientes:

  • Seguridad de usuario, SharePoint soporta de acceso a nivel de sitio, lista, carpeta y elemento. La gestión de la seguridad se basa en un sistema de roles y niveles de permisos que determinan que puede hacer cada usuario autenticado en función del rol y sistema de permisos asignado. En cuanto a la autenticación del usuario, SharePoint confía en sistemas externos, ya sea para autenticación Windows o no, es decir, no implementa un mecanismo de autenticación per-se.

image

  • Autenticación, se soportan varias formas de autenticación. El mecanismo por defecto es autenticación Windows basada en Claims (aunque por compatibilidad con SharePoint 2007 también tenemos la opción de autenticación de Windows en modo clásico o legacy). El modelo de identidad basado en Claims de SharePoint está construido sobre Windows Identity Foundation (WIF) e identifica a un usuario en SharePoint como una identidad que tiene asociada un conjunto de “Claims” representando el nombre del usuario, su e-mail, etc. El modelo de Claims implica que se ha configurado un sistema de identidades externo que proporciona a SharePoint toda la información necesaria sobre el usuario que accede. Para más información sobre el modelo de autenticación basado en Claims en SharePoint:
  • Autorización, el acceso a sitios listas, carpetas y elementos de lista se controla mediante el sistema de roles comentado que permite asignar usuarios o grupos de usuario a uno o varios niveles de permisos (o definición de rol) que determinan que puede hacer el usuario a estos niveles. Por defecto, SharePoint utiliza un sistema de permisos heredable, es decir, los permisos se heredan de forma jerárquica desde el nivel más alto (sitio) al nivel más bajo (elemento) en la jerarquía de objetos de SharePoint a nivel de sitio…esta herencia se puede romper en cualquiera de estos niveles dando lugar a situaciones de exclusividad de permisos. A nivel de grupos de usuarios, se soportan dos tipos:
    • Grupos de SharePoint, definidos en el ámbito de una colección de sitios y por lo tanto no re-utilizables fuera de este ámbito.
    • Grupos de dominio, definidos fuera del ámbito y control de SharePoint y completamente re-utilizables.

image

Y hasta aquí llega este post sobre el modelo de seguridad en SharePoint.

SharePoint 2010: ¿Qué características de BCS tengo en SharePoint Foundation vs SharePoint Server?

Una pregunta que surge con frecuencia cuando se habla de los Business Connectivity Services (BCS) en SharePoint 2010 es la de que características están presentes en SharePoint Foundation y cuales en SharePoint Server. Por suerte, la respuesta a esta cuestión la tenemos en este enlace y se resumen en la siguiente figura.

Feature sets of BCS, SharePoint, and Office

Además, la tabla que viene en el artículo al que hago referencia permite conocer en detalle las características del BCS por versión de SharePoint, además de proporcionar el detalle al final del mismo (clientes Office incluidos):

Business Connectivity Services Feature
SharePoint Foundation 2010 SharePoint Server 2010 Standard Edition SharePoint Server 2010 Enterprise Edition
External List
External Data column
Business Data Connectivity (BDC) service
Connector Framework
Secure Store Service  
External Data Search  
Profile Pages  
Business Data Web Parts    
Rich Client Integration    

SharePoint Camps en Madrid, Barcelona y Santander…el resumen!

Esta semana ha concluido la tercera sesión de los SharePoint Camps que hemos celebrado en Santander y que ha sido la continuación de  las ediciones de Madrid y Barcelona. La experiencia ha sido muy buena y espero que se repita en años venideros gracias al apoyo de Microsoft Corporation que ha sido el origen de estos Camps…por hacer un pequeño resumen de como han ido los Camps:

  • Han participado en total más de 60 personas en las sesiones de training realizadas en cada ciudad. Os recuerdo que los materiales del training los podéis encontrar a través de este post: SharePoint 2010- Materiales de los eventos de la semana pasada!
  • En la parte de pruebas de concepto, los resultados han sido muy buenos: las empresas participantes  han desarrollado una serie de funcionalidades que demuestran las posibilidades de extensibilidad de la plataforma y además tendrán la oportunidad de mostrar sus soluciones al equipo de METRO en DPE EE.UU con lo que tendrán una alta visibilidad al otro lado del charco de lo que se sabe de SharePoint en España Sonrisa, y no sólo eso, seguro que alguna de las pruebas que se presente dará que hablar y les dejará asombrados.

A nivel particular, los Camps me han servido para conocer a gente que está muy metida en el mundillo de SharePoint y que no tenía controlada Lengua fuera y sobre todo para demostrarme una vez más que pretender saber de todo de SharePoint es una tarea imposible, pero que con este tipo de trainings aprendemos tanto los ponentes como los asistentes, vemos los problemas reales que el uso de la plataforma ocasiona, carencias, etc. Finalmente, quería agradecer a todos los que habéis participado en los Camps vuestra presencia en los mismos y sobre todo vuestra pasión por SharePoint…algo está cambiando en el sector de nuestro servidor favorito en España y ese cambio es gracias a la comunidad tan fuerte que estamos formando…a seguir así. Y como no, aquí van las fotos resumen de los Camps:

  • SharePoint Camps en Madrid:
P1310004 P2020008 P2040014
  • SharePoint Camps en Barcelona:
P2150017 P2150020 P2170022
  • SharePoint Camps en Santander:
P2220049 P2220050 P2220051

Otros posts relacionados:

SharePoint 2010: ¿Se puede conseguir la visualización Visio de flujos creados en VS 2010?

Como sabéis, en SharePoint 2010 tenemos la posibilidad de crear flujos de trabajo en tres entornos diferentes: Visio, SharePoint Designer 2010 (SPD 2010) o Visual Studio 2010. Además, podemos pasar los flujos de trabajo creados de uno a otro entorno:

  • Podemos crear un flujo de Visio e importarlo en SPD 2010 para completarlo y a la inversa.
  • A su vez, un flujo de trabajo creado en Visio y completado con SPD 2010 se puede importar en VS 2010.

Cada entorno de creación y en función de si estamos con SharePoint Foundation o Server, tiene sus particularidades. Una de ellas la tenemos en la posibilidad de disponer la visualización de un diagrama Visio que muestre en tiempo de ejecución un workflow que se ha creado con SPD 2010 (para que esto sea posible, necesitamos Visio Services y por tanto disponer de la versión Enterprise de SharePoint 2010)…¿Y con VS 2010? Pues por defecto, los flujos creados con VS 2010 no se muestran renderizados en un diagrama Visio…ahora bien, gracias a Manuel Guadarrama de STPNET, conocí el siguiente workaround que os dejo como referencia:

SharePoint2010_thumb

SharePoint 2010: ALM en SharePoint!

Algo que últimamente está en boca de todos es si el concepto de ALM (Application Lifecycle Management) aplica en el desarrollo para SharePoint. La respuesta es que sí, otra cosa es que se parezca más o menos al ciclo de vida de aplicaciones software convencionales. En SharePoint 2010 frente a SharePoint 2010 contamos con una mejor soporte para ALM gracias a la mejor integración de Visual Studio 2010 (a través de las herramientas de desarrollo para SharePoint) y TFS en el desarrollo para SharePoint. En este sentido, hay una serie de recursos que reflejan esta idea y que es importante tener siempre a mano cuando hablamos de ALM y SharePoint:

SharePoint2010_thumb

SharePoint 2010: Limitaciones en las soluciones Sandbox (II)!

Como continuación al primer post sobre limitaciones en las soluciones SandBox en cuanto a que tipo de artefactos se pueden crear y el ámbito a nivel de desarrollo en el que nos podemos mover (Colección de Sitios hacia abajo), en esta ocasión quería entrar en un poco más de detalle en estas limitaciones teniendo en cuenta el modelo de ejecución de las soluciones SandBox. Básicamente, todo el código que corre dentro del servicio de SandBox está sujeto a una serie de restricciones tanto de ejecución como de acceso. Hay dos sistemas de restricciones:

  • Uno que se aplica únicamente a toda llamada que se realice a cualquier ensamblado exceptuando Microsoft.SharePoint.dll.
  • Otra que se aplica únicamente a toda llamada que se realice al modelo de objetos SharePoint incluido en Microsoft.SharePoint.dll y otros ensamblados como Microsoft.SharePoint.Linq.dll.

Request processing model in sandboxed solutions

¿Cómo se aplican estas restricciones? Para el primer tipo de llamadas a ensamblados, se definen dos mecanismos:

  • Una política muy restrictiva de seguridad de acceso a código (CAS) que se encarga de limitar lo que el código ejecutándose en el proceso de SandBox puede hacer (Nota: Esta política si permite acceder a ensamblados de Microsoft Office con un “strong-named”). Esta política se encuentra definida en el archivo web.config bajo la ruta %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG,  impone restricciones como:

image

    • La imposibilidad de llamar a código no manejado desde el código de una solución SandBox.
    • La imposibilidad de llamar a las APIS de reflexión de .NET Framework 3.5 desde el código de una solución SandBox.
    • La condición de que para poder llamar desde código de una solución SandBox a ensamblados de .NET Framework 3.5 se necesita que tengan el atributo AllowPartiallyTrustedCallersAttribute.
   1: <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

   2: <configuration>

   3:   <system.web>

   4:       <httpModules>

   5:          <clear/>

   6:       </httpModules>

   7:     <httpHandlers>

   8:       <add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="true"/>

   9:     </httpHandlers>

  10:     <securityPolicy>

  11:       <trustLevel name="WSS_Sandbox" policyFile="..\config\wss_usercode.config" />

  12:     </securityPolicy>

  13:     <trust level="WSS_Sandbox" originUrl="" />

  14:   </system.web>

  15:   <runtime>

  16:     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

  17:       <probing privatePath="assemblies" />

  18:       <dependentAssembly>

  19:         <assemblyIdentity name="Microsoft.SharePoint" publicKeyToken="71e9bce111e9429c" culture="neutral" />

  20:         <bindingRedirect oldVersion="0.0.0.0-14.900.0.0" newVersion="14.900.0.0" />

  21:       </dependentAssembly>

  22:     </assemblyBinding>

  23:   </runtime>

  24: </configuration>

  • A través de un token de seguridad con privilegios mínimos que impide que el worker process del servicio de SandBox:
    • Tenga permisos para leer o escribir en el sistema de archivos.
    • Tenga permisos para realizar llamadas a la red, de forma que solo se pueden acceder a recursos disponibles en el servidor dónde se está ejecutando el proceso.
    • Tenga permisos para escribir en el registro.
    • Tenga permisos para llamar a cualquier ensamblado que no esté en la GAC, incluso aunque disponga del atributo AllowPartiallyTrustedCallersAttribute.

Para el segundo sistema de restricciones, se define una versión “shim” del MO de servidor de SharePoint que junto con el MO completo son cargados por uno de los dos procesos que constituyen el servicio de SandBox (en concreto por SPUCWorkerProcessProxy.exe) que impiden que se llamen a objetos de la API no permitidos desde una solución SandBox. Además, existen otros dos ensamblados que son usados por este sistema y que se cargan en el Worker Process del servicio de SandBox (Microsoft.SharePoint.UserCode.dll) y en el proxy comentado (Microsoft.SharePoint.SubsetProxy.dll). El mecanismo de uso de estos ensamblados “shim” por los procesos del servicio de SandBox es el siguiente:

  • Cuando una solución SandBox hace uso de un parte permitida de la API de SharePoint, el primero de los ensamblados pasa la llamada al segundo en el proceso de proxy, que a su vez la pasa a la API estándar en Microsoft.SharePoint.dll.
  • Los resultados de la llamada realizad se pasan al código original que la realizó.

Como ejemplo de restricción en cuanto al uso del MO de SharePoint tenemos:

  • No se puede acceder a la clase SPWebApplication ni a cualquiera definida bajo Microsoft.SharePoint.Administration.
  • No es posible realizar una elevación de privilegios en el código que se ejecute en modo SandBox.
  • No se pueden usar los controles definidos en Microsoft.SharePoint.WebControls de manera que estamos restringidos al uso de controles ASP.NET.

El listado completo de APIs dentro de Microsoft.SharePoint.dll que se pueden usar lo podéis encontrar aquí Microsoft.SharePoint.dll APIs Available from Sandboxed Solutions. Finalmente, otra limitación ya comentada en este blog es que a nivel de despliegue de una solución SadnBox está prohibido incluir cualquier tipo de archivo que se tenga que copiar en el servidor físico como controles de usuario, páginas de aplicación, o imágenes. Para más información recomendable ver SharePoint Deployment Models.

SharePoint 2010: Alternativas para montar el entorno de desarrollo (II)!

Siguiendo con la serie de post sobre alternativas para montar el entorno de desarrollo para SharePoint 2010, en esta ocasión voy a comentar otra posibilidad que tenemos dentro del movimiento de irnos “todos a la nube” Guiño…esta alternativa implica que nuestro entorno de desarrollo esté disponible en algún proveedor de servicios en la nube como puede ser Arsys en España, Amazon como ya nos ha explicado Mario Cortes o en la propia plataforma Azure de Microsoft …aunque en este post no voy a tratar este caso, sino que voy a hablaros de Cloudshare que es plataforma de cloud computing en modo autoservicio que facilita la creación de entornos virtuales para realizar demostraciones, pruebas de concepto o incluso formaciones…todo depende del tipo de suscripción adquirida. En mi caso, he tenido la suerte de poder contar con una invitación para usar Cloudshare Pro que facilita la creación rápida de estos entornos virtuales ya sean limpios o en base a plantillas predefinidas:

  • Crear un entorno es tan sencillo como pulsar el botón “Create new environment”. La licencia Pro sólo permite crear un entorno, pero en él podemos disponer de varias máquinas virtuales y crear snapshots del entorno para compartir con terceros…de hecho, disponemos de nada menos que 1.000 invitaciones que permiten usar los snapshots creados por un período de 48 horas…cool.
  • A la hora de crear una máquina virtual en el entorno, tenemos varias plantillas disponibles. Entre ellas una para SharePoint 2010 Sonrisa.
  • Una vez definido el entorno, basta con pulsar el botón View Environment para que las máquinas virtuales se arranquen. Estas máquinas las podremos acceder desde el explorador o bien por escritorio remoto Sonrisa
image image image
  image  

Por supuesto, podremos editar el entorno en todo momento y añadirle nuevas máquinas virtuales.

image

WSS 3.0 & MOSS: Compatibilidad de Office 2010!

El otro día planteaban en los foros de SharePoint un problema sobre la integración entre SharePoint 2007 (WSS 3.0 & MOSS) y Office 2010…la verdad, cuando ví el thread tampoco me sorprendí mucho en cuanto a que Office 2010 es una versión superior a las que soporta SharePoint 2007, aunque no debería dar ningún problema en cuanto a que Office 2010 es una evolución de Office 2007. Sin embargo, la integración es diferente como podéis ver en este thread. Por eso, cuando surja la duda sobre como se integra Office 2010 con SharePoint 2007 lo mejor es bajarse el siguiente documento creado por Microsoft en el que podemos ver que se soporta y que no en SharePoint 2010 en función de si trabajamos con Office 2010 u Office 2007 y extrapolarlo al uso de Office 2010 en SharePoint 2007.