Autenticación remota en SharePoint Online mediante la autenticación basada en notificaciones
Resumen: obtenga información sobre cómo autenticar en Microsoft SharePoint Online en aplicaciones cliente mediante los modelos de objetos de cliente de SharePoint.
Última modificación: miércoles, 22 de abril de 2015
Hace referencia a: Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio
En este artículo
Introducción a la autenticación remota en SharePoint Online mediante la autenticación basada en notificaciones
Breve introducción a la autenticación de SharePoint
Evolución de la autenticación basada en notificaciones
Secuencia de autenticación de notificaciones de SharePoint
Uso del modelo de objetos de cliente para la autenticación remota en SharePoint Online
Revisión del proyecto de código de ejemplo de la autenticación remota de SharePoint Online
Conclusión
Acerca del autor
Recursos adicionales
**Se aplica a:**SharePoint Online
**Proporcionado por:**Robert Bogue, Thor Projects, LLC (MVP de Microsoft SharePoint)
Contenido
Introducción a la autenticación remota en SharePoint Online mediante la autenticación basada en notificaciones
Breve introducción a la autenticación de SharePoint
Evolución de la autenticación basada en notificaciones
Secuencia de autenticación de notificaciones de SharePoint
Uso del modelo de objetos de cliente para la autenticación remota en SharePoint Online
Revisión del proyecto de código de ejemplo de la autenticación remota de SharePoint Online
Conclusión
Recursos adicionales
Acerca del autor
.jpg "Hacer clic para obtener el código")
Introducción a la autenticación remota en SharePoint Online mediante la autenticación basada en notificaciones
La decisión de confiar en servicios basados en la nube, como Microsoft SharePoint Online, no se ha tomado a la ligera y suele verse obstaculizada por el problema del acceso a los datos de la organización por necesidades internas. En este artículo, se abordará este importante problema; para ello, se proporcionará un marco y código de ejemplo para crear aplicaciones cliente que puedan autenticar usuarios de forma remota en SharePoint Online mediante el modelo de objetos de cliente de SharePoint 2010.
Nota
Si bien este artículo se centra en SharePoint Online, las técnicas descritas pueden aplicarse a cualquier entorno en el que el servidor de SharePoint 2010 remoto use la autenticación basada en notificaciones.
Se revisarán los métodos de autenticación de SharePoint 2010, se proporcionarán detalles sobre algunas operaciones de SharePoint 2010 con la autenticación en el modo de notificaciones y se describirá un método para desarrollar un conjunto de herramientas para habilitar la autenticación remota en el servidor para su uso con el modelo de objetos de cliente.
Breve introducción a la autenticación de SharePoint
En Office SharePoint Server 2007, eran dos los tipos de autenticación: la autenticación de Windows, mediante la cual se transmitía la información de autenticación a través de encabezados HTTP, y la autenticación basada en formularios. La autenticación basada en formularios usaba los motores de roles y pertenencia de Microsoft ASP.NET para administrar usuarios y roles (o grupos). Esto implicó una gran mejora en la autenticación en la versión de 2003 de las tecnologías de SharePoint, que se basaban exclusivamente en la autenticación de Windows. No obstante, todavía resultaba difícil lograr varios escenarios, como el inicio de sesión federado y el inicio de sesión único.
Para demostrar las limitaciones que implica basarse únicamente en la autenticación de Windows, piense en un entorno que solo use la autenticación de Windows. En este entorno, se piden las credenciales a los usuarios cuyos equipos no están conectados al dominio, o cuyas configuraciones no se han establecido para transmitir las credenciales automáticamente, para cada aplicación web a la que tienen acceso y en cada programa desde el que tienen acceso a la aplicación. Por ejemplo, si en intranet.contoso.com hay una intranet basada en SharePoint, y Mis sitios se encuentran en my.contoso.com, se pedirán las credenciales a los usuarios dos veces. Si abren un documento de Microsoft Word desde cada sitio, se les piden las credenciales dos veces más, y otras dos veces para Microsoft Excel. Es evidente que esta no es una buena experiencia del usuario.
Sin embargo, si la misma red usa la autenticación basada en formularios, una vez que los usuarios han iniciado sesión en SharePoint, ya no se les pide autenticación en otras aplicaciones como Word y Excel. Pero sí se les pide en cada una de las dos aplicaciones web.
Había sistemas de inicio de sesión federados, como Windows Live ID, pero era difícil integrarlos en Office SharePoint Server 2007. Fundamentalmente, el mecanismo basado en formularios estaba diseñado para autenticar usuarios locales, es decir, no estaba diseñado para autenticar la identidad basada en un sistema federado. SharePoint 2010 solucionó este problema mediante la adición de compatibilidad directa con la autenticación basada en notificaciones. Esto permite que SharePoint 2010 se base en un tercero para autenticar al usuario y para proporcionar información sobre los roles de dicho usuario.
Evolución de la autenticación basada en notificaciones
Dado que los equipos están diseñados para dar cabida a varios usuarios, la autorización siempre ha sido un desafío. En un principio, el sistema operativo validaba al usuario. A continuación, indicaba a la aplicación de qué usuario se trataba. Esta era la primera notificación que realizaba el sistema operativo a la aplicación. La esencia de esta notificación era la identidad del usuario. El sistema operativo había determinado quién era el usuario, probablemente mediante una contraseña que este proporcionaba. La aplicación no tenía que determinar de qué usuario se trataba; simplemente confiaba en el sistema operativo.
Este proceso de autenticación funcionaba muy bien hasta que los usuarios se vieron en la necesidad de usar aplicaciones en sistemas donde no habían iniciado sesión. En ese momento, la aplicación debía realizar su propia autenticación. Las aplicaciones comenzaron con el mismo método que habían usado los sistemas operativos, es decir, solicitar el nombre y la contraseña del usuario. La autenticación funcionaba correctamente de este modo, pero requería que cada aplicación validara el nombre de usuario y la contraseña. Mantener varias bases de datos de autenticación independientes se convirtió en un problema, ya que los usuarios deseaban usar los mismos nombres de usuario y contraseñas en todas las aplicaciones.
La creación de cuentas con el mismo nombre de usuario y la misma contraseña es un problema que se puede manejar. No obstante, a medida que crecía la preocupación por la seguridad, se requería a los usuarios cambiar sus contraseñas de forma periódica, lo que creó una situación difícil de controlar, ya que les resultaba complicado mantener sus contraseñas sincronizadas entre aplicaciones diferentes. Para solucionar este problema se desarrollaron mecanismos de autenticación compartida. Una vez más, una aplicación podía basarse en un tercero para autenticar al usuario.
El enfoque más popular para una base de datos de autenticación compartida es uno que use el protocolo Kerberos. El protocolo Kerberos proporciona mecanismos que permiten a un usuario autenticarse en un servidor centralizado y, a continuación, transmitir su identidad a través de un vale firmado por ese servidor. La ventaja de este enfoque es que el servidor centralizado es el único que debe conocer la contraseña del usuario u otra información de identificación. Esto funciona muy bien para proporcionar la información de autenticación, pero se basa en un almacén único para las identidades de usuario.
Actualmente, algunos usuarios de la aplicación usan identidades que no se pueden controlar. Considere el caso de una organización que ofrece servicios de nómina o planes de jubilación a otras compañías. Es posible que estas organizaciones necesiten aceptar usuarios que pertenezcan a una gran cantidad de compañías diferentes y no requieran la autenticación individual de cada uno de ellos. Lo único que necesitan saber es que la organización con la que tienen un contrato puede identificar al usuario. En estos casos, el servidor centralizado para la autenticación no existe; no hay una entidad centralizada que pueda validar a cada usuario.
Del mismo modo, si tiene un sitio web de extranet diseñado para trabajar con varios asociados, puede que no desee administrar cuentas de usuario para todos los empleados de los asociados ni dejar que los asociados las administren. En su lugar, solo prefiere tomar la notificación del servidor remoto de la identidad del usuario.
Esta es una de las excelentes características de un inicio de sesión basado en notificaciones. Otro sistema, en el que su sistema confía, proporciona una notificación de la identidad del usuario.
Existen varios estándares, como WS-Federation, WS-Security y WS-Trust, que definen cómo debe funcionar este tipo de disposición. WS-Federation es el más relevante debido a que describe un método específico para el intercambio de autenticación federada. SharePoint 2010, al igual que muchos otros productos de Microsoft y que no son de Microsoft, implementa el estándar WS-Federation. Esto significa que la implementación de notificaciones de SharePoint puede comunicarse con una gran cantidad de sistemas adicionales.
Además de la información de autenticación descrita anteriormente, existe una funcionalidad que permite a la infraestructura realizar otras notificaciones sobre el usuario, incluidas las propiedades de perfil como el nombre y la dirección de correo electrónico. La notificación también puede incluir los roles, o grupos, a los que pertenece un usuario. Esto permite a las aplicaciones, incluida SharePoint 2010, usar la información del usuario en la que confía el proveedor de notificaciones (conocido como parte emisora). Posteriormente, las aplicaciones pueden establecer la autorización para realizar alguna acción en los roles transmitidos en el token de notificaciones.
Para que una notificación pueda transmitir más que la mera identidad, es preciso poder aplicar reglas sobre los tipos de notificaciones que una aplicación aceptará de un tercero. El estándar WS-Trust respalda la idea de que una parte puede basarse en otra, como se describió anteriormente. Además, también contempla la posibilidad de una cadena de confianza, donde la aplicación, como SharePoint 2010, confía en un proveedor interno como Servicios de federación de Active Directory (ADFS) 2.0, que a su vez confía en otra parte o en varias partes adicionales. ADFS 2.0 crea su propio token de notificaciones para SharePoint, en función de la información que recibió de la parte emisora en la que confía. Esto es especialmente útil porque ADFS 2.0 es un motor de transformación de notificaciones, es decir, puede transformar una notificación, como una propiedad, en otra notificación, como la pertenencia a roles. ADFS 2.0 también puede filtrar las notificaciones realizadas por un tercero, de modo que el tercero no pueda pasar una notificación a la aplicación de la cual el usuario es administrador.
Secuencia de autenticación de notificaciones de SharePoint
Ahora que ya conoce las ventajas de la autenticación basada en notificaciones, podemos examinar lo que realmente sucede al trabajar con la seguridad basada en notificaciones en SharePoint. Al usar la autenticación clásica, SharePoint emite un código de estado HTTP 401 al cliente que indica los tipos de autenticación HTTP que admite el servidor. No obstante, en el modo de notificaciones se lleva a cabo una interacción más compleja. A continuación se proporciona una explicación detallada de la secuencia que realiza SharePoint cuando está configurado tanto para la autenticación de Windows como para Windows Live ID mediante notificaciones.
El usuario selecciona un vínculo en el sitio protegido y el cliente transmite la solicitud.
El servidor responde con un código de estado HTTP 302 que indica un redireccionamiento temporal. La página de destino es /_layouts/authenticate.aspx, con un parámetro de cadena de consulta Source que contiene la dirección URL de origen relativa al servidor que solicitó el usuario inicialmente.
El cliente solicita /_layouts/authenticate.aspx.
El servidor responde con un redireccionamiento temporal 302 a /_login/default.aspx con un parámetro de cadena de consulta ReturnUrl que incluye la página de autenticación y su cadena de consulta.
El cliente solicita la página /_login/default.aspx.
El servidor responde con una página que pide al usuario que seleccione el método de autenticación. Esto se debe a que el servidor está configurado para aceptar notificaciones de varios servicios de token de seguridad (STS), incluido el STS de SharePoint integrado y el STS de Windows Live ID.
El usuario selecciona el proveedor de inicio de sesión apropiado en la lista desplegable y el cliente publica la respuesta en /_login/default.aspx.
El servidor responde con un redireccionamiento temporal 302 a /_trust/default.aspx con un parámetro de cadena de consulta trust con el proveedor de confianza que seleccionó el usuario, un parámetro ReturnUrl que incluye la página authenticate.aspx y un parámetro de cadena de consulta adicional con el origen nuevamente. El origen sigue formando parte del parámetro ReturnUrl.
El cliente sigue el redireccionamiento y obtiene /_trust/default.aspx.
El servidor responde con un redireccionamiento temporal 302 a la dirección URL del proveedor de identidad. En el caso de Windows Live ID, la dirección URL es https://login.live.com/login.srf con una serie de parámetros que identifican el sitio como Windows Live ID y un parámetro wctx que coincide con la cadena de consulta ReturnUrl proporcionada anteriormente.
El cliente y el servidor iteran un intercambio de información (basado en la operación de Windows Live ID y posteriormente en el usuario) que da como resultado un elemento para exponer en /_trust/default.aspx, que se configuró en Windows Live ID. Este elemento para exponer incluye un token del lenguaje de marcado de aserción de seguridad (SAML) que incluye la identidad del usuario y la firma de Windows Live ID que especifica que el identificador es correcto.
El servidor responde con un redireccionamiento a /_layouts/authenticate.aspx, que se proporcionó inicialmente con la dirección URL de redireccionamiento en el parámetro de cadena de consulta ReturnUrl. Este valor se devuelve desde el proveedor de notificaciones como wctx con el formato de una variable de envío de formulario. Durante el redireccionamiento, la página /_trust/default.aspx escribe dos o más cookies de autenticación cifradas y codificadas que se retransmiten en cada solicitud al sitio web. Estas cookies están compuestas de una o varias cookies FedAuth y de una cookie rtFA. Las cookies FedAuth habilitan la autorización federada y la cookie rtFA habilita el cierre de sesión del usuario en todos los sitios de SharePoint, incluso si el proceso de cierre de sesión comienza en un sitio que no es de SharePoint.
El cliente solicita /_layouts/authenticate.aspx con un parámetro de cadena de consulta de la dirección URL de origen.
El servidor responde con un redireccionamiento temporal 302 a la dirección URL de origen.
Nota
Si solo hay un mecanismo de autenticación para la zona en la que el usuario obtiene acceso a la aplicación web, no se pide al usuario que seleccione la autenticación que desea usar (vea el paso 6). En su lugar, /_login/default.aspx redirige al usuario inmediatamente al proveedor de autenticación correspondiente (en este caso, Windows Live ID).
Cookies de autenticación de SharePoint Online
Un aspecto importante de este proceso, que dificulta pero no imposibilita el uso de la autenticación remota en SharePoint Online en aplicaciones cliente, es que las cookies FedAuth se escriben con una marca HTTPOnly. Esta marca está diseñada para evitar los ataques de scripts de sitios (XSS). En un ataque XSS, un usuario malintencionado inserta scripts en una página que transmiten o usan las cookies disponibles en la página actual con fines nefarios. La marca HTTPOnly de la cookie impide que Internet Explorer permita el acceso a la cookie desde scripts de cliente. Microsoft .NET Framework también respeta la marca HTTPOnly, lo que impide que se recupere la cookie directamente desde el modelo de objetos de .NET Framework.
Nota
En SharePoint Online, las cookies FedAuth se escriben con una marca HTTPOnly. Sin embargo, en instalaciones de SharePoint 2010 locales, un administrador puede modificar el archivo web.config para representar las cookies normales sin esta marca.
Uso del modelo de objetos de cliente para la autenticación remota en SharePoint Online
El punto de partida para usar el modelo de objetos de cliente de SharePoint para la autenticación remota consiste en obtener un objeto ClientContext. Este objeto de contexto de cliente es el que relaciona las otras operaciones del modelo de objetos con el servidor y el sitio especificado. En un escenario de autenticación HTTP basada en Windows, el contexto de cliente se comporta del mismo modo que Internet Explorer: transmite automáticamente las credenciales al servidor si el servidor se encuentra en la zona de intranet. En la mayoría de los casos, esto funciona muy bien. El servidor procesa las credenciales y autentica al usuario automáticamente.
En un entorno de autenticación basada en formularios, también se puede usar el objeto FormsAuthenticationLoginInfo para proporcionar autenticación basada en formularios al servidor. Sin embargo, esto solo funciona para la autenticación basada en formularios. No funciona para escenarios de notificaciones basadas en federación debido a que el proceso de autenticación real no pertenece a SharePoint.
La creación de un objeto ClientContext autenticado es un proceso de varios pasos. Ante todo, el usuario debe poder iniciar sesión en el sistema remoto de forma interactiva. En primer lugar, el usuario inicia sesión en SharePoint mediante el proveedor de autenticación federada y SharePoint debe emitir sus cookies de autenticación. En segundo lugar, el código debe recuperar las cookies de autenticación. En tercer lugar, dichas cookies deben agregarse al objeto ClientContext.
Habilitación del inicio de sesión del usuario para la autenticación remota
.NET Framework incluye un objeto System.Windows.Forms.WebBrowser diseñado para habilitar el uso de un explorador web dentro de una aplicación. Para habilitar el inicio de sesión del usuario en el proveedor de autenticación federada, debe crearse y mostrarse este objeto. El objetivo, no obstante, es recuperar las cookies de autenticación emitidas por SharePoint Online. Para determinar cuándo se ha completado el proceso de inicio de sesión, debe registrar un controlador en el evento Navigated. Este evento se desencadena una vez que el explorador ha completado la navegación. Este controlador de eventos espera a que se envíe el usuario de vuelta a la dirección URL desde la que comenzó a navegar. Cuando esto ocurre, el código sabe que el usuario ha completado la secuencia de inicio de sesión.
Captura de las cookies de autenticación de SharePoint
Dado que las cookies FedAuth se escriben con una marca HTTPOnly, no se puede obtener acceso a ella desde .NET Framework. Para recuperarlas, debe realizarse una llamada a WININET.dll. .NET Framework puede llamar a los métodos DLL basados en COM a través de PInvoke (invocación de plataforma). En este caso, el método que debe llamarse es InternetGetCookieEx, que puede devolver cookies normales y cookies con la marca HTTPOnly. No obstante, este método solo funciona si se comienza con Internet Explorer 8. Una vez recuperada la cookie, se debe agregar al contexto de cliente.
Para obtener más información acerca de PInvoke, vea Llamar a funciones nativas desde código administrado.
Adición de las cookies de autenticación de SharePoint al objeto ClientContext
El último paso consiste en recuperar las cookies de autenticación desde el inicio de sesión del usuario y adjuntarlas al contexto de cliente. Desafortunadamente, no existe un modo directo de agregar las cookies a la solicitud. Sin embargo, hay un evento, ExecutingWebRequest, que se llama antes de que el objeto ClientContext realice una solicitud al servidor. Mediante la adición de un controlador de eventos a este evento, puede agregar un nuevo encabezado de solicitud con las cookies de autenticación. Una vez hecho esto, el objeto ClientContext puede usarse normalmente y el resto del código ignora completamente que la autenticación se basa en una autenticación federada.
Revisión del proyecto de código de ejemplo de la autenticación remota de SharePoint Online
En el ejemplo de código que acompaña a este artículo se demuestra la técnica para agregar las cookies de autenticación de SharePoint al objeto ClientContext. Se proporciona un conjunto de clases que pueden usarse para llevar a cabo la autenticación de usuario federada. Puede comenzar con el programa de ejemplo para ver los cambios que necesita efectuar al usar este código en comparación con los que deben realizarse al usar un servidor web con autenticación HTTP.
Aplicación cliente de ejemplo de autenticación de SharePoint Sp_Ctx
El proyecto Sp_Ctx es un programa de línea de comandos que usa un objeto ClientContext de SharePoint para recuperar información acerca de la Web que señala el contexto.
Nota
Cuando se usa el ejemplo Sp_Ctx, debe especificar la dirección URL web como una solicitud https. Especificar la dirección URL web como una solicitud http dará como resultado una excepción.
El proyecto hace referencia a la biblioteca ClaimsAuth pero, aparte de eso, es igual. De hecho, el aspecto del código principal es prácticamente idéntico al que puede encontrarse en una aplicación cliente estándar.
01: static void Main(string[] args)
02: {
03: if (args.Length < 1) { Console.WriteLine("SP_Ctx <url>"); return; }
04: string targetSite = args[0];
05: using (ClientContext ctx = ClaimClientContext.GetAuthenticatedContext(targetSite))
06: {
07: if (ctx != null)
08: {
09: ctx.Load(ctx.Web); // Query for Web
10: ctx.ExecuteQuery(); // Execute
11: Console.WriteLine(ctx.Web.Title);
12: }
13: }
14: Console.ReadLine();
15: }
En este código, la única diferencia con el código de una aplicación cliente estándar se encuentra en la línea 05. En lugar de crear un nuevo ClientContext, se realiza una llamada a ClaimClientContext.GetAuthenticatedContext. La gran diferencia es que al llamar a ClaimClientContext.GetAuthenticatedContext se muestra un formulario que permite al usuario suministrar sus credenciales al sistema remoto, se capturan las cookies de autenticación necesarias para autenticar las solicitudes y se agrega ese encabezado al contexto de cliente.
ClaimClientContext en el ejemplo de autenticación de SharePoint Online
Examine el siguiente nivel del código y observe el objeto ClaimClientContext al que se llamaba. Este objeto expone dos métodos: el que se usa en el ejemplo, GetAuthenticatedContext, y GetAuthenticatedCookie. GetAuthenticatedContext llama a GetAuthenticatedCookie. De hecho, GetAuthenticatedContext llama a GetAuthenticatedCookie para obtener las cookies y las encapsula en un contexto.
GetAuthenticatedCookie abre el cuadro de diálogo que muestra el sitio web y espera a que se complete la solicitud de autenticación para que se puedan recuperar las cookies de autenticación.
ClaimsWebAuth en el ejemplo de autenticación de SharePoint Online
La clase ClaimsWebAuth obtiene las cookies de autenticación. Encapsula un formulario y un objeto WebBrowser. El primer paso, que se lleva a cabo durante la construcción del objeto, consiste en recopilar las páginas de inicio de sesión y de navegación final. Esto se realiza mediante el método GetClaimParams, que efectúa una solicitud web con un método HTTP OPTIONS.
Al llamar al método Show, se crea el objeto WebBrowser y se agrega un controlador de eventos para el evento Navigated. Este evento se llama cada vez que el objeto WebBrowser finaliza la navegación. El controlador de eventos detecta cuándo el explorador web ha alcanzado la dirección URL final de navegación. El receptor de eventos realiza una llamada a CookieReader, que a su vez lee WinINET para obtener la cookie FedAuth HTTPOnly.
Con el receptor de eventos en su lugar, WebBrowser navega a la dirección URL de inicio de sesión y se lleva a cabo el proceso de autenticación. Una vez completado el proceso, las cookies de autenticación se devuelven al llamador.
CookieReader en el ejemplo de autenticación de SharePoint Online
La última pieza del código de ejemplo es la clase CookieReader, que contiene la llamada a WinINET.dll y una función auxiliar para obtener la cookie. La función auxiliar, denominada GetFedAuthCookie, devuelve una cadena que representa la cookie con el formato "Nombre=Valor". GetFedAuthCookie llama a InternetGetCookieEx del método WinINET.dll para capturar la cookie.
InternetGetCookieEx devuelve false si el tamaño del búfer de cadena que se pasa no es lo suficientemente grande. También establece el parámetro de tamaño en el tamaño de búfer que necesita. Como consecuencia, es posible que GetFedAuthCookie deba llamar a InternetGetCookieEx dos veces para obtener el valor de la cookie, si el búfer inicial es demasiado pequeño.
Conclusión
En este artículo se describe cómo llevar a cabo la autenticación basada en notificaciones para Microsoft SharePoint Online en aplicaciones cliente mediante los modelos de objetos de cliente de SharePoint 2010. SharePoint Online proporciona una opción atractiva y flexible para las compañías que deseen usar la eficaz plataforma de colaboración de SharePoint, sin los costos operativos que implica el hospedaje local de software. Además, con las técnicas descritas en este artículo, los desarrolladores pueden usar los modelos de objetos de cliente de SharePoint para crear aplicaciones cliente capaces de autenticar de forma remota en SharePoint Online.
Acerca del autor
Robert Bogue ha participado en el programa Microsoft MVP durante 8 años. Recientemente ha publicado el libro The SharePoint Shepherd’s Guide for End Users (La Biblia sobre SharePoint para usuarios finales), del que podrá encontrar más información en http://www.SharePointShepherd.com. Robert también escribe en su blog http://www.thorprojects.com/blog. Para ponerse en contacto con Robert, escriba a Rob.Bogue@thorprojects.com.
Recursos adicionales
Para obtener más información sobre la autenticación remota en SharePoint Online mediante la autenticación basada en notificaciones, vea los siguientes recursos: