Novedades sobre mejoras de seguridad

Última modificación: miércoles, 14 de abril de 2010

Hace referencia a: SharePoint Foundation 2010

En este artículo
Autenticación e identidad basada en notificaciones
Cambio automático de contraseña y cuentas administradas
API de permisos efectivos
Servicio de almacenamiento seguro

Microsoft SharePoint Foundation y Microsoft SharePoint Server 2010 continúan aumentando y mejorando las características de seguridad de Windows SharePoint Services 3.0 y Microsoft Office SharePoint Server 2007. En este tema se resumen las nuevas características y mejoras de seguridad en SharePoint Foundation y SharePoint Server 2010.

Autenticación e identidad basada en notificaciones

La identidad basada en notificaciones es un modelo de identidad de SharePoint Foundation y SharePoint Server 2010 que incluye características como autenticación entre usuarios de sistemas de Windows y sistemas que no son de Windows, varios tipos de autenticación, autenticación más segura en tiempo real, un conjunto más amplio de tipos principales y delegación de identidad de usuario entre aplicaciones.

Cuando un usuario inicia sesión en SharePoint Foundation y SharePoint Server 2010, el token del usuario se valida y se usa después para iniciar sesión en SharePoint. El token del usuario es un token de seguridad emitido por un proveedor de notificaciones. Hay cinco modos de acceso o inicio de sesión admitidos en SharePoint Foundation y SharePoint Server 2010:

  • Inicio de sesión en modo clásico de Windows

  • Inicio de sesión en modo de notificaciones de Windows

  • Modo de inicio de sesión pasivo SAML

  • Inicio de sesión pasivo de rol y pertenencia ASP.NET

  • Acceso anónimo

Nota

Inicio de sesión pasivo SAML describe el proceso de inicio de sesión. Cuando el inicio de sesión de una aplicación web está configurado para aceptar tokens de un proveedor de inicio de sesión de confianza, se denomina inicio de sesión pasivo SAML. Un proveedor de inicio de sesión de confianza es un STS externo (es decir, externo a SharePoint) en el que SharePoint confía. Para obtener más información acerca de cómo iniciar sesión en SharePoint y los diferentes modos de inicio de sesión, vea Notificaciones entrantes: Inicio de sesión en SharePoint.

Al crear aplicaciones para notificaciones, el usuario presenta una identidad en la aplicación como conjunto de notificaciones. Una notificación puede ser el nombre del usuario, otra podría ser una dirección de correo electrónico. La idea es que un sistema de identidad externa se configura para proporcionar a la aplicación toda la información que necesita sobre el usuario con cada solicitud, junto con la comprobación criptográfica de que los datos de identidad recibidos por la aplicación provienen de una fuente de confianza.

Bajo este modelo, es más fácil de lograr el inicio de sesión único y la aplicación deja de ser responsable de las siguientes acciones:

  • Autenticación de usuarios

  • Almacenamiento de cuentas de usuario y contraseñas

  • Llamada a directorios de empresa para buscar detalles de identidad del usuario

  • Integración con sistemas de identidad de otras plataformas o compañías

Bajo este modelo, la aplicación toma decisiones relacionadas con identidad en función de las notificaciones proporcionadas por el usuario. Esto puede ser cualquier cosa desde la personalización sencilla de la aplicación con el nombre del usuario hasta la autorización del usuario para que obtenga acceso a recursos y características de alto nivel en la aplicación.

Para obtener más información acerca de la identidad basada en notificaciones y los proveedores de notificaciones, vea Conceptos e información general sobre la identidad basada en notificaciones y Proveedor de notificaciones.

Conversión de un token de usuario de suscripciones de ASP.NET a un token de seguridad de notificaciones

En SharePoint Foundation, un proveedor de pertenencia de ASP.NET debe implementar el método System.Web.Security.Membership.ValidateUser requerido. Cuando se le proporciona un nombre de usuario, el proveedor de roles devuelve una lista de roles a los que pertenece el usuario. El proveedor de pertenencia es responsable de validar la información de credenciales mediante el método System.Web.Security.Membership.ValidateUser (ahora requerido en SharePoint Foundation).

Sin embargo, el token de usuario es creado por el servicio de token de seguridad (STS) de SharePoint Foundation. El STS de SharePoint Foundation crea el token de seguridad de notificaciones a partir del nombre de usuario validado por el proveedor de pertenencia y a partir del conjunto de pertenencias a grupos asociadas con el nombre de usuario proporcionado por el proveedor de pertenencia.

Nota

Para obtener más información acerca del STS, vea Conceptos e información general sobre la identidad basada en notificaciones. Para obtener más información acerca de cómo iniciar sesión en SharePoint, vea Notificaciones entrantes: Inicio de sesión en SharePoint.

Cambio automático de contraseña y cuentas administradas

La nueva característica de cambio de contraseña automático de SharePoint Foundation permite actualizar e implementar las contraseñas sin tener que actualizar la contraseña manualmente en varias cuentas, servicios y aplicaciones web. Esto facilita la administración de contraseñas en SharePoint Foundation. Puede usar la característica de cambio de contraseña automático para determinar si una contraseña está a punto de caducar o expirar y para restablecer la contraseña mediante el uso de una cadena larga, aleatoria y criptográficamente segura.

Use cuentas administradas para implementar la característica de cambio de contraseña automático. Las cuentas administradas en SharePoint Foundation mejoran la seguridad y garantizan el aislamiento de aplicaciones.

Para obtener más información acerca de la API de cuenta administrada, vea:

API de permisos efectivos

En Windows SharePoint Services 3.0, es difícil obtener el permiso efectivo del usuario en objetos protegibles, como SPWeb, SPList, SPListItem, etc. Con el tiempo, el sitio puede tener una configuración de permisos muy compleja, especialmente cuando muchos objetos no heredan los permisos de los objetos primarios (ámbito único). Es difícil para los administradores determinar los permisos efectivos de un usuario específico y el modo en que el usuario obtiene el permiso en un objeto específico. SharePoint Foundation incluye un nuevo comando en la cinta de opciones llamado Comprobación de permisos y un conjunto de API de permisos efectivos que proporcionan un método rápido para enumerar todas las asignaciones de roles para un usuario específico en un ámbito específico.

La clase SPSecurableObject expone un nuevo método GetUserEffectivePermissionsInfo(). Este método recupera un objeto con información detallada acerca de los permisos efectivos que tiene un usuario específico en el ámbito actual y las asignaciones de roles relacionadas con dicho usuario en este ámbito. Si el usuario especificado pertenece a una directiva que se marca como "Account Operate as System", este método no incluye información sobre directivas de seguridad de la aplicación web. Este método está disponible para los usuarios a los que se ha concedido el permiso EnumeratePermissions. Para obtener más información acerca de EnumeratePermissions, vea la enumeración SPBasePermissions.

La clase SPSecurableObject también expone un nuevo método GetUserEffectivePermissions(). Para el ámbito actual, este método devuelve un objeto SPBasePermissions que representa la máscara de permisos efectivos del usuario.

La clase SPWeb tiene un nuevo método denominado GetWebsAndListsWithUniquePermissions() que permite a los administradores de colecciones de sitios recuperar una colección de sitios web y listas que tienen permisos exclusivos o que tienen artículos con permisos exclusivos.

El comportamiento de la API es el siguiente: desde la dirección URL de inicio, devuelve una lista de direcciones URL de los contenedores (por ejemplo, SPWeb o SPList), donde hay presente un ámbito de seguridad único (donde se produjo la interrupción de la herencia de roles), incluidos todos los contenedores que no tienen un ámbito de seguridad único pero que contienen uno o varios elementos secundarios con ámbitos de seguridad únicos.

La clase SPList tiene un nuevo método GetItemsWithUniquePermissions() que permite a los administradores de colecciones de sitios recuperar todos los elementos de lista con permisos exclusivos.

Para obtener más información sobre estas API, vea Microsoft.SharePoint.

Nota

En este tema se destacan solo algunas de las nuevas API. No se incluyen todas las nuevas API relacionadas con la seguridad que se han agregado a SharePoint Foundation.

Servicio de almacenamiento seguro

El Servicio de almacenamiento seguro reemplaza la característica de inicio de sesión único de Microsoft Office SharePoint Server 2007. El Servicio de almacenamiento seguro es un servicio que proporciona almacenamiento y asignación de credenciales, como nombres de cuenta y contraseñas. Permite almacenar de forma segura datos que proporcionan credenciales necesarias para conectarse a sistemas externos y asociar aquellas credenciales a una identidad o un grupo de identidades específicos. Es muy común que las soluciones intenten autenticarse en un sistema externo en el cual el usuario actual se conoce de forma diferente o tiene una cuenta diferente para la autenticación. En estos casos, el Servicio de almacenamiento seguro puede usarse para almacenar y asignar las credenciales de usuario que requiere el sistema externo. Puede configurar el Servicio de almacenamiento seguro de modo que varios usuarios puedan tener acceso a un sistema externo mediante un solo conjunto de credenciales en dicho sistema externo.

Para obtener más información acerca de Servicio de almacenamiento seguro, vea Servicio de almacenamiento seguro.

Vea también

Conceptos

Introducción a la seguridad y al modelo de identidad basado en notificaciones