Ejemplo de diseño: Implementación corporativa (SharePoint Server 2010)
Se aplica a: SharePoint Foundation 2010, SharePoint Server 2010
Última modificación del tema: 2017-01-18
En este artículo se describe una implementación práctica de los componentes de la arquitectura lógica para lograr un diseño viable. Este artículo está pensado para que se use junto con los siguientes ejemplos de diseño:
Ejemplo de diseño: portal corporativo con autenticación clásica
Ejemplo de diseño: portal corporativo con autenticación basada en notificaciones
Para descargar cualquiera de estos modelos, vea Ejemplos de diseño de SharePoint Server 2010: portal corporativo con autenticación clásica o autenticación basada en notificaciones (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0xC0A).
En este artículo:
Acerca de los ejemplos de diseño
Objetivos de diseño generales
Granjas de servidores
Usuarios, zonas y autenticación
Servicios
Alternativas de publicación y creación
Sitios de administración
Grupos de aplicaciones
Aplicaciones web
Colecciones de sitios
Bases de datos de contenido
Zonas y direcciones URL
Directivas de zona
Los ejemplos de diseño muestran una implementación corporativa genérica de Microsoft SharePoint Server 2010. Los ejemplos de diseño aplican prácticamente todos los componentes de la arquitectura lógica y muestran cómo se incorporan éstos en el diseño global. Los dos ejemplos ilustran los mismos servicios y sitios, pero incorporan distintos métodos de autenticación, tal como se indica a continuación:
Autenticación clásica: este ejemplo de diseño representa una ruta de acceso para actualizar sitios de Microsoft Office SharePoint Server 2007 a Microsoft SharePoint Server 2010. En este ejemplo se incluye la autenticación clásica, en la que se usan los métodos de autenticación de Windows para tener acceso a sitios. Se usa una zona diferente para cada método de autenticación. Mientras se usa la autenticación de Windows para los sitios de SharePoint, un producto de puerta de enlace o firewall se puede configurar para usar la autenticación de formularios para recopilar las credenciales de Windows que se reenvían a SharePoint Server 2010. Las cuentas de empleados de asociados se agregan al directorio corporativo.
Autenticación de notificaciones: el ejemplo de diseño incorpora el nuevo modelo de autenticación de notificaciones. Varios proveedores de autenticación y tipos de autenticación se implementan en una sola zona. La autenticación de notificaciones es compatible con la autenticación basada en formularios, la autenticación basada en token SAML y la autenticación de Windows. En este ejemplo de diseño, se agregan compañías asociadas mediante la autenticación basada en token SAML para autenticarse directamente en los directorios asociados. Hay varias opciones de proveedores para las cuentas de empleados de asociados.
Use el ejemplo de diseño que mejor represente los requisitos de autenticación.
En este artículo se describen los objetivos de diseño de los ejemplos y se explica cómo se logran estos objetivos mediante el uso de los componentes de la arquitectura lógica que se muestran en los ejemplos.
Acerca de los ejemplos de diseño
Los ejemplos de diseño muestran una implementación corporativa de una empresa ficticia denominada Fabrikam, Inc. La implementación incluye dos conjuntos o granjas de servidores. Una granja de servidores hospeda el sitio web de asociados y la intranet de la compañía. La segunda granja de servidores hospeda el sitio web de la empresa (www.fabrikam.com). En el resto de esta sección se describen estos sitios de nivel superior.
Intranet
La intranet corporativa incluye los siguientes sitios:
Contenido de intranet publicado (por ejemplo, HRweb)
Sitios de grupo de colaboración
Mis sitios
Juntos, estos son los sitios de contenido y colaboración que van a usar los empleados de forma habitual. Individualmente, cada una de estas aplicaciones representa un tipo distinto de contenido. Cada tipo de contenido:
Enfatiza distintas funciones de SharePoint Server 2010.
Hospeda datos con distintas características de datos.
Está sujeto a un perfil de uso diferente.
Requiere una estrategia de administración de permisos diferente.
Por lo tanto, las opciones de diseño de cada una de estas aplicaciones están diseñadas para optimizar el rendimiento y la seguridad de cada aplicación.
El diseño de las aplicaciones de servicio junta estas tres aplicaciones para proporcionar:
Navegación en todas las aplicaciones
Búsqueda en toda la empresa
Metadatos empresariales y datos de perfiles compartidos
El siguiente diagrama muestra las tres aplicaciones que componen la intranet corporativa.
.gif "Sitios de intranet")
Las direcciones URL en esta ilustración proceden del ejemplo de diseño de autenticación clásica.
Aplicación web de asociados
La aplicación web de asociados hospeda sitios disponibles externamente para la colaboración segura con empresas asociadas y asociados particulares. Esta aplicación está diseñada para que los empleados creen fácilmente sitios de colaboración segura. Los asociados no tienen permiso de acceso a otros tipos de contenido hospedados en la granja de servidores. El diseño de zonas y aplicaciones de servicio se ocupa de este objetivo.
En el ejemplo de diseño, la aplicación web de asociados está hospedada en la misma granja de servidores que hospeda el contenido de la intranet.
Sitio Internet de la empresa
El sitio Internet de la empresa es la presencia en Internet de la misma. El contenido se pone a disposición de los clientes mediante la configuración del acceso anónimo con permisos de solo lectura. Entre los factores clave que impulsan las opciones de diseño para esta aplicación, se incluyen:
Aislamiento de contenido: los clientes no pueden tener acceso a ningún otro tipo de contenido que se hospeda en la granja de servidores.
Administración dirigida: se proporciona acceso autenticado para los empleados que administran el sitio web mediante tareas de administración y creación.
Creación y publicación de contenido seguro: una colección de sitios independientes se hospeda en la granja de servidores A en la aplicación web de asociados para la creación. Esto permite la colaboración segura y el desarrollo de contenido con empleados tanto internos como remotos, así como con asociados editoriales especializados en el desarrollo de sitios web o la creación de contenido. La publicación de contenido está configurada para publicar automáticamente el contenido desde la colección de sitios de creación en la primera granja de servidores a la colección de sitios de producción en la segunda granja de servidores. El siguiente diagrama ilustra el proceso de publicación.
.gif "Sitios publicados")
Objetivos de diseño generales
En el ejemplo de diseño se proporcionan implementaciones prácticas de las características de SharePoint Server 2010 dentro de varios tipos comunes de aplicaciones. En este artículo, se describen las implementaciones de diseño para cada una de las aplicaciones individuales. Entre los objetivos de diseño clave para el ejemplo de diseño, se incluyen:
Usar el número mínimo de granjas de servidores para hospedar los tipos más comunes de sitios web normalmente requeridos por una corporación, es decir, intranet, extranet y sitios Internet.
Crear un marco de trabajo para diseñar un entorno que puede crecer. Las decisiones de diseño para las aplicaciones individuales no impiden la adición de otras aplicaciones. Por ejemplo, una implementación inicial puede incluir sólo sitios de grupo de colaboración o sólo las tres aplicaciones que componen una intranet (sitios de grupo, Mis sitios y contenido publicado de intranet). Mediante el uso de un diseño de arquitectura lógica similar, se pueden agregar aplicaciones a la solución sin afectar al diseño de las aplicaciones iniciales. En otras palabras, el diseño no incorpora opciones de diseño que limitan el uso del entorno.
Proporcionar acceso para varios grupos de usuarios sin poner en peligro la seguridad del contenido dentro de los distintos tipos de sitios. Los usuarios de distintas zonas de red (internas y externas) con distintos proveedores de autenticación pueden participar en la colaboración. Además, los usuarios sólo pueden tener acceso al contenido al que están destinados. Al seguir un diseño de arquitectura lógica similar, se crea la oportunidad de proporcionar acceso a los usuarios en varias ubicaciones y con diferentes objetivos. Por ejemplo, el diseño inicial puede que esté destinado sólo para acceso de los empleados internos. Sin embargo, mediante el uso de un diseño similar, se crea la oportunidad de habilitar también el acceso a los empleados remotos, los empleados de asociados, las empresas asociadas y los clientes.
Garantizar que se puede usar el diseño en un entorno de extranet. Se toman decisiones de diseño deliberadas para garantizar que las granjas de servidores se pueden implementar de forma segura en una red perimetral.
En el resto de este artículo se describe cada uno de los componentes lógicos que aparecen en el ejemplo de diseño (de arriba a abajo) y se describen las opciones de diseño que se aplican en el ejemplo de diseño. El propósito de este enfoque es demostrar las distintas formas en que se pueden configurar los componentes de la arquitectura lógica en función de la aplicación.
Granjas de servidores
El ejemplo de diseño incorpora el uso de dos granjas de servidores. En esta sección se describen los requisitos de licencia que afectan al número de granjas de servidores necesarias en un entorno corporativo y se anotan las topologías de las granjas de servidores que se muestran en el ejemplo de diseño.
Requisitos de licencia
Para hospedar contenido de intranet y sitios Internet, se requiere un mínimo de dos servidores. Esto es necesario para satisfacer los requisitos de licencia.
Las siguientes dos licencias del servidor están disponibles en SharePoint Server 2010:
Microsoft SharePoint Server 2010, licencia del servidor: se trata de la licencia apropiada para el contenido de colaboración de intranet. Esta licencia requiere el uso de licencias de acceso de cliente (CAL). Si crea sitios para la colaboración de asociados, debe asegurarse de que adquiere el número necesario de licencias CAL para los empleados de asociados.
Microsoft SharePoint Server 2010 para sitios Internet: esta licencia está destinada únicamente para sitios web orientados a Internet. Esta licencia no requiere licencias CAL. Si crea sitios para la colaboración de asociados, no es necesario adquirir licencias CAL adicionales. Sin embargo, no podrá crear sitios que estén destinados exclusivamente al uso de los empleados.
Nota
No se puede combinar estas licencias en el mismo equipo servidor o en la misma granja de servidores.
Dadas las opciones de licencia, la elección de diseño más importante consiste en decidir qué granja de servidores hospedará la aplicación web de asociados. En el ejemplo de diseño, la primera granja de servidores hospeda el contenido de intranet y la segunda hospeda el sitio Internet de la empresa. De acuerdo con los términos de la licencia, cualquier granja puede hospedar la aplicación web.
Con la opción de las dos granjas de servidores, las instrucciones generales de diseño para determinar qué granja debe hospedar una aplicación web de asociados incluyen lo siguiente:
Naturaleza de colaboración: si el objetivo principal de un sitio de extranet de asociados es comunicar de forma segura información a varios asociados, una granja de servidores de Internet es la opción más económica. Por otro lado, si el objetivo principal es trabajar en colaboración con un pequeño número de empleados de asociados, puede que una granja de servidores de intranet sea una mejor opción. Elija la opción que le permita optimizar la granja de servidores para su rol deseado.
Número de empleados de asociados: si colabora con muchos empleados de asociados y la reducción de costos es importante, puede hospedar contenido anónimo y de colaboración de forma segura en una granja de servidores orientada a Internet mediante la licencia de sitios Internet.
En el ejemplo de diseño, la aplicación web de asociados está destinada a una colaboración intensiva con empresas asociadas, incluido el desarrollo y almacenamiento provisional del sitio Internet de la empresa. La colocación de la aplicación web de asociados en la primera granja de servidores permite a la organización optimizar cada una de las dos granjas de servidores para su uso previsto (colaboración en lugar de contenido de solo lectura). Sin embargo, cualquier granja de servidores podría hospedar la aplicación web de asociados.
El ejemplo de diseño incluye Microsoft Office Web Apps. Office Web Apps requiere una licencia de cliente de Microsoft Office 2010. En otras palabras, si pone Office Web Apps a disposición de los asociados, debe adquirir también licencias de cliente de Office 2010 para ellos.
Topología de las granjas de servidores
Cada granja de servidores en el ejemplo de diseño consta de cinco servidores con la siguiente topología:
Dos servidores front-end web
Un servidor de aplicaciones
Dos servidores de bases de datos, en clúster o reflejados
En el ejemplo de diseño se ilustra la arquitectura lógica de SharePoint Server 2010, al mostrar que:
Todos los sitios se reflejan en los servidores front-end web.
El sitio de Administración Central está instalado en un servidor de aplicaciones para protegerlo del acceso de usuario directo.
En realidad, el número de equipos servidor y la topología de la granja de servidores no son importantes para la arquitectura lógica, excepto para aumentar el rendimiento y la capacidad según sea necesario. La arquitectura lógica se puede diseñar independientemente de la topología de la granja de servidores. El proceso de planeación de rendimiento y capacidad le ayudará a cambiar el tamaño de la granja de servidores para cumplir los objetivos de rendimiento y capacidad. Si desea obtener más información, vea Administración del rendimiento y de la capacidad (SharePoint Server 2010).
Escalado más allá de dos granjas de servidores
Es posible que la empresa requiera mucho más que las dos granjas de servidores representadas. Entre los sitios candidatos para una granja de servidores dedicada, se incluyen los siguientes:
Mis sitios: muchas organizaciones con un gran número de empleados o alumnos optan por hospedar Mis sitios en una granja de servidores dedicada.
Creación y almacenamiento provisional de sitios: si el contenido publicado es complejo o extenso, la creación y el almacenamiento provisional se podrían optimizar mejor hospedando estos sitios en una granja de servidores dedicada de un solo servidor con la licencia de Microsoft SharePoint Server 2010 para sitios Internet. Por ejemplo, la publicación de contenido que incluye metadatos con etiquetas aumenta la complejidad del ejemplo de diseño de los servicios entre la granja de servidores de creación y la granja publicada, lo que incluye compartir el servicio en granjas de servidores y tomar decisiones sobre cómo se podría compartir el servicio en otros tipos de aplicaciones web en una granja de uso múltiple.
Sitios de asociados: los requisitos de seguridad y aislamiento podrían garantizar una granja de servidores dedicada para la colaboración de asociados. Esto crea aislamiento físico entre el contenido exclusivamente interno y el contenido que se desarrolla en colaboración con asociados externos.
Usuarios, zonas y autenticación
Al crear una aplicación web en SharePoint Server 2010, deberá elegir entre la autenticación basada en notificaciones o la autenticación de modo clásico. El modo de autenticación determina la forma en que se usan las cuentas internamente mediante SharePoint Server 2010. En la siguiente tabla se resumen los dos enfoques.
Tipo de autenticación |
Descripción |
Recomendaciones |
Autenticación de modo clásico |
SharePoint Server 2010 considera las cuentas de usuario como cuentas tradicionales de Windows Active Directory. Se admiten los siguientes protocolos de autenticación: Kerberos, NTLM, básica, implícita y anónima. No se admite la autenticación basada en formularios. Sólo se puede configurar un método de autenticación en una zona. |
El modo clásico se recomienda para actualizar entornos de Microsoft Office SharePoint Server 2007, en los que la autenticación basada en formularios no es un requisito. No es necesario ejecutar la migración de usuario si se va a actualizar y seleccionar el modo clásico de autenticación. |
Autenticación basada en notificaciones |
SharePoint Server 2010 considera las cuentas de usuario como identidades de notificaciones. Las cuentas de Windows se convierten automáticamente en identidades de notificaciones. Además, este modo admite la autenticación basada en formularios y la autenticación con un proveedor de identidad de confianza. Se pueden configurar varios tipos de autenticación en una sola zona. |
La autenticación basada en notificaciones se recomienda para las nuevas implementaciones de SharePoint Server 2010. Es necesaria para actualizar soluciones de Office SharePoint Server 2007 que requieren autenticación basada en formularios. |
Los dos ejemplos de diseño que se describen en este artículo representan estas dos opciones. En concreto, las secciones siguientes describen cómo se incorpora la autenticación en los dos ejemplos de diseño.
Ejemplo de diseño de autenticación de modo clásico
El ejemplo de diseño que usa la autenticación de modo clásico incorpora el método de autenticación tradicional de una zona por tipo que se incorporó en la versión anterior. Por esta razón, en este ejemplo se proporciona una ruta de acceso para actualizar de Office SharePoint Server 2007 a SharePoint Server 2010.
La única advertencia es que la autenticación basada en formularios no se admite en el modo clásico. Al usar la autenticación de modo clásico, todas las cuentas autenticadas se deben encontrar dentro de los Servicios de dominio de Active Directory (AD DS). La recomendación para los usuarios que tienen acceso a los sitios de forma remota es que usen la autenticación basada en formularios en el producto de puerta de enlace o firewall para recopilar las credenciales de Windows que se reenvían a la granja de servidores de SharePoint.
El ejemplo de modo clásico muestra cuatro clases diferentes de usuarios, cada una asignada a una zona diferente. En cada aplicación web, puede crear hasta cinco zonas con uno de los nombres de zona disponibles: Predeterminada, Intranet, Internet, Personalizada o Extranet.
En la siguiente tabla se muestran las zonas, los usuarios y el tipo de autenticación según se explica en el ejemplo de diseño de modo clásico.
.gif "Tabla que muestra zonas, usuarios y autenticación.")
La cuenta de rastreo de búsqueda requiere acceso a al menos una zona mediante la autenticación NTLM. Si ninguna de las zonas para los usuarios está configurada para usar NTLM, configure la zona personalizada para que use la autenticación NTLM.
Ejemplo de diseño de la autenticación basada en notificaciones
La autenticación basada en notificaciones se recomienda para todas las implementaciones nuevas de SharePoint Server 2010 y es necesaria para actualizar soluciones de Office SharePoint Server 2007 que requieren autenticación basada en formularios. Además de proporcionar los métodos de autenticación estándar de Windows, la autenticación basada en notificaciones permite autenticarse con otros directorios, como Windows Live ID, Servicios de federación de Active Directory 2.0 o un proveedor de identidad de terceros que admita tokens SAML y el protocolo WS-Federation.
En el ejemplo de diseño de la autenticación basada en notificaciones, se usa la autenticación basada en notificaciones en la granja de servidores de colaboración. La autenticación basada en notificaciones permite el uso de varios tipos de autenticación en la misma zona. En el ejemplo de diseño, se usa la zona predeterminada para todos los tipos de autenticación. La siguiente tabla muestra las zonas, los usuarios y el tipo de autenticación que se indican en el ejemplo de la granja de colaboración.
.gif "Tabla que muestra zonas, usuarios y autenticación.")
En el ejemplo de diseño, el sitio de contenido publicado de intranet, los sitios de grupo y Mis sitios sólo son accesibles para los empleados, ya sean internos o externos a la red. En el ejemplo de diseño se implementa una sola dirección URL (mediante SSL) que se puede usar tanto interna como externamente. Se usan cuentas de Active Directory. Si es necesario, se puede usar LDAP con la autenticación basada en formularios o SAML, lo que requiere una configuración adicional.
En el ejemplo de diseño, la aplicación web de asociados representa un sitio de extranet que es accesible para los empleados de asociados y las compañías asociadas. El uso de la autenticación basada en notificaciones en este escenario requiere que se configure la confianza con uno o más servicios de token de seguridad (STS). Esto puede proporcionarse mediante uno de los siguientes métodos:
La granja de servidores de SharePoint se puede configurar para que confíe en un STS externo, como el STS asociado con Windows Live (para autenticar asociados individuales) o el STS que se encuentra en una compañía asociada (para autenticarse directamente con el directorio de asociados).
Se puede configurar el STS dentro del entorno corporativo para que confíe en un STS externo. Los administradores deben establecer explícitamente esta relación en las dos organizaciones. En este escenario, la granja de servidores de SharePoint está configurada para confiar únicamente en el STS que se encuentra en su propio entorno corporativo. Este STS interno comprueba el token que recibe del STS externo y, a continuación, emite un token que permite al usuario asociado tener acceso a la granja de SharePoint. Éste es el método recomendado.
Una alternativa a la implementación de un entorno basado en notificaciones para autenticar a los asociados es usar la autenticación basada en formularios y administrar estas cuentas con un almacén independiente, por ejemplo, una base de datos.
Para obtener más información sobre la implementación de un entorno de autenticación basada en notificaciones, consulte las siguientes notas del producto: Identidad basada en notificaciones para Windows: introducción a Servicios de federación de Active Directory 2.0, Windows CardSpace 2.0 y Windows Identity Foundation (https://go.microsoft.com/fwlink/?linkid=196776&clcid=0xC0A).
En el ejemplo de diseño de autenticación basada en notificaciones, la granja de servidores publicada está configurada para usar la autenticación de modo clásico. Una alternativa es usar la autenticación basada en notificaciones para la granja publicada también e implementar una zona independiente para los usuarios anónimos. El elemento importante del diseño es usar una zona independiente para que los usuarios anónimos creen aislamiento entre el entorno de solo lectura y el entorno de lectura y escritura, independientemente del tipo de autenticación que se implemente. En la siguiente tabla se muestran las zonas, los usuarios y el tipo de autenticación que se ilustran para la granja publicada.
.gif "Tabla que muestra zonas, usuarios y autenticación.")
Una vez más, la cuenta de rastreo de búsqueda requiere acceso a al menos una zona mediante la autenticación NTLM. La autenticación NTLM se puede agregar a una zona de autenticación basada en notificaciones, si es necesario. En el modo clásico, si ninguna de las zonas para los usuarios está configurada para usar NTLM, configure la zona personalizada para que use la autenticación NTLM.
Zonas
Al diseñar zonas, debe tomar varias decisiones que son esenciales para que la implementación sea correcta. Se trata de decisiones relativas al diseño y la configuración de las zonas siguientes:
Zona predeterminada
Zonas para acceso externo
En las secciones siguientes se describen las decisiones que se incorporan en el ejemplo de diseño.
Requisitos de configuración de la zona predeterminada
La zona que implica la mayor consideración es la zona predeterminada. SharePoint Server 2010 coloca los siguientes requisitos de configuración de la zona predeterminada:
Cuando una solicitud de usuario no se puede asociar a una zona, se aplican la autenticación y las directivas de la zona predeterminada. Por lo tanto, la zona predeterminada debe ser la zona más segura.
El correo electrónico administrativo se envía con vínculos de la zona predeterminada. Éstos incluyen correo electrónico a propietarios de sitios que se aproximan a los límites de cuota. Por tanto, los usuarios que reciben este tipo de alertas y mensajes de correo electrónico deben poder tener acceso a vínculos a través de la zona predeterminada. Esto es especialmente importante para los propietarios de sitios.
Las colecciones de sitios con nombre de host sólo están disponibles por medio de la zona predeterminada. Todos los usuarios que vayan a tener acceso a colecciones de sitios con nombre de host deben tener acceso por medio de la zona predeterminada.
Configuración de zonas para un entorno de extranet
En un entorno de extranet, el diseño de zonas es imprescindible por las siguientes dos razones:
Las solicitudes del usuario se pueden iniciar desde varias redes distintas. En el ejemplo de diseño, los usuarios inician solicitudes desde la red interna, Internet y las empresas asociadas.
Los usuarios consumen contenido en varias aplicaciones web. En el ejemplo de diseño, la intranet consta de tres aplicaciones web diferentes. Además, los empleados internos y remotos potencialmente pueden contribuir al contenido y administrarlo en todas las aplicaciones web: intranet, sitio web de asociados y el sitio Internet de la empresa.
En un entorno de extranet, asegúrese de que se observan los siguientes principios de diseño:
Configure las zonas de varias aplicaciones web para que se reflejen mutuamente. La configuración de la autenticación y los usuarios a los que está dirigida deben coincidir. No obstante, las directivas asociadas con zonas pueden diferir entre distintas aplicaciones web. Por ejemplo, asegúrese de que la zona de intranet se usa para los mismos empleados en todas las aplicaciones web. Es decir, no configure la zona de intranet para empleados internos en una aplicación web y para empleados remotos en otra.
Configure las asignaciones de acceso alternativas precisa y correctamente para cada zona y cada recurso. Las asignaciones de acceso alternativas se crean automáticamente al crear la zona. Sin embargo, se puede configurar SharePoint Server 2010 para que rastree contenido en recursos externos, como un recurso compartido de archivos. Los vínculos a estos recursos externos se deben crear manualmente para cada zona mediante asignaciones de acceso alternativas.
Si las zonas en las aplicaciones web no se reflejen entre sí y los vínculos a recursos externos no son adecuados, existen los siguientes riesgos:
Los nombres de servidor, los nombres del Sistema de nombres de dominio (DNS) y las direcciones IP se pueden exponer fuera de la red interna.
Es posible que los usuarios no puedan tener acceso a los sitios web y otros recursos.
Servicios
La arquitectura de servicios indicada muestra la opción más compleja para implementar servicios a través de los tres distintos tipos de sitios: intranet, sitio web de asociados y el sitio Internet de la empresa. Se implementan servicios dedicados y con particiones para el sitio web de asociados. Una instancia independiente de la aplicación de servicio de metadatos administrados se implementa para uso exclusivo de la colección de sitios de creación y el sitio Internet publicado.
Una alternativa mucho más sencilla consiste en implementar un conjunto de aplicaciones de servicio y compartir cada servicio, según sea necesario, en todos los sitios. Esta arquitectura se basa en el recorte de seguridad para mostrar únicamente el contenido al que los usuarios tienen acceso. El siguiente diagrama ilustra este enfoque más sencillo.
.gif "Arquitectura de servicios")
La decisión principal de diseño para implementar aplicaciones de servicio consiste en qué tanto propagar la taxonomía de la organización. La arquitectura de servicios se puede simplificar si se comparten los metadatos administrados, el perfil de usuario y la búsqueda en todas las aplicaciones web y si se basa en el recorte de seguridad para administrar el acceso al contenido. En la arquitectura simplificada que se describe en este artículo, una instancia del servicio de metadatos administrados se comparte en todos los sitios. Sin embargo, con esta configuración, todos los usuarios tienen acceso a la taxonomía corporativa. Los arquitectos de la solución deben decidir si se van a implementar varias instancias del servicio de metadatos administrados. También deben decidir qué tanto compartir los datos de perfil de usuario.
Sitio web de asociados
En el caso del sitio web de asociados (grupo personalizado en la Granja de servidores 1), los servicios mínimos que se indican en el ejemplo de diseño son la búsqueda y los metadatos administrados. Si agrega Office Web Apps al grupo de servicios usados por el sitio web de asociados, asegúrese de que tiene las licencias adecuadas para todos los usuarios del sitio, incluidos los asociados. La aplicación de servicio de perfiles de usuario no se incluye en el ejemplo de diseño para impedir que los usuarios busquen datos de otras personas de la organización.
En la arquitectura simplificada, los asociados tienen acceso a toda la taxonomía corporativa y pueden buscar datos de otros usuarios de la organización. Sin embargo, la búsqueda limita los resultados a sitios y contenido para los que tienen acceso los asociados.
Si los sitios de asociados requieren aislamiento de contenido entre proyectos, la implementación de aplicaciones de servicio dedicadas y con particiones es una buena opción, tal como se indica en el ejemplo de diseño. Esto aumenta la complejidad de la arquitectura de servicios, pero garantiza que los asociados no tengan acceso a los metadatos vinculados al contenido de intranet o incluso a otros proyectos en el sitio web de asociados.
Sitio Internet de la empresa
En la arquitectura simplificada de diseño, la aplicación de servicio corporativa de metadatos administrados también se comparte con el sitio Internet publicado. En el ejemplo de diseño, una instancia dedicada de la aplicación de servicio de metadatos administrados se implementa en la granja de servidores de colaboración para uso exclusivo de la colección de sitios de creación y la granja publicada.
Si la granja de servidores publicada es anónima y de solo lectura, no hay ningún riesgo de exponer los metadatos administrados que no están asociados con el contenido publicado. Los usuarios anónimos sólo tienen acceso al contenido que se publica y no pueden enviar clasificaciones ni crear otros tipos de metadatos.
Compartir la aplicación de servicio de metadatos administrados en toda la organización (tal como se muestra en la arquitectura simplificada de este artículo) permite a los autores usar la taxonomía corporativa. Por el contrario, la implementación de una instancia dedicada del servicio para la creación y publicación (tal como se muestra en el ejemplo de diseño) garantiza el aislamiento de los metadatos administrados.
Una instancia dedicada de la aplicación de servicio de búsqueda se implementa en la granja de servidores que hospeda el sitio Internet de la empresa. Se trata de la configuración recomendada para un sitio Internet publicado.
Alternativas de publicación y creación
En el caso del sitio Internet de la empresa, el ejemplo de diseño muestra un proceso de publicación que incluye el uso de la característica de distribución de contenido para mover contenido desde una colección de sitios de creación hasta la granja de servidores de publicación. Una alternativa más sencilla a este enfoque es crear directamente en la granja de servidores de publicación. Esto se conoce normalmente como creación en producción.
La creación en el entorno de producción simplifica considerablemente la solución mediante la consolidación de servicios en una granja de servidores y la eliminación de la necesidad de distribución de contenido. En el ejemplo de diseño se incluyen las zonas adicionales que pueden usar los autores para trabajar de forma segura sin afectar a los usuarios anónimos. Asegúrese de bloquear el acceso anónimo entrante en el puerto asociado con las zonas utilizadas por los autores. Si el sitio tiene menos de 500 escrituras por hora de actividad de creación, no es probable que el rendimiento del sitio publicado se vea afectado cuando se cree en el entorno de producción.
SharePoint Server 2010 incluye características de publicación que se pueden usar en este escenario para garantizar que el contenido no se exponga a usuarios anónimos hasta que esté listo. Para obtener más información, vea los artículos siguientes:
Programar las fechas de inicio y de finalización de una página publicada (https://go.microsoft.com/fwlink/?linkid=196777&clcid=0xC0A)
Aprobar o rechazar un envío pendiente (https://go.microsoft.com/fwlink/?linkid=196778&clcid=0xC0A)
Establecer permisos para la publicación (https://go.microsoft.com/fwlink/?linkid=196779&clcid=0xC0A)
Sitios de administración
En el ejemplo de diseño, el sitio de Administración central de cada granja de servidores está hospedado en un servidor de aplicaciones. Esto protege el sitio del contacto directo del usuario. Si un cuello de botella de rendimiento o un riesgo en la seguridad afectan a la disponibilidad de los servidores front-end web, el sitio de Administración central sigue estando disponible.
Las direcciones URL de carga equilibrada de los sitios de administración no se mencionan en el ejemplo de diseño o en este artículo. Entre las recomendaciones destacan las siguientes:
Si se usan números de puerto en las direcciones URL administrativas, use puertos no estándar. De forma predeterminada, los números de puerto se incluyen en las direcciones URL. Aunque los números de puerto no se usan normalmente en las direcciones URL orientadas al cliente, el uso de números de puerto en los sitios de administración puede aumentar la seguridad al limitar el acceso a estos sitios a los puertos no estándar.
Cree entradas DNS independientes para los sitios de administración.
Además de estas recomendaciones, opcionalmente puede equilibrar la carga del sitio de Administración central entre varios servidores de aplicaciones para conseguir redundancia.
Grupos de aplicaciones
Los grupos de aplicaciones independientes de Internet Information Services (IIS) se suelen implementar para lograr el aislamiento de procesos entre el contenido. Los grupos de aplicaciones proporcionan una forma para que varios sitios se ejecuten en el mismo equipo servidor, pero sigan teniendo sus propios procesos de trabajo e identidad. Esto soluciona la vulnerabilidad de seguridad de un sitio que proporciona una oportunidad para que un atacante inyecte código en el servidor para atacar otros sitios.
En la práctica, considere la opción de usar un grupo de aplicaciones dedicado por cada uno de los escenarios siguientes:
Para separar el contenido autenticado del contenido anónimo.
Para aislar las aplicaciones que almacenan contraseñas e interactúan con aplicaciones empresariales externas (aunque, en su lugar, se puede usar el Servicio de almacenamiento seguro para este fin).
Para aislar las aplicaciones en las que los usuarios tienen mucha libertad para crear y administrar sitios, así como para colaborar en el contenido.
En el ejemplo de diseño se usan grupos de aplicaciones de la siguiente manera:
Cada sitio de administración se hospeda en un grupo de aplicaciones dedicado. Éste es un requisito de Productos de SharePoint 2010.
El contenido de intranet se divide en dos grupos de aplicaciones diferentes. El contenido de colaboración (Mis sitios y sitios de grupo) se hospeda en un grupo de aplicaciones. El contenido publicado de intranet se hospeda en otro grupo de aplicaciones. Esta configuración proporciona aislamiento de procesos para el contenido publicado de intranet en el que es más probable que se usen las conexiones de datos profesionales.
La aplicación web de asociados se hospeda en un grupo de aplicaciones dedicado.
El sitio Internet de la empresa se hospeda en un grupo de aplicaciones dedicado en la segunda granja de servidores. Si la granja también fuera a hospedar contenido de colaboración de asociados, estos dos tipos de contenido (Internet y asociado) se hospedarían en dos grupos de aplicaciones diferentes.
Aplicaciones web
Una aplicación web es un sitio web de IIS creado y utilizado por Productos de SharePoint 2010. Cada aplicación web se representa por medio de un sitio web diferente en IIS.
Por regla general, debe usar aplicaciones web dedicadas para:
Separar el contenido anónimo del contenido autenticado En el ejemplo de diseño, el sitio Internet de la compañía se hospeda en un grupo de aplicaciones y aplicación web dedicada.
Aislar a los usuarios. En el ejemplo de diseño, el sitio web de asociados se hospeda en un grupo de aplicaciones y aplicación web dedicada para garantizar que los asociados no tengan acceso al contenido de intranet.
Aplicar permisos. Una aplicación web dedicada proporciona la oportunidad para aplicar permisos mediante directivas al usar la página Directiva de aplicación web en la Administración central. Por ejemplo, se puede crear una directiva en el sitio Internet de la compañía para denegar explícitamente acceso de escritura a uno o varios grupos de usuarios. Las directivas de una aplicación web se aplican independientemente de los permisos configurados en sitios o documentos individuales de la aplicación web.
Optimizar el rendimiento. Las aplicaciones consiguen un mejor rendimiento si se colocan en aplicaciones web con otras aplicaciones de características similares. Por ejemplo, las características de datos de Mis sitios incluyen una gran cantidad de sitios cuyo tamaño es pequeño. Por el contrario, los sitios de grupo contienen normalmente una cantidad más pequeña de sitios de tamaño muy grande. Si estos dos tipos de sitios se colocan en aplicaciones web independientes, las bases de datos resultantes se componen de datos con características similares, lo cual optimiza el rendimiento de la base de datos. En el ejemplo de diseño, Mis sitios y los sitios de grupo no tienen requisitos de aislamiento de datos únicos: comparten el mismo grupo de aplicaciones. No obstante, Mis sitios y los sitios de grupo se colocan en aplicaciones web independientes para optimizar el rendimiento.
Optimizar la administración. La creación de aplicaciones web independientes da como resultado sitios y bases de datos independientes, por lo que puede implementar distintos límites al sitio (papelera de reciclaje, expiración y tamaño) y negociar distintos contratos de nivel de servicio. Por ejemplo, puede permitir más tiempo para restaurar el contenido de Mi sitio si éste no es el tipo de contenido más importante de la organización. Esto permite restaurar el contenido más importante antes de restaurar el contenido de Mi sitio. En el ejemplo de diseño, los sitios de Mi sitio se colocan en una aplicación web independiente para que los administradores puedan administrar el crecimiento de forma más dinámica en comparación con otras aplicaciones.
Colecciones de sitios
Las colecciones de sitios actúan de puente entre la arquitectura lógica y la arquitectura de información. Los objetivos de diseño para las colecciones de sitios en el ejemplo de diseño son para satisfacer los requisitos del diseño de la dirección URL y para crear divisiones lógicas de contenido.
Para satisfacer los requisitos del diseño de la dirección URL, cada aplicación web incluye una colección de sitios de nivel raíz. Las rutas de acceso administradas se usan para incorporar un segundo nivel de colecciones de sitios de nivel superior. Para obtener más información sobre los requisitos de la dirección URL y el uso de rutas de acceso administradas, vea "Zonas y direcciones URL" más adelante en este artículo. Más allá del segundo nivel de colecciones de sitios, cada sitio es un subsitio.
El siguiente diagrama ilustra la jerarquía de sitios de los sitios de grupo.
.gif "Sitios de grupo")
Dados los requisitos para una colección de sitios de nivel raíz, las decisiones de diseño giran en torno al segundo nivel de colecciones de sitios. En el ejemplo de diseño se incorporan opciones en función de la naturaleza de la aplicación.
Contenido de intranet publicado
La hipótesis para la aplicación web del contenido publicado de intranet es que varias divisiones dentro de la empresa van a hospedar contenido publicado. En el ejemplo de diseño, el contenido de cada división se hospeda en una colección de sitios independiente. Esto proporciona las siguientes ventajas:
Cada división puede administrar los permisos de su contenido por separado.
Se puede almacenar el contenido de cada división en una base de datos dedicada.
Entre las desventajas de usar varias colecciones de sitios, se incluyen las siguientes:
En las colecciones de sitios no se pueden compartir páginas maestras, diseños de página, plantillas, elementos web ni navegación.
Se requiere más esfuerzo para coordinar personalizaciones y navegación en las colecciones de sitios.
En función de la arquitectura de información y el diseño de la aplicación de intranet, el contenido publicado puede aparecer al usuario como una aplicación de conexión directa. Como alternativa, cada colección de sitios puede aparecer como un sitio web independiente.
Mis sitios
Mis sitios tienen diferentes características y las recomendaciones para implementar sitios de Mi sitio son sencillas. En el ejemplo de diseño, la aplicación de Mi sitio incorpora un sitio de nivel superior con la dirección URL de http://my. La primera colección de sitios de nivel superior que se crea usa la plantilla de host de Mi sitio. Se incorpora una ruta de acceso administrada (mediante la inclusión de caracteres comodín), lo que permite un número indefinido de sitios creados por el usuario. Todos los sitios por debajo de la ruta de acceso administrada son colecciones de sitios independientes que heredan la plantilla de host de Mi sitio. El nombre de usuario se agrega a la dirección URL con el formato http://my personal/nombre de usuario. La siguiente ilustración muestra Mis sitios.
.gif "Mis sitios")
Sitios de grupo
Puede usar cualquiera de los dos métodos siguientes para diseñar colecciones de sitios dentro de una aplicación de sitio de grupo:
Permitir que los grupos creen colecciones de sitios a través de la creación de sitios sin intervención del administrador. La ventaja de este método es que los grupos pueden crear fácilmente un sitio, según sea necesario, sin intervención del administrador. Sin embargo, este método presenta varias desventajas, entre las que se incluyen:
Se pierde la oportunidad de implementar una taxonomía detallada.
La aplicación se puede volver difícil de administrar.
Los sitios se abandonan fácilmente.
No se puede compartir plantillas y navegación entre los proyectos o grupos que, en caso contrario, podrían compartir una colección de sitios.
Crear un número finito de colecciones de sitios para la organización según el funcionamiento de la misma. En este método, un administrador de SharePoint crea las colecciones de sitios. Una vez creada la colección de sitios, los grupos pueden crear sitios en la colección de sitios, según sus necesidades. Este método proporciona la oportunidad de implementar una taxonomía detallada que proporcione estructura a la forma en que los sitios de grupo se administran y crecen. También hay más oportunidades para compartir plantillas y navegación entre los proyectos y grupos que comparten una colección de sitios.
En el ejemplo de diseño se incorpora el segundo método, que da como resultado una jerarquía de la colección de sitios similar para los sitios de grupo como para el contenido publicado de intranet. El desafío para los arquitectos de la información es crear un segundo nivel de las colecciones de sitios que tenga sentido para la organización. En la siguiente tabla se muestran sugerencias para distintos tipos de organizaciones.
| Tipo de organización | Taxonomías de colección de sitios sugeridas |
|---|---|
Desarrollo de productos |
|
Investigación |
|
Centro de enseñanza superior |
|
Oficina legislativa estatal |
|
Bufete de abogados corporativo |
|
Industria |
|
Aplicación web de asociados
El sitio web de asociados está pensado para usarse en la colaboración con asociados externos en proyectos que tienen ámbitos finitos o duraciones limitadas. Por diseño, los sitios dentro de la aplicación web de asociados no están diseñados para estar relacionados. Entre los requisitos para la aplicación web de asociados se incluye garantizar que:
Los propietarios del proyecto pueden crear fácilmente sitios para la colaboración de asociados.
Los asociados y otros colaboradores sólo tienen acceso al proyecto en el que trabajan.
Los propietarios del sitio administran los permisos.
Los resultados de la búsqueda desde dentro de un proyecto no exponen contenido de otros proyectos.
Los administradores pueden identificar fácilmente los sitios que ya no se usan y eliminarlos.
Para satisfacer estos requisitos, en el ejemplo de diseño se incorpora una colección de sitios para cada proyecto. De este modo, se producen las siguientes ventajas:
Las colecciones de sitios individuales proporcionan el nivel de aislamiento adecuado entre proyectos.
Se puede implementar la creación de sitios sin intervención del administrador.
Debido a que la aplicación web de asociados también hospeda las colecciones de sitios para desarrollar contenido del sitio Internet de la empresa, se crean colecciones de sitios independientes para la creación y almacenamiento provisional.
Sitio Internet de la empresa
El sitio Internet de la empresa incorpora una colección de sitios de nivel raíz. Todos los sitios por debajo de esta colección de sitios son subsitios. Esta estructura simplifica las direcciones URL de las páginas dentro del sitio. El siguiente diagrama ilustra la arquitectura del sitio Internet de la empresa.
.gif "Sitio de Internet de la compañía")
Bases de datos de contenido
Puede usar los dos métodos siguientes para incorporar bases de datos de contenido en el diseño (en el ejemplo de diseño se incorporan ambos métodos):
Establecer los tamaños de destino para las bases de datos de contenido con umbrales de advertencia de tamaño adecuados. Crear una nueva base de datos cuando se alcancen los umbrales de advertencia de tamaño. Con este método, las colecciones de sitios se agregan automáticamente a las bases de datos disponibles, en función de los tamaños de destino. Es el método más usado.
Asociar colecciones de sitios a bases de datos de contenido específicas. Este método permite colocar una o más colecciones de sitios en una base de datos dedicada que se puede administrar de forma independiente con respecto a las demás.
Si opta por asociar colecciones de sitios a bases de datos de contenido específicas, puede usar los métodos siguientes para hacerlo:
Usar Windows PowerShell para crear una colección de sitios en una base de datos específica.
Dedicar una base de datos a una sola colección de sitios mediante la aplicación de la siguiente configuración de capacidad de la base de datos:
Número de sitios antes de que se genere un evento de advertencia = 1
Número máximo de sitios que se puede crear en esta base de datos = 1
Para agregar un grupo de colecciones de sitios a una base de datos dedicada, realice los siguientes pasos:
Dentro de la aplicación web, cree la base de datos y establezca el estado de la base de datos en Listo.
Establezca el estado de todas las demás bases de datos en Sin conexión. Mientras las bases de datos de contenido están sin conexión, no se pueden crear nuevas colecciones de sitios. Sin embargo, las colecciones de sitios existentes de las bases de datos sin conexión siguen estando accesibles para operaciones de lectura y escritura.
Cree las colecciones de sitios. Se agregan a la base de datos automáticamente.
Vuelva a establecer el estado de todas las demás bases de datos en Listo.
Contenido de intranet publicado
En el caso del contenido publicado de intranet, el ejemplo de diseño incorpora una base de datos para facilitar la administración. Agregue bases de datos en función de los objetivos del tamaño de destino, si es necesario.
Mis sitios
Para Mis sitios, en el ejemplo de diseño se logra que la escala sea eficaz mediante la administración de bases de datos en el tamaño de destino máximo. Para conseguir este objetivo, se configuran las siguientes opciones:
Limitar el almacenamiento del sitio a un máximo de: esta opción, que se configura en la página Plantillas de cuota en la Administración central, limita el tamaño de un sitio personal.
Papelera de reciclaje de la segunda etapa: esta opción, que se configura en la página Configuración general de la aplicación web, determina la cantidad de espacio adicional que se asigna a la papelera de reciclaje de la segunda etapa.
Número máximo de sitios que se puede crear en esta base de datos: esta opción se configura al crear una base de datos. Calcule el tamaño total permitido de los sitios mediante los números especificados para los dos valores anteriores. A continuación, según el objetivo de tamaño para cada base de datos, determine cuántos sitios se ajustarán a la base de datos.
En el ejemplo de diseño se proporciona la siguiente configuración de tamaño en función del tamaño de una base de datos de destino de 200 gigabytes (GB) y un tamaño de Mi sitio de destino de 1 GB:
Límites de tamaño por cada sitio = 1 GB
Tamaño de destino de la base de datos = 175 GB
Reservado para la papelera de reciclaje de la segunda etapa = 15%
Número máximo de sitios = 180
Advertencia de nivel de sitio = 150
Cuando se alcance la advertencia de nivel de sitio, cree una nueva base de datos. Después de crear la nueva base de datos, se agregarán nuevos sitios de Mis sitios como alternativa a la nueva base de datos y la base de datos existente hasta que se alcance el número máximo de sitios para una de las bases de datos.
Sitios de grupo
Para los sitios de grupo, en el ejemplo de diseño se logra de nuevo que la escala sea eficaz mediante la administración de bases de datos en el tamaño de destino máximo. Se espera que los sitios de grupo de la mayoría de las organizaciones sean mucho mayores que los sitios de Mis sitios. En el ejemplo de diseño se proporciona una configuración de la base de datos según un límite de 30 GB para las colecciones de sitios. Elija un límite que sea apropiado para los sitios de grupo de la organización.
Otro método para las organizaciones con grupos que tienen grandes necesidades de almacenamiento es dedicar una sola base de datos a cada colección de sitios de grupo de nivel superior.
Sitio web de asociados
De forma similar que Mis sitios, el sitio web de asociados logra que la escala sea eficaz mediante la administración de bases de datos en el tamaño de destino máximo. Sin embargo, en el ejemplo de diseño el sitio web de asociados también hospeda la colección de sitios de creación para el sitio Internet de la empresa. Por lo tanto, el diseño de la base de datos incorpora ambos métodos:
La colección de sitios de creación se hospeda en una base de datos dedicada.
La base de datos y las opciones de tamaño se configuran para administrar los demás sitios y bases de datos.
Dado que el sitio web de asociados se hospeda en una aplicación web dedicada, se pueden crear límites de tamaño más adecuados para los tipos de sitios creados. En el ejemplo de diseño se proporciona la siguiente configuración de tamaño:
Tamaño de destino de la base de datos = 200 GB
Cuota de almacenamiento por sitio = 5 GB
Número máximo de sitios = 40
La colección de sitios de creación se hospeda en una base de datos dedicada.
Sitio Internet de la empresa
Mediante el uso de una sola colección de sitios en el diseño del sitio Internet de la empresa, se puede usar una sola base de datos para esta aplicación web.
Zonas y direcciones URL
En el ejemplo de diseño se muestra cómo coordinar direcciones URL a través de varias aplicaciones dentro de una implementación corporativa.
Objetivos de diseño
Los siguientes objetivos tienen influencia en las decisiones de diseño para las direcciones URL:
Las convenciones de direcciones URL no se limitan a las zonas a través de las cuales se puede tener acceso al contenido.
Los puertos estándar HTTP y HTTPS (80 y 443) se pueden usar en todas las aplicaciones del ejemplo de diseño.
Los números de puerto no se incluyen en las direcciones URL. En la práctica, no se suelen usar números de puerto en entornos de producción.
Principios de diseño
Para lograr estos objetivos de diseño, se aplican los siguientes principios de diseño:
No se usan colecciones de sitios con nombre de host. Tenga en cuenta que las colecciones de sitios con nombre de host son diferentes de los encabezados host de IIS. Las colecciones de sitios con nombre de host no funcionan con la característica de asignaciones alternativas de acceso. Se requiere esta característica para tener acceso al mismo contenido a través de varias direcciones URL de dominio. Por lo tanto, cuando se usan sitios con nombre de host, estos sitios sólo están disponibles a través de la zona predeterminada.
Cada aplicación incorpora una sola colección de sitios raíz. Se trata de un requisito para usar asignaciones alternativas de acceso. Si varias colecciones de sitios raíz son necesarias dentro de una aplicación web y se espera usar únicamente la zona predeterminada para el acceso de usuarios, las colecciones de sitios con nombre de host son una buena opción.
Para las aplicaciones que incluyen varias colecciones de sitios de nivel alto, donde cada colección de sitios representa un grupo de nivel superior o proyecto (por ejemplo, sitios de grupo), en el ejemplo de diseño se incorporan rutas de acceso administradas. Las rutas de acceso administradas proporcionan mayor control sobre las direcciones URL de estos tipos de sitios.
Desventajas del diseño
El cumplimiento de los objetivos de diseño tiene algunas desventajas, entre las que se incluyen las siguientes:
Las direcciones URL son más largas.
No se usan colecciones de sitios con nombre de host.
Diseño de direcciones URL de carga equilibrada
Al crear una aplicación web, se debe elegir una dirección URL de carga equilibrada para asignar a la aplicación. Además, se debe crear una dirección URL de carga equilibrada para cada zona que se cree dentro de una aplicación web. La dirección URL de carga equilibrada incluye el protocolo, el esquema, el nombre de host y el puerto, si se usan. La dirección URL de carga equilibrada debe ser única en todas las zonas y aplicaciones web. Por lo tanto, cada aplicación y cada zona dentro de cada aplicación requieren una dirección URL única en el ejemplo de diseño.
Intranet
Cada una de las tres aplicaciones web que componen la intranet requieren una dirección URL única. En el ejemplo de diseño, la audiencia de destino para el contenido de intranet consta de los empleados internos y remotos. En el ejemplo de diseño de autenticación de notificaciones, los empleados usan las mismas direcciones URL para cada una de estas aplicaciones independientemente de si son remotos o internos. Aunque este método agrega una capa de seguridad al diseño de SharePoint (todo el tráfico es SSL), requiere que se enrute el tráfico interno a través del producto de puerta de enlace o firewall junto con el tráfico remoto o que se configure un entorno DNS dividido para resolver las solicitudes internas dentro de la red interna.
En el ejemplo de diseño de autenticación clásica, las direcciones URL son diferentes para los empleados internos y remotos. En la siguiente tabla se muestran las direcciones URL para que los empleados internos y remotos tengan acceso a cada aplicación en el ejemplo de diseño de autenticación clásica.
| Aplicación | Dirección URL del empleado interno | Dirección URL del empleado remoto |
|---|---|---|
Contenido de intranet publicado |
http://fabrikam |
https://intranet.fabrikam.com |
Sitios de grupo |
http://teams |
https://teams.fabrikam.com |
Mis sitios |
http://my |
https://my.fabrikam.com |
Sitio web de asociados
En el ejemplo de diseño, los empleados internos, los empleados remotos y los empleados de asociados tienen acceso al sitio web de asociados. En el ejemplo de diseño de autenticación de notificaciones, cada uno de estos usuarios escribe la misma dirección URL, independientemente del método de autenticación. En el ejemplo de diseño de autenticación clásica, cada tipo distinto de usuario escribe una dirección URL diferente. Aunque los empleados remotos y los empleados de asociados tienen acceso al sitio web de asociados de forma externa mediante SSL (HTTPS), cada grupo necesita una dirección URL diferente para aplicar las ventajas de usar zonas separadas; es decir, distintos métodos de autenticación y distintas directivas de zona. En la siguiente tabla se muestran las direcciones URL que los empleados internos, los empleados remotos y los asociados usan para tener acceso al sitio web de asociados, tal como se muestra en el ejemplo de diseño de autenticación clásica.
| Zona | Dirección URL |
|---|---|
Dirección URL del empleado interno |
http://partnerweb |
Dirección URL del empleado remoto |
https://remotepartnerweb.fabrikam.com |
Dirección URL del asociado |
https://partnerweb.fabrikam.com |
Sitio Internet de la empresa
El sitio Internet de la empresa es un sitio público y cualquier usuario puede tener acceso a éste a través de la dirección URL predeterminada, http://www.fabrikam.com. Se aplican las directivas de la zona de Internet (es decir, acceso anónimo y denegar escritura).
Sin embargo, para admitir tareas de creación y administración en el sitio público, el ejemplo de diseño incorpora direcciones URL para los empleados internos y remotos. Se pueden usar directivas para que estas zonas garanticen acceso adecuado a los grupos de seguridad de destino para tareas de creación y mantenimiento. Los ejemplos de diseño de autenticación clásica y de autenticación de notificaciones usan el mismo método para esta granja de servidores. En la siguiente tabla se muestran las direcciones URL para cada zona.
| Zona | Dirección URL |
|---|---|
Dirección URL del empleado interno |
http://fabrikamsite |
Dirección URL del empleado remoto |
https://fabrikamsite.fabrikam.com |
Dirección URL del cliente |
http://www.fabrikam.com |
Uso de inclusiones explícitas y de caracteres comodín para las rutas de dirección URL
Al definir rutas de acceso administradas, puede especificar qué rutas del espacio de nombres URL de una aplicación web se usan para colecciones de sitios. Puede especificar que existen una o varias colecciones de sitios en una ruta de acceso distintiva situada por debajo del sitio raíz. Sin rutas de acceso administradas, todos los sitios creados por debajo de la colección de sitios raíz forman parte de la colección de sitios raíz.
Puede crear los dos tipos siguientes de rutas de acceso administradas:
Inclusión explícita: una colección de sitios con la dirección URL explícita que asigne el usuario. Una inclusión explícita se aplica a una sola colección de sitios. Puede crear varias inclusiones explícitas por debajo de una colección de sitios raíz. Una dirección URL de ejemplo para una colección de sitios creada con este método es http://fabrikam/hr. Hay un impacto en el rendimiento para cada ruta de acceso explícita agregada, por lo que se recomienda limitar el número de colecciones de sitios creado con una inclusión explícita a unos 20.
Inclusión de caracteres comodín: se agrega una ruta de acceso a la dirección URL. Esta ruta de acceso indica que todos los sitios especificados directamente después del nombre de la ruta de acceso son colecciones de sitios únicas. Esta opción se suele usar para colecciones de sitios que admiten la creación de sitios sin intervención del administrador, como Mis sitios. Una dirección URL de ejemplo para una colección de sitios creada con este método es http://my/personal/user1.
En el ejemplo de diseño se incorpora el uso de ambos tipos, tal como se describe en las secciones siguientes.
Inclusiones explícitas: contenido publicado de intranet
En el ejemplo de diseño, la aplicación web de intranet publicada incorpora el uso de inclusiones explícitas.
Contenido de intranet publicado
En la aplicación web de contenido de intranet publicado, se usa una inclusión explícita para cada subsitio, por ejemplo, recursos humanos, instalaciones y compras. Cada una de estas colecciones de sitios puede asociarse con una base de datos de contenido diferente, si es necesario. El uso de inclusiones explícitas en este ejemplo asume que no se crea ningún otro tipo de sitio en la aplicación web, incluidas las inclusiones de caracteres comodín.
El límite recomendado para los sitios creados con una inclusión explícita es de aproximadamente 20. Si la organización requiere un número mayor de colecciones de sitios, considere la posibilidad de usar una inclusión de caracteres comodín o colecciones de sitios con nombre de host.
En el ejemplo de diseño de autenticación clásica, el uso de inclusiones explícitas da como resultado las direcciones URL que se muestran en la tabla siguiente.
| Empleado interno (zona de intranet) | Empleado remoto (zona predeterminada) |
|---|---|
http://fabrikam |
https://intranet.fabrikam.com |
http://fabrikam/hr |
https://intranet.fabrikam.com/hr |
http://fabrikam/facilities |
https://intranet.fabrikam.com/facilities |
http://fabrikam/purchasing |
https://intranet.fabrikam.com/purchasing |
En este ejemplo, la colección de sitios raíz, http://fabrikam, representa la página principal predeterminada de la intranet. Este sitio está pensado para hospedar contenido para los usuarios.
Inclusión de caracteres comodín: sitios de grupo, Mis sitios y sitio web de asociados
Los sitios de grupo, Mis sitios y la aplicación web de asociados incorporan el uso de una inclusión de caracteres comodín. Las inclusiones de caracteres comodín son ideales para las aplicaciones que permiten a los usuarios crear sus propias colecciones de sitios y para las aplicaciones web que incluyen muchas colecciones de sitios. Una inclusión de caracteres comodín indica que el siguiente elemento después del carácter comodín es un sitio raíz de una colección de sitios.
Sitios de grupo
Dentro de la aplicación de sitios de grupo, la inclusión de caracteres comodín se usa para cada colección de sitios de grupo. Las prácticas de buen gobierno recomiendan que se mantenga el número de sitios de grupo de nivel superior dentro de un número manejable. Además, la taxonomía para sitios de grupo debe ser lógica para el funcionamiento de un negocio.
En el ejemplo de diseño de autenticación clásica, el uso de inclusiones de caracteres comodín da como resultado las direcciones URL que se muestran en la tabla siguiente.
| Empleado interno (zona de intranet) | Empleado remoto (zona predeterminada) |
|---|---|
http://teams/sites/Team1 |
https://teams.fabrikam.com/sites/Team1 |
http://teams/sites/Team2 |
https://teams.fabrikam.com/sites/Team2 |
http://teams/sites/Team3 |
https://teams.fabrikam.com/sites/Team3 |
En este ejemplo, la colección de sitios raíz, http://team, no necesariamente hospeda contenido para los usuarios.
Mis sitios
Mis sitios ofrecen creación de sitios sin intervención del administrador. Cuando un usuario que examina la intranet hace clic por primera vez en Mi sitio, se crea un sitio automáticamente para el usuario. En el ejemplo de diseño, Mis sitios incluyen una inclusión de caracteres comodín denominada /personal (http://my/personal). La característica de Mi sitio anexa automáticamente el nombre de usuario a la dirección URL.
En el ejemplo de diseño de autenticación clásica, esto da como resultado las direcciones URL con el formato que se muestra en la tabla siguiente.
| Empleado interno (zona de intranet) | Empleado remoto (zona predeterminada) |
|---|---|
http://my/personal/user1 |
https://my.fabrikam.com/personal/user1 |
http://my/personal/user2 |
https://my.fabrikam.com/personal/user2 |
http://my/personal/user3 |
https://my.fabrikam.com/personal/user3 |
Aplicación web de asociados
La aplicación web de asociados está diseñada para permitir que los empleados creen fácilmente sitios seguros para la colaboración con asociados externos. Para lograr este objetivo, se permite la creación de sitios sin intervención del administrador.
En el ejemplo de diseño de autenticación clásica, la aplicación web de asociados incluye una inclusión de caracteres comodín denominada /sites (http://partnerweb/sites). Esto da como resultado las direcciones URL con el formato que se muestra en la tabla siguiente.
| Empleado interno (zona de intranet) | Empleado remoto (zona predeterminada) |
|---|---|
http://partnerweb/sites/project1 |
https://remotepartnerweb.fabrikam.com/sites/project1 |
http://partnerweb/sites/project2 |
https://remotepartnerweb.fabrikam.com/sites/project2 |
http://partnerweb/sites/project3 |
https://remotepartnerweb.fabrikam.com/sites/project3 |
Los colaboradores de asociados pueden tener acceso a los sitios web de asociados mediante las direcciones URL que aparecen en la tabla siguiente.
| Asociado (zona de extranet) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
La excepción para la aplicación web de asociados, tal como se muestra en los ejemplos de diseño, es la colección dedicada a crear el contenido para el sitio Internet de la empresa. Para esta colección de sitios, se usa una inclusión explícita. Esto proporciona un ejemplo del uso de las inclusiones explícitas y las inclusiones de caracteres comodín en la misma aplicación web.
Directivas de zona
Puede crear una directiva para que una aplicación web exija permisos en el nivel de la aplicación web. Se puede definir una directiva para la aplicación web en general o solo para una zona específica. Una directiva exige permisos en todo el contenido dentro de la aplicación web o la zona. Los permisos de directiva invalidan todas las demás opciones de seguridad configuradas para los sitios y el contenido. Puede configurar la directiva según usuarios o grupos de usuarios, pero no según grupos de SharePoint. Si agrega o cambia una directiva de zona, la búsqueda debe volver a rastrear los sitios para recoger los nuevos permisos.
Las directivas no se usan en el ejemplo de diseño de autenticación de notificaciones para la granja de servidores de colaboración donde se habilitan varios tipos de autenticación en una sola zona. Las directivas se implementan en el ejemplo de diseño de autenticación clásica y en la granja publicada del ejemplo de diseño de autenticación de notificaciones donde se recomienda la autenticación de Windows. En la granja de servidores publicada, el uso de directivas agrega una capa adicional de seguridad entre los usuarios anónimos y los usuarios que tienen acceso para administrar los sitios.
Los ejemplos de diseño proporcionan ejemplos de varias directivas para conseguir lo siguiente:
Denegar el acceso de escritura al contenido publicado.
Garantizar que los autores e ingenieros de pruebas tienen acceso adecuado al contenido publicado.