Este artículo proviene de un motor de traducción automática.

Seguridad de SharePoint

Seguridad personalizada basada en notificaciones en SharePoint 2010

Feng Marfil, Shabbir Darugar

Descargar el ejemplo de código

Microsoft SharePoint 2010 introdujo un nuevo modelo de identidad basada en solicitudes para la creación de aplicaciones para notificaciones.Cuando un usuario trata de una aplicación para notificaciones, presenta una identidad a la aplicación como un conjunto de notificaciones.Estas notificaciones permiten una autorización más específica para el contenido.Por lo tanto, los usuarios con ciertos atributos, como el código de país y código de departamento, se conceden acceso al contenido apropiado.

Implementación de seguridad basada en solicitudes a nivel empresarial presenta algunos desafíos interesantes.Examinaremos el proceso de creación de un proveedor de notificaciones personalizadas (CCP) en SharePoint, integración con Microsoft FAST Search Server 2010 para SharePoint, administración de contenido de las reclamaciones desde la perspectiva del usuario y evitar algunos problemas comunes.Como lo hacemos, aprenderá a diseñar e implementar un modelo de seguridad personalizada dinámica basada en solicitudes en 2010 de SharePoint.Vamos a utilizar portal de recursos humanos de la empresa Contoso, ContentWeb, para nuestro ejemplo.

Descripción de la aplicación

Contoso es una empresa global con cerca de 100.000 empleados, y ContentWeb contiene una gran cantidad de información que los autores de contenido necesitan para administrar en forma diaria para cada semana.En la mayoría de los casos, el contenido es aplicable a la gente en un país pero no en otro, a una disciplina, pero no en otro, o a todos los empleados de Contoso.Sin embargo, algunos de los contenidos, es información confidencial que debe estar disponible para sólo un pequeño subconjunto de los empleados (por ejemplo, VPs).

Para cubrir esas una amplia audiencia, ContentWeb utiliza grupos de SharePoint (SPGs) con notificaciones personalizadas secure y destinar contenido explícitamente.Reclamaciones específicas a las necesidades de Contoso están almacenadas en una base de datos y se utiliza para definir reclamación "conjunto" un usuario. Es este conjunto de reclamaciones que determina lo que un empleado puede y no puede ver.Una interfaz de administración permite a los trabajadores de la información que admiten el cambio de portal o aumentan su propio conjunto de reclamaciones, así como la posibilidad para ver el portal como un usuario diferente.Esta eficaz característica personalizada se denomina vista Portal como (APV).

ContentWeb utiliza basada en solicitudes autenticación de Windows en SharePoint 2010 y FAST Search Server 2010 para SharePoint como el motor de búsqueda en un entorno de búsqueda federada enterprise.

¿Por qué un CCP?

Cuando un usuario inicia sesión en ContentWeb, la autenticación de Windows basada en solicitudes proporciona un conjunto de solicitudes de Active Directory, que actúa como el proveedor de identidades.Sin embargo, estas notificaciones solos no son suficientes para ContentWeb proteger y contenido de destino.ContentWeb requiere información de usuario adicionales de repositorios de datos empresariales como SAP para crear un conjunto de solicitud completo que describe el usuario.Por lo tanto, necesitamos un CCP para aumentar las reclamaciones.Utilizamos estas notificaciones personalizadas para explícitamente secure y destinar el contenido al usuario.

Tener un CCP permite Contoso determinar quéreclamación tipos y valores desea utilizar para describir los empleados, proveedores y demás funciona con.Este modelo es escalable; permite que Contoso cambiar con eficiencia con el tiempo, como los cambios de su negocio.

Porque no se pueden editar fácilmente las solicitudes procedentes de Active Directory, también necesita un CCP para admitir APV.VPA se utiliza principalmente cuando una persona autorizada (usuario) que desea ver el portal que otra persona (usuario B).En tales casos, el proveedor de notificaciones personalizadas agrega notificaciones personalizadas de usuario b en el conjunto de solicitud del usuario a autorizar, por tanto, el usuario a ver el contenido que puede tener acceso el usuario B.

Las notificaciones que un usuario posee son atributos que representan su "perfil". Los usuarios pueden tener reclamaciones simples y compuestas.Reclamaciones simples, como CountryCode y UserType, son fáciles de entender.ContentWeb utiliza un conjunto predefinido de reclamaciones simples — o, más exactamente, los tipos de notificaciones simple.Sin embargo, en ocasiones, un empleado debe tener permiso para contenido que tiene más de un tipo de notificación; Por ejemplo, CountryCode = US Y UserType = FullTimeEmployee: la condición AND.En ese caso, crear notificaciones compuestos.

Fuera de la caja, SharePoint 2010 evalúa las reclamaciones en Reclamación de un usuario establece mediante la lógica OR.Esto significa que SharePoint 2010 admite sólo la condición o para la seguridad y de destino, y que no siempre es suficiente.Veamos un ejemplo.ContentWeb tiene tanto una reclamación CountryCode y un UserType.Necesita para proteger parte del contenido de los Estados Unidos a tiempo completoempleados utilizando CountryCode = US Y UserType = FullTimeEmployee.Nosotros no podemos satisfacer este requisito directamente en SharePoint 2010 usando las reclamaciones simples CountryCode o UserType, por lo que necesitamos crear una compuesto reclamación para representar con ambas alegaciones.

Podríamos crear un nuevo tipo de notificación para los Estados Unidos a tiempo completoempleados.Sin embargo, si la empresa crea nuevas oficinas en otros países, a continuación, necesitamos actualizar nuestro código fuente CCP para agregar los tipos de notificación correspondiente.Claramente, esto puede resultar costoso y lento.Además, el equipo de negocios de ContentWeb quiere ser capaz de agregar y quitar los tipos de notificación compuesto sin necesidad de una nueva versión de la aplicación cada vez.Como puede ver, ContentWeb requiere un modelo de seguridad dinámica y extensible.

¿Cómo se administra todos los datos de reclamaciones?Utilizaremos esta base de datos denominada ContentWebAdminDB para almacenar los metadatos de la reclamación.ContentWebAdminDB es el reclamaciones origen back-end; consolida todos los datos de origen de reclamaciones de SAP y otras bases de datos empresariales.Trataremos esta base de datos de más de un bit.Y vamos a utilizar cualquier aplicación ASP.NET aplicación administrativa denominada ContentWebAdmin para conectarse a esta base de datos para crear y actualizar metadatos compuestos de reclamaciones y la configuración de APV.(Detalles de esta aplicación están fuera del ámbito de este artículo). Reclamaciones compuestos se crean mediante reclamaciones simples.Por ejemplo, en la aplicación ContentWebAdmin podemos crear una compuesto reclamación llamada FullTimeEmployee-US utilizando el CountryCode = US y UserType = reclamaciones de fulltimeemployee simples.Con estos metadatos de Reclamación de coumpound, para cualquier usuario que tenga CountryCode = US y UserType = reclamaciones de fulltimeemployee simples, una nueva reclamación compuesta US-FullTimeEmployee = true, se incorporarán de conjunto de solicitud del usuario.Nota que ningún compuesto reclamar US-FullTimeEmployee = false aparece en el conjunto de solicitud de cualquier usuario.Con este diseño dinámico reclamaciones compuesto, cada usuario tiene sólo unos pocos docena reclamaciones en total, aunque la permutación de reclamaciones compuestas puede ser bastante alta.Esto es esencial para garantizar un buen rendimiento.

Cuando un usuario inicia sesión ContentWeb, se invoca el CCP.CCP llama a un procedimiento almacenado personalizado, sp_GetUserClaims, en ContentWebAdminDB al pasar de la notificación de identidad del usuario.El procedimiento almacenado comprueba la configuración de VPA y devuelve todas las reclamaciones simples y compuestas para ese usuario al CCP.Como puede ver, reclamaciones compuestas dinámicas no están igual a las reglas de autorización dinámico.Nuestras solución no cambia la forma en que SharePoint 2010 de reclamaciones compuestos evalúa las reclamaciones.Nosotros simplemente inyectar reclamaciones compuestas en conjuntos de notificaciones de usuario según la configuración de los metadatos de reclamaciones compuesto.Figura 1 muestra una descripción general de ContentWeb.

Figura 1 vista de alto nivel de ContentWeb

Dentro del proveedor de créditos personalizados ContentWeb

CCP ContentWeb tiene una clase especial que se hereda de Microsoft.SharePoint.Administration.SPClaimProvider.Figura 2 muestra parte de esta clase.Tenga en cuenta la línea 16 del código (que se establece la propiedad textoparamostrar).Hemos agregado para ayudar a hacer nuestras reclamaciones tipos y valores de visualización de una manera más fácil de usar y legible.

Figura 2 reclamaciones más legible

protected override void FillResolve(
  Uri context, string[] entityTypes, SPClaim resolveInput,
  List<Microsoft.SharePoint.WebControls.PickerEntity> resolved)
{
  string claimTypeName = string.Empty;
  string claimValue = string.Empty;
 
  // Handles only ContentWeb claim types
  if (null != resolveInput && resolveInput.ClaimType.Contains(
    ContentWebClaimTypes.ContentWebClaimTypePrefix))
  {
    claimValue = resolveInput.Value.ToLower();
    claimTypeName = GetName(resolveInput.ClaimType);
 
    PickerEntity entity = CreatePickerEntity();
    entity.Claim = resolveInput;
    entity.Description = resolveInput.ClaimType + " = " + claimValue;
    entity.DisplayText = claimTypeName + " = " + claimValue;
    entity.EntityData[PeopleEditorEntityDataKeys.DisplayName] =
      claimTypeName + " = " + claimValue;
    entity.EntityType = SPClaimEntityTypes.User;
    entity.IsResolved = true;
    resolved.Add(entity);
  }
}

CCP ContentWeb necesita una cadena de conexión para llamar a un procedimiento almacenado en ContentWebAdminDB para las reclamaciones del usuario. Como CCP es una característica del conjunto de servidores, no es en el ámbito de cualquier aplicación Web, por lo que no podemos utilizar el archivo web.config para configurar la cadena de conexión de base de datos. Podríamos usar machine.config, pero que no es ideal porque tenemos varios Web front-ends. En su lugar, utilizaremos el almacén de objetos jerárquicos de SharePoint, SPPersistedObject, para almacenar la cadena de conexión de base de datos. Esto se almacena en la base de datos de configuración de SharePoint, haciendo que la cadena de conexión de base de datos disponibles para todos los servidores cliente Web de la granja de SharePoint.

Dentro de la CCP ContentWeb, creamos una clase que hereda de Microsoft.SharePoint.Administration.SPPersistedObject, como se muestra en figura 3.

Figura 3 de la clase ConnectionStringStorage

[Guid("56705e15-abd3-44f0-adea-91488da1a572")]
public class ConnectionStringStorage
  : Microsoft.SharePoint.Administration.SPPersistedObject
{
    [Persisted]
    private string m_connectionString;
 
    public ConnectionStringStorage()
    {
    }
 
    public ConnectionStringStorage(
      string name, SPPersistedObject parent)
      : base(name, parent)
    {
    }
 
    public ConnectionStringStorage(
      string name, SPPersistedObject parent, Guid guid)
      : base(name, parent, guid)
    {
    }
 
    public string ConnectionString
    {
      get { return m_connectionString; }
      set { m_connectionString = value; }
    }
}

Utilizaremos la siguiente secuencia de comandos Windows PowerShell para registrar la cadena de conexión de base de datos:

[System.Reflection.Assembly]::LoadWithPartialName(
  "Microsoft.Sample.ContentWeb.ClaimsSecurity")
$id = new-object System.Guid("56705e15-abd3-44f0-adea-91488da1a572")
$farm = Get-SPFarm
$existingObject = $farm.GetObject($id)
$existingObject.Delete()
$newObject =
  new-object Microsoft.Sample.Contoso.ClaimsSecurity.ConnectionStringStorage(
  "ConnectionString", $farm, $id)
$newObject.ConnectionString = "Data Source=ContentWebAdminSQLServer;
  Initial Catalog=ContentWebAdminDB;Integrated Security=True;Timeout=30"
$newObject.Update();
Iisreset

Como puede observar, hacemos referencia a la dll CCP. Creamos un nuevo objeto ConnectionStringStorage y establezca su propiedad ConnectionString. Por último, llamamos su método Update para guardarlo en la base de datos de configuración de SharePoint.

Se recomienda que la cadena de conexión tiene un valor de tiempo de espera de menos de 60 segundos. El CCP tiene un tiempo de espera de ejecución predeterminado de 60 segundos. Esto significa que si se agota el tiempo de espera de la conexión de base de datos, tiene la capacidad para capturar la excepción real de la cadena de conexión en lugar de una engañosa la ejecución de la CCP.

Dentro de constructor de CCP, se podrá recuperar la cadena de conexión y almacenarlo en una variable de nivel de módulo:

public class ContentWebClaimProvider : SPClaimProvider
{
  private static string connectionString = null;
 
  public ContentWebClaimProvider(string displayName)
    : base(displayName)
  {
    Guid guid = new Guid(@"56705e15-abd3-44f0-adea-91488da1a572");
    ConnectionStringStorage storage =
      (ConnectionStringStorage)SPFarm.Local.GetObject(guid);
    connectionString = storage.ConnectionString;
  }
}

Queremos ser capaces de seguimiento cuando CCP se conecta a la base de datos para las reclamaciones del usuario. SharePoint 2010 tiene una nueva característica que es perfecta para esto. Se llama el objeto Microsoft.SharePoint.Utilities.SPMonitoredScope, y supervisa el rendimiento y uso de recursos para un bloque de código especificado. El siguiente código registra las llamadas de base de datos de la CCP:

using (new SPMonitoredScope("ContentWeb.CCP.GetUserClaims", 5))
{
  userClaimsDataSet = CustomClaimSourceDA.GetUserClaims(
    userAlias, connectionString);
}

También podemos configurar el nivel de evento y el nivel de seguimiento de este evento en la Administración Central de SharePoint. Estos son controlados por el objeto de supervisión en la categoría SharePoint Foundation bajo supervisión | Reporting | Configurar el registro de diagnóstico.

Dentro de la base de datos ContentWebAdminDB

Como mencionamos anteriormente, ContentWebAdminDB consolida los datos del usuario Reclamación de SAP y otras bases de datos empresariales y contiene el origen de notificación personalizada. CCP ContentWeb llama a un procedimiento almacenado, sp_GetUserClaims, para recuperar notificaciones personalizadas de un usuario.

La aplicación de ContentWebAdmin permite a los usuarios autorizados configurar notificaciones compuestos y VPA para un usuario. ContentWebAdminDB almacena los metadatos de la configuración de reclamaciones compuestos y la configuración de VPA en tablas. Cuando CCP ContentWeb llama a sp_GetUserClaims, este procedimiento almacenado se VPA configuración y, a continuación, devolver reclamaciones simples y compuestas reclamaciones. El diseño detallado y la implementación de esta base de datos está fuera del ámbito de este artículo. Sin embargo, incluimos una secuencia de comandos SQL para un procedimiento de sp_GetUserClaims ficticio almacenado con valores de Reclamación codificados dentro del paquete de código descargable.

Uso de grupos de SharePoint

Un SPG es un contenedor lógico de los usuarios de SharePoint. Esto es útil para ContentWeb, que utiliza cientos de reclamaciones compuestas. Sin SPGs, sería muy difícil para los autores de contenido administrar todos los reclamos.

Uso de SPGs ofrece las siguientes ventajas:

• Nombre descriptivo: SPGs permiten a los usuarios crear nombres de grupo descriptivo y significativo para los valores de la reclamación potencialmente crípticos. Por ejemplo, ContentWeb tiene un SPG denominado "Nos empleados a tiempo completo" que describe los usuarios que tengan la notificación de los valores de país = Estados Unidos, CompanyCode = 1010 y UserSubType = FTE.
• Soporte de resolución de las personas selector nombre: el control de selector de personas en 2010 SharePoint admite la resolución de nombres para SPGs. Esto facilita buscar y seleccionar SPGs, tal como se muestra en figura 4.

Figura 4 grupos de SharePoint en el selector de personas

• Administración de seguridad de Reclamación dinámica: supongamos que necesita cambiar la definición de "Nos empleados a tiempo completo," Agregar UserType = Corp a los otros atributos: país = Estados Unidos, CompanyCode = 1010 y UserSubType = FTE — debido a cambiantes de la empresa necesita. Es fácil realizar el cambio en sólo ese uno GPP y todos los objetos protegidos en que SPG automáticamente heredaría este cambio.
• **Sólo un SPG para asegurar y contenido de destino:**SharePoint 2010 ahora soporta la capacidad para proteger y un objeto utilizando el mismo SPG de destino. Esto elimina la carga típica asociada con la creación de las audiencias, importar perfiles de usuario, ejecutando la tarea de sincronización de perfiles, etc. destinadas a.
• Varias reclamaciones asociados uno SPG: supongamos que necesita para proteger una página para empleados a jornada completa cuyo nivel oscila entre 60 a 65. Puede hacerlo fácilmente mediante la creación de un SPG que tiene esta reclamaciones para UserSubType = FTE y Level = 60, UserSubType = FTE y Level = 61… UserSubType = FTE y Level = 65. SharePoint 2010 interpreta todos estos reclamos como "OR".

Administrar muchos SPGs tiene el potencial para ser lentos, engorrosos y propenso a errores. El equipo de negocios de ContentWeb utiliza un archivo de Excel para administrar cientos de grupos con notificaciones personalizadas asociadas.

Hay varias opciones para automatizar la creación de SPGs. Hemos creado una secuencia de comandos Windows PowerShell que lee datos de un archivo XML para automatizar esta tarea. (Encontrará esta secuencia de comandos en la descarga de código, que puede descargarse desde code.msdn.microsoft.com/mag201111SPSecurity.) Se llena el archivo de datos XML utilizando el archivo de Excel del equipo de negocios. Figura 5 muestra el archivo de configuración XML de ejemplo.

Figura 5 ejemplo de archivo de configuración de XML

<?xml version="1.0" encoding="utf-8"?>
<SharePointGroups url="http://contentweb" owner="contoso\ivfeng" >
  <SharePointGroup name="ContentWeb-FTE"
    description="ContentWeb-FTE" permissionLevel="Read">
    <Claim type="UserType" value="emp"/>
  </SharePointGroup>
  <SharePointGroup name="ContentWeb_US_0000_Emp_Corp_HRPro"
    description="ContentWeb_US_0000_Emp_Corp_HRPro">
    <Claim type="CompoundClaim" value="US+emp+corp+hrpro"/>
  </SharePointGroup>
  <SharePointGroup name="ContentWeb_US_0000_Emp_Corp_Manager"
     description="ContentWeb_US_0000_Emp_Corp_Manager">
    <Claim type="CompoundClaim" value="us+emp+corp+manager"/>
    <Claim type="CompoundClaim" value="US+emp+corp+hrpro"/>
  </SharePointGroup>
</SharePointGroups>

Usando SPGs destino

Para usar los destinatarios, necesita la aplicación de servicio de perfil de usuario habilitada para la aplicación Web.

Hay un problema complicado debe tener en cuenta cuando se utiliza SPGs destinadas a. Inicialmente, descubrimos que la SPGs que contiene los usuarios de Active Directory o grupos de seguridad fueron todo funciona correctamente, pero las SPGs que contiene los usuarios notificación personalizada no funcionan en absoluto. La causa raíz estaba relacionada con el nivel de permiso de esos grupos. Cuando creamos las SPGs con notificaciones personalizadas, no deseamos asignar cualquier nivel de permisos predeterminado. Sin embargo, si un SPG no está asignado un nivel de permisos cuando crea y utiliza posteriormente para la seguridad, éste se marcará con un nivel de permiso especial denominado acceso limitado, como se muestra en figura 6.

Figura 6 una marca de grupo de SharePoint con acceso limitado

Debido a que ContentWeb tiene cientos de SPGs y la mayoría de ellos sólo se utiliza para la audiencia de destino, no tienen ningún nivel de permisos establecido. Sin embargo, no se puede extraer el procesador de la audiencia de destino en estas SPGs sin ningún nivel de permiso. Nosotros tuvimos la suerte y descubrió una solución a través de la interfaz de usuario permiso de la página que nos estábamos aplicando a la audiencia de destino. Nos concede permiso para los SPGs se utiliza para la audiencia de destino, a continuación, inmediatamente deshizo este permiso "Lectura". Este proceso hace que SharePoint marcar estos SPGs con el nivel de permiso de acceso limitado, y la audiencia de destino felizmente respeta ese nivel de permisos. Es importante tener en cuenta que no tienes que vaya a través de esta concesión y deshacer el proceso para los SPGs varias veces. Debe hacerlo una vez dentro del árbol de herencia de seguridad. Tenga en cuenta que si se interrumpe la herencia de seguridad, debe hacerlo de nuevo, incluso si usted ya lo han hecho en el nivel primario.

Aplicación de búsqueda de ContentWeb

Uno de nuestros principales objetivos con esta aplicación fue mejorar la experiencia de búsqueda para los empleados de Contoso. Queríamos ContentWeb para que el contenido mucho más intuitivo, lo que había sido en el pasado.

Para hacer esto para ContentWeb, usamos FAST Search Server 2010 para SharePoint alojado en un entorno federado. Hacer referencia a figura 1 para Contoso del FED en entorno de búsqueda rápida. Esto demuestra una granja de SharePoint llamada la granja federación de búsqueda rápida. Detrás de este conjunto de servidores es Microsoft FAST Search Server para la base de datos y motor de SharePoint. El conjunto de servidores de búsqueda rápida contiene todas las consultas búsqueda servicio de aplicaciones (consulta SSAs) y un contenido SSA.

Naturalmente, hemos creado un origen de contenido dentro de los SSA de contenido existente. (Servidor de búsqueda rápida recomienda SSA contenido sólo uno). Una vez hecho esto, el SSA contenido será rastrear la base de datos de contenido de ContentWeb y realizar el índice de búsqueda disponibles en ContentWeb y otras aplicaciones de intranet.

A continuación, crea un SSA consulta independiente y lo publicó en ContentWeb. Con la prueba de búsqueda inicial en ContentWeb, descubrimos que funcionó la búsqueda básica, pero recorte de seguridad de la búsqueda no estaba funcionando como se esperaba. Para las páginas que se protegen con notificaciones personalizadas de ContentWeb, los usuarios no podrían ver los vínculos dentro de los resultados de búsqueda incluso aunque tengan los permisos de seguridad. Nos supimos que necesitábamos para que las asignaciones de tipos de notificación personalizada registradas en la granja de SharePoint de búsqueda rápida para recorte de seguridad de búsqueda trabajar de ContentWeb. La forma más sencilla de hacerlo es implementar el CCP en la granja de SharePoint de búsqueda rápida. No sólo disponemos que confirmar el tipo de notificación se registraron las asignaciones, teníamos para asegurarse de que todos los identificadores de notificación (se muestra como la cuenta en figura 7) eran iguales en todas las granjas de SharePoint para el mismo par de valor de tipo de reclamación.

Figura 7 reclamación IDs

Actualmente, incluso con las actualizaciones acumulativas de SharePoint 2010 de junio de 2011, solicitar asignaciones de tipos en SharePoint 2010 son inmutables. Una vez implementado un CCP en una granja de SharePoint 2010, las asignaciones de tipos de reclamación se registran y se modifican aunque quitar y volver a implementar el CCP. Porque puede que tenga las CCP en varias granjas de SharePoint, es muy importante implementar todas las CCP en la misma secuencia para garantizar la notificación de los identificadores son iguales en todas las explotaciones. Si no es así, no se alineará la secuencia de identificadores y búsqueda no devolverá resultados precisos.

Cuando se rastrea el contenido de ContentWeb, no se invoca el CCP. Todo lo que necesitamos es que las asignaciones de tipos de notificación registradas en el conjunto de servidores de búsqueda rápida para que el motor del rastreador puede descodificar las notificaciones personalizadas de ContentWeb. A continuación, se almacena las notificaciones personalizadas descodificadas para la seguridad en el índice de búsqueda. Quitar el CCP ContentWeb es opcional porque se mantendrá las asignaciones de tipos de reclamación. Además, no necesitamos el CCP ContentWeb para aumentar las reclamaciones de usuario en el conjunto de servidores de búsqueda rápida.

Resultados de búsqueda de recorte de seguridad: Portales de Intranet de Contoso

Para el contenido de ContentWeb que permite realizar búsquedas desde otros portales de intranet de Contoso, es necesario asegurar lo siguiente:

• Todos los portales de intranet que necesitan para el contenido de ContentWeb de superficie deben basarse en SharePoint 2010 y aplicaciones Web basada en solicitudes que utilizan la autenticación de Windows.
• Todos los portales de intranet deben consultar el mismo índice de búsqueda rápida.
• Todos los portales de intranet deben tener el ContentWeb CCP instalado en ellos. (Si hay más de un CCP, todos deben instalarse en la misma secuencia para garantizar la reclamación que se alinean los Id.)

Si se cumplen todas estas condiciones, el contenido de ContentWeb será para búsquedas en todos los portales de intranet de Contoso.

En resumen

SharePoint 2010 proporciona sólida integración con la seguridad basada en solicitudes. Grupos de SharePoint, reclamaciones y un proveedor de notificaciones personalizadas permiten autorizar contenido para la empresa en términos generales, así como a nivel granular. Como puede ver, en muchos escenarios que puede satisfacer con relativa facilidad.

Este diseño permite a los desarrolladores crear sólidas herramientas que permiten a los trabajadores de información (como el personal de soporte técnico) para alterar sus reclamaciones y ver un sitio como un usuario diferente y, a continuación, volver.

Al igual que con nuevas implementaciones del diseño, no incluye nuestra experiencia sin "oportunidades de aprender", pero el producto final fue bien valen la pena. El código de ejemplo proporcionamos ayudarán a comenzar a hacerlo en la dirección correcta y off un estupendo inicio acerca de cómo implementar la próxima generación mediante enterprise portal!

Jinhui (Marfil) Feng es ingeniero de desarrollo de software senior en Microsoft y trabaja en sus aplicaciones de recursos humanos internos.

Shabbir Darugar es un jefe de ingeniero y proyecto de desarrollo de software senior en Microsoft y trabaja en sus aplicaciones de recursos humanos internos.

Patrick Stanko es un director de programas de Microsoft y trabaja en sus aplicaciones de recursos humanos internos.

Gracias al siguiente experto técnico para la revisión de este artículo: Tom Wisnowski