Autenticación del servicio Conectividad a datos empresariales

Última modificación: miércoles, 28 de julio de 2010

Hace referencia a: SharePoint Server 2010

En este artículo
Modos de autenticación
Patrones de autenticación para los modos de autenticación
Autenticación en el nivel de aplicación

El Servicio de conectividad de datos profesionales (BDC) admite dos modelos de autenticación:

• Subsistema de confianza

• Suplantación y delegación

En el modelo del subsistema de confianza, el nivel intermedio (generalmente, el servidor web) autentica el servidor back-end como una identidad fija. Elija el modelo del subsistema de confianza por los siguientes motivos:

• El grupo que posee y administra el servidor back-end ofrece acceso a una cuenta que ellos administran.

• Ofrece agrupación de conexiones.

• Reduce los costos de licencia en el servidor back-end.

• Es menos complejo.

En el modelo de suplantación y delegación, el cliente delega la autenticación al nivel intermedio, que suplanta al cliente y se autentica ante el servidor back-end en su nombre. Este modelo se puede usar por los siguientes motivos:

• Para cumplir el requisito de servidor back-end en la autorización por usuario

• Para permitir la auditoría en el servidor back-end

Modos de autenticación

Los siguientes modos de autenticación están disponibles al usar BDC para conectarse a una base de datos o servicio web.

Autenticación de paso a través (sistemas de bases de datos y servicios web)

La autenticación de paso a través es la capacidad del sistema operativo para pasar la información de autenticación de un cliente al servidor back-end. BDC admite la autenticación de paso a través para las conexiones de servicio web y de base de datos. Al usar esta autenticación, se autentica como la identidad del usuario conectado.

Cuando se obtiene acceso a BDC desde una página web, este se ejecuta en el proceso de trabajo de Internet Information Services (IIS), w3wp.exe, en el servidor front-end web. La identidad de este proceso es la cuenta del grupo de aplicaciones de IIS, pero el subproceso usado para atender la solicitud suplanta al usuario conectado. Para evitar perder la identidad del usuario conectado cuando BDC autentica en el servidor back-end, debe habilitar la delegación Kerberos entre el servidor que ejecuta IIS y el otro equipo. La delegación Kerberos permite al servidor receptor enviar la solicitud de autenticación a la ubicación correcta.

Cuando BDC se usa para tareas de rastreo, se ejecuta en el proceso de demonio de filtro, mssdmn.exe. Para obtener acceso al origen de contenido back-end, los subprocesos del proceso de demonio de filtro se presentan como la cuenta de acceso al contenido asociada a ese origen de contenido back-end.

Sin embargo, al usar la autenticación de paso a través, el sistema operativo expone solo el nombre de usuario y la contraseña. Por lo tanto, si una compañía usa una autenticación de dos factores (es decir, los usuarios deben poseer cierta información específica o privada, además del nombre de usuario y la contraseña), la autenticación de paso a través no funcionará.

A pesar de estos inconvenientes, la simplicidad de su uso hace que la autenticación de paso a través sea un buen candidato en un entorno de prueba o si el servidor de destino usa la autenticación anónima.

Autenticación RevertToSelf (sistemas de bases de datos y servicios web)

Si un usuario inicia sesión con la autenticación de Windows, IIS suplanta esa cuenta concreta, de manera que mientras IIS se ejecuta bajo la identidad de grupo de aplicaciones, suplanta al usuario conectado y la solicitud se ejecuta bajo la suplantación del usuario antes de avanzar.

La autenticación RevertToSelf permite revertir esta suplantación y autenticarse como la cuenta subyacente que está configurada para el grupo de aplicaciones de IIS.

Precaución
Si el código personalizado usa el método RevertToSelf para la autenticación, puede conceder a los usuarios privilegios de nivel de sistema en los servidores back-end si concede privilegios a la identidad del grupo de aplicaciones. Por lo tanto, no debe ejecutar código personalizado en un sistema de producción hasta que se haya probado meticulosamente.

WindowsCredentials (sistemas de bases de datos y servicios web)

Microsoft SharePoint Server 2010 realiza la autenticación con las credenciales de Windows obtenidas del Servicio de almacenamiento seguro predeterminado.

RdbCredentials (sólo sistemas de bases de datos)

En el modo RdbCredentials, SharePoint Server 2010 realiza la autenticación con las credenciales de base de datos del Servicio de almacenamiento seguro predeterminado. SharePoint Server agrega estas credenciales de base de datos a la cadena de conexión y las transmite al servidor de la base de datos.

Credentials (sólo sistemas de servicios web)

SharePoint Server 2010 realiza la autenticación de los sistemas de servicio web con credenciales distintas a las de la autenticación de Windows del Servicio de almacenamiento seguro predeterminado. Estas credenciales se usan para la autenticación básica o implícita, según cuál sea la configuración del servidor de servicios web. Debido a que la autenticación básica e implícita no protege adecuadamente las credenciales, se debe usar la Capa de sockets seguros (SSL), el protocolo de seguridad de Internet (IPsec) o ambos para ayudar a proteger la comunicación entre el servidor de servicios web y el servidor que ejecuta BDC.

DigestCredentials (solo sistemas de servicios web de WCF)

Con el modo de autenticación DigestCredentials, SharePoint Server 2010 usa el Servicio de almacenamiento seguro predeterminado para asignar las credenciales del usuario a credenciales distintas de las usadas para la autenticación de Windows. Las credenciales asignadas se usan para la autenticación implícita. Puesto que la autenticación implícita no protege adecuadamente las credenciales, se debe usar la Capa de sockets seguros (SSL), el protocolo de seguridad de Internet (IPsec) o ambos para ayudar a proteger la comunicación entre el servidor de servicios web de WCF y el servidor que ejecuta BDC.

Resumen

La tabla 1 contiene un resumen de cuándo se debe usar cada uno de los modos de autenticación y proporciona vínculos a los ejemplos actualmente disponibles en el SDK de SharePoint 2010.

Patrones de autenticación para los modos de autenticación

La siguiente tabla muestra el patrón de autenticación que sigue cada modo de autenticación.

Autenticación en el nivel de aplicación

BDC también admite una autenticación en el nivel de aplicación secundaria, que se usa junto con la autenticación primaria configurada para el sistema. Es particularmente útil en situaciones en las que una aplicación back-end necesita que las credenciales de seguridad se pasen en las llamadas a métodos para autorizar a los usuarios.

Puede habilitar la autenticación en el nivel de aplicación mediante la definición de filtros en el modelo BDC, particularmente filtros de nombre de usuario, contraseña, SSOTicket y UserContext. Para obtener más información acerca de estos filtros, vea Tipos de filtros compatibles con el Servicio de conectividad a datos empresariales.

A continuación se muestra cómo habilitar la autenticación en el nivel de aplicación mediante la adición de filtros de nombre de usuario y contraseña al modelo BDC.

Para habilitar la autenticación en el nivel de aplicación

1. En la propiedad SecondarySsoApplicationId de LobSystemInstance, especifique la aplicación de almacenamiento seguro que contiene las credenciales.

2. Defina UsernameCredentialFilter y PasswordCredentialFilter, y asocie cada uno con un parámetro de entrada.