次の方法で共有

Planificar la infraestructura necesaria para el nuevo modelo de aplicaciones de SharePoint 2013

  • [アーティクル]

Artículo original publicado el martes, 4 de septiembre de 2012

SharePoint 2013 trae consigo un nuevo modelo de aplicaciones al que nos referimos como "modelo de aplicaciones" o "modelo de aplicaciones de nube". Mientras que, desde una perspectiva de desarrollo, aporta una amplia nueva gama de oportunidades, también conlleva requisitos de infraestructura que necesita planificar y crear para darles compatibilidad. De hecho, si me paro a pensar en el modelo de aplicaciones, realmente existen tres grandes partes que tomo en consideración:

  1. El modelo de desarrollo. Cómo voy a desarrollar la aplicación, de qué nuevas características voy a sacar partido, etc. Esta es principalmente una actividad para desarrolladores.
  2. El modelo de seguridad. El modelo de seguridad de estas nuevas aplicaciones es una interesante combinación de todo un poco Existe el nuevo concepto de "aplicación principal", que es cómo define los derechos de las aplicaciones. Existe el modelo OAuth, que define a qué contenido puede acceder, así como mecanismos para presentar SharePoint con un token que describe quién es usted: es prácticamente como las notificaciones de aplicaciones. El modelo de seguridad y el medio por el que se crean y se presentan estos tokens varía significativamente dependiendo de si la aplicación está hospedada en SharePoint o en algún otro lugar y de si utiliza Servicios de control de acceso (ACS) como agente de confianza o no. Estamos ante mucha información y en este artículo no se hablará de toda ella, pero esta actividad sí concierne tanto a desarrolladores como a profesionales de TI.
  3. La infraestructura: todo el mejunje que hace que las aplicaciones funcionen dentro de una organización. Contiene las aplicaciones del servicio, el dominio y el prefijo de aplicación y las configuraciones de aplicación DNS y SSL. Principalmente es una actividad para profesionales de TI y constituye la base del artículo de este blog. El artículo también se centrará en aplicaciones hospedadas en SharePoint en oposición a una aplicación hospedada externamente en otro sitio o en la nube, como Windows Azure. Cuando instala una aplicación hospedada en SharePoint, se crea para ella una nueva SPWeb. De ese modo, cada aplicación obtiene su propio conjunto de datos y no puede sobrescribir los datos de otra aplicación. También proporciona una capa de seguridad para que alguien que tenga permisos para una aplicación no pueda disponer de código malintencionado que utilice los derechos del usuario actual para obtener acceso a datos en otro sitio de la granja. Esta es una entidad de seguridad básica importante de aplicaciones basada en el nuevo modelo de aplicaciones que se ha de recordar: cuando se hospedan en SharePoint, una aplicación equivale a una SPWeb.

Ahora comencemos a trabajar con la lista de los diferentes componentes de infraestructura. En primer lugar, es recomendable que se asegure de que se ha creado una instancia de las aplicaciones de servicio Administración de aplicaciones y Configuración de suscripciones y de que se está ejecutando en la granja. El servicio de administración de aplicaciones se utiliza, por ejemplo, para llevar un seguimiento de aplicaciones y desarrollos, para la creación de licencias, etc. El servicio de configuración de suscripciones es la misma aplicación de servicio que se utiliza para implementaciones multiempresa; también lo utiliza el modelo de aplicaciones para crear las direcciones URL únicas que utilizan las aplicaciones.

¿Cómo se crean estas direcciones URL? Pues bien, se comienza con la configuración de las aplicaciones que establece en la Administración central. Si va a la Administración central encontrará una nueva sección llamada Aplicaciones. Si hace clic en ella, verá una opción para Configurar direcciones URL de aplicación. Ahí encontrará dos valores que se utilizan para crear una dirección URL de aplicación: el Dominio de aplicación y el Prefijo de aplicación. El Dominio de aplicación es análogo al nombre de host que se va a utilizar para todas las aplicaciones de la granja. A la hora de planificar este nombre, existen tres aspectos que se han de considerar:

  1. Como se utiliza para toda la granja, debería obtener el mismo nivel de planificación y de preparación que utiliza para las otras aplicaciones web. 
  2. Además de esto, tiene que ser un nombre de dominio completo. Si en su lugar trata de utilizar un nombre estilo NetBIOS, verá que en lo referente a la resolución de nombres no funciona bien. 
  3. Por último, NO debería ser un dominio secundario de las aplicaciones web.

Bien, sirvámonos de un ejemplo específico. Supongamos que las aplicaciones web son similares a equipo.contoso.com, mi.contoso.com y portal.contoso.com. Antes que nada, puede que no sea recomendable utilizar solamente "contoso.com" como dominio de aplicación, porque hacerlo le exigirá la creación de una entrada DNS de carácter comodín para TODAS las contoso.com que apunta al extremo de las aplicaciones (profundizaremos en este tema en breve). Tampoco es recomendable que utilice “apps.contoso.com” porque es un dominio secundario que está utilizando para las aplicaciones web (que tienen todas su raíz en “contoso.com”). Si nos basamos en estas reglas, la mejor elección sería algo parecido a “contosoapps.com”. 

El valor Prefijo de aplicación puede ser lo que usted quiera. Se añade a la primera parte de la dirección URL de la aplicación, en la que nos adentraremos a continuación.

Antes he mencionado utilizar una entrada DNS de carácter comodín, y esto es lo que expondremos ahora. Cuando se instala una aplicación y se hospeda en SharePoint, esta tiene una dirección URL que se parece a: https://apps-87e90ada14c175.contosoapps.com/myapp/pages/default.aspx. Los elementos de la dirección URL son los siguientes:

  • “apps”. Este es el valor Prefijo de aplicación que he mencionado anteriormente que escribió en la Administración central.
  • “87e90ada14c175”. Este es un valor único que se basa en la colección de sitios y en la web en la que está instalada la aplicación
  • “contosoapps.com”. Este es el Dominio de aplicación que ha escrito en la Administración central.
  • “myapp”. Este es el nombre de la aplicación que se ha instalado. El resto de la dirección URL (pages/default.aspx) es el contenido de la SPWeb en la que está instalada la aplicación.

Si observa cómo está formada la dirección URL, probablemente comprenda por qué será aconsejable utilizar una entrada DNS de carácter comodín. Como la primera parte de la URL va a ser diferente para cada instancia de aplicación instalada (incluso si la misma aplicación está instalada en múltiples colecciones de sitios), no es factible actualizar continuamente el DNS de todas y cada una de las instancias. Una vez dicho esto, aplicado al DNS del escenario que se ha descrito aquí, será recomendable que utilice una entrada DNS de carácter comodín para *.contosoapps.com. La dirección IP a la que conduce es un tema que se discutirá más adelante.

La entrada SSL de carácter comodín está relacionada con la entrada DNS de carácter comodín. Para que quede bien claro: si utiliza aplicaciones, debería utilizar SSL. El modelo de aplicaciones supone la utilización de tokens de acceso, que describen quiénes son el usuario y la aplicación actuales. Igual que si estuviera utilizando tokens SAML para un usuario, es recomendable encriptar el canal por el que pasan estos tokens para prevenir ataques de reproducción que facilitarían el acceso al contenido a alguien que podría estar husmeando el tráfico de su red. El uso de SSL impide que tengan lugar estos escenarios, y ya que ha visto que las direcciones URL de estas aplicaciones van a ser diferentes para cada instancia instalada, esto también significa que, para poder realizar labores de administración, necesitará un certificado SSL de carácter comodín. De nuevo, en nuestro escenario obtendríamos un certificado SSL para *.contosoapps.com.

Hasta ahora hemos hablado sobre las aplicaciones de servicio necesarias, la configuración necesaria para el Dominio de aplicación y el Prefijo de aplicación, cómo se forman las direcciones URL y las entradas DNS y SSL que se necesitan. Ahora, para dejarlo todo atado, tenemos que hablar de cómo se enrutan las solicitudes de aplicación. En términos generales, para llevar a cabo el enrutamiento de solicitudes de aplicación se necesita una aplicación web de SharePoint individual. Veamos por qué. Supongamos de nuevo que tiene tres aplicaciones web definidas como se muestra a continuación; todas utilizan SSL, de modo que para cada una utilizamos direcciones IP únicas:

  • team.contoso.com – 192.168.1.10
  • my.contoso.com – 192.168.1.11
  • portal.contoso.com – 192.168.1.12

Tal como se ha descrito anteriormente, en la granja solo puede tener un Dominio de aplicación y no debería ser un dominio secundario. Esto plantea dos problemas reales con las aplicaciones anteriores:

  • Si instalamos aplicaciones en todas estas aplicaciones web, ¿cómo conseguimos enrutar la solicitud de aplicación correcta a la aplicación web correcta? Solo tenemos un Dominio de aplicación, pero tres aplicaciones web.
  • Si tratamos de enrutar una solicitud de aplicación a una de estas aplicaciones web existentes, el SSL se romperá. ¿Por qué? Porque, como estamos utilizando SSL en todas las aplicaciones web (ya que estamos utilizando Aplicaciones), todas tienen un certificado SSL similar a *.contoso.com. En cualquier caso, no podemos enrutar solicitudes de aplicación a ellas, porque no puede obtener un carácter comodín SSL que funcione con *.contoso.com y *.contosoapps.com, que es lo que utilizarán las aplicaciones.

La solución, entonces, es crear una cuarta aplicación web. Puede crearla sin ningún nombre de encabezado de host y asignarle una IP compartida: 192.168.1.13. Entonces, en DNS la entrada de carácter comodín de *.contosoapps.com apuntará a 192.168.1.13. Lo que termina sucediendo es que la aplicación web Aplicaciones "escucha" esa dirección IP y el módulo HTTP de SharePoint responsable del enrutamiento recoge la solicitud de la aplicación. Después utilizará la aplicación de servicio Administración de aplicaciones para determinar qué aplicación web hospeda realmente esa aplicación y volver a enrutar así la solicitud a ella. La solicitud se atiende entonces desde esa aplicación web, desde la colección de sitios y desde la SPWeb en la que está ubicada la aplicación en sí misma, de modo que todos los valores de configuración de seguridad y autenticación se les aplican correctamente.

Ahora, la configuración de nuestra granja tiene el siguiente aspecto:

  •  Configuración de aplicaciones
    • Dominio de aplicación: contosoapps.com
    • Prefijo de aplicación: apps
  • Aplicaciones web

    • team.contoso.com

      • Dirección IP: 192.168.1.10
      • Certificado SSL: *.contoso.com

    • my.contoso.com

      • Dirección IP: 192.168.1.11
      • Certificado SSL: *.contoso.com

    • portal.contoso.com

      • Dirección IP: 192.168.1.12
      • Certificado SSL: *.contoso.com

    • No hay encabezado host, pero puede utilizar algo similar a contosoapps, etc. En realidad, no tiene importancia, ya que no estamos enrutando basándonos en el encabezado host, sino en la dirección IP. NO OBSTANTE, si estuviese utilizando encabezados host y todas las aplicaciones web utilizasen la misma dirección IP, esta aplicación web de escucha no debería tener ningún valor de encabezado host. De lo contrario, IIS no recogerá solicitudes de aplicación de ninguna aplicación web.

      • Dirección IP: 192.168.1.13
      • Certificado SSL: *.contosoapps.com
  • DNS
    • team.contoso.com – 192.168.1.10
    • my.contoso.com – 192.168.1.11
    • portal.contoso.com – 192.168.1.12
    • *.contosoapps.com – 192.168.1.13

Ahora que se han cubierto todos los aspectos de configuración de la infraestructura de las aplicaciones, existen un par de consideraciones más que es necesario recordar al planificar el lanzamiento de nuevas aplicaciones de SharePoint 2013:

  • Las aplicaciones de SharePoint no funcionan con aplicaciones web que utilizan SAML. Si utiliza autenticación SAML, no podrá utilizar aplicaciones de SharePoint en esas aplicaciones web. Se espera encontrar solución a este problema en un Service Pack próximo o en algún otro tipo de revisión, pero, de momento, esto constituye una limitación para SharePoint 2013 RTM.
  • Las aplicaciones de SharePoint no son compatibles con zonas múltiples (p.ej. AAM), por lo que todas las solicitudes se atienden fuera de la zona predeterminada. Si utiliza AAM para dar compatibilidad a zonas múltiples, probablemente no podrá utilizar aplicaciones de SharePoint. Todas las aplicaciones se atienden fuera de la zona predeterminada, así que, en teoría, si la zona determinada que estableció estaba expuesta a todos los usuarios y utilizaba exactamente el mismo mecanismo de autenticación en todas las zonas (con algunas posibles limitaciones demasiado específicas como para abordarlas ahora), entonces es posible que funcionase. Pero, si utiliza zonas, suele ser porque a) no desea que todos los extremos estén expuestos a todo el mundo o b) SÍ desea utilizar métodos de autenticación diferentes. Reiteramos que esto podría cambiar en un futuro, pero actualmente SharePoint 2013 RTM tiene una disponibilidad limitada.

 

Otro apunte final importante: el proceso que se ha explicado da la impresión de ser un largo trabajo de configuración, y lo es. De todos modos, recuerde que si utiliza Office 365 el programa se ocupa de todo: la instalación y el uso de aplicaciones es pan comido. Es recomendable que lo tenga en cuenta al sopesar las opciones.

Conclusión: las aplicaciones de SharePoint son una parte principal de SharePoint 2013, pero requieren cierta planificación y diseño previos para asegurar una sólida infraestructura que les dé compatibilidad.

 

Esta entrada de blog es una traducción. Puede encontrar el artículo original en Planning the Infrastructure Required for the new App Model in SharePoint 2013