OAuth y el usuario rehidratado en SharePoint 2013: funcionamiento y puntos clave

Artículo original publicado el jueves, 16 de agosto de 2012

Antes que nada, me gustaría decir que una de las cosas que más me gusta de escribir blogs sobre los misterios de SharePoint sin pensar es el hecho de que puedo usar un lenguaje completamente coloquial, como el del título del blog: algo que es casi imposible a menos que, digamos, seas el creador de una nueva versión de SharePoint. ¿Alguien ha visto los mensajes tan divertidos de SharePoint 2013 para acercarse al usuario? “Perdón por la espera, ya casi he acabado” y cosas por el estilo. Me parece muy gracioso, porque se entremezcla con cosas como el HRESULT que le salió a mi amigo Tom el otro día. Mmm… cuantas más cosas cambian, más hay que no lo hacen.

Pero volvamos al tema principal. Ya me mencionado OAuth un par de veces en este blog para hablar sobre las características nuevas de SharePoint 2013. Pero, aunque no entraré a explicar qué es OAuth porque tenemos un equipo entero de redactores dedicados a esa tarea, quisiera expandirme un poco en describir algunas de las maneras en que se usa. El mejor ejemplo de una confianza OAuth es, probablemente, el de la búsqueda de un índice de SharePoint remoto. Con esto, se permite que una persona de una granja de servidores emita una consulta que se enruta a otra granja de SharePoint; en esa granja de servidores de SharePoint remoto, se puede reconstruir la identidad del usuario para que los resultados de la búsqueda se restrinjan con las medidas de seguridad adecuadas. También se utiliza en otros escenarios como el nuevo modelo de aplicación (es decir, si el usuario tiene derechos de acceso al contenido que la aplicación solicita) o entre aplicaciones de servidor como SharePoint y Exchange (si el usuario tiene derechos de acceso al contenido del buzón), entre otros. Creo que el índice de SharePoint remoto es un buen ejemplo, ya que puede que sea el mejor escenario para pensar en por qué necesitamos hacer lo que hacemos y que, de este modo, todo salga según lo previsto.

Empecemos por el principio: ¿cómo podría FarmA (granja de servidores A) “hacer un Steve” que parezca el “Steve” de FarmB (granja de servidores B)? Todo comienza con la aplicación de perfil de usuario. Supongamos que Steve está en FarmB y emite una consulta. Esa consulta se envía a FarmA junto con algunos atributos de Steve. De manera predeterminada, dichos atributos son la dirección SMTP, la dirección SIP, el nombre de cuenta y el identificador de nombre de Steve. Cuando FarmA recibe la consulta, lo primero que hará será realizar una búsqueda en su aplicación de perfil de usuario local para encontrar un perfil que coincida con los valores que se enviaron sobre Steve. Por eso es tan importante que se asegure de que su aplicación de perfil de usuario esté completa y en buen estado en SharePoint 2013. Precisamente para explicar ese procedimiento escribí este artículo de blog: https://blogs.msdn.com/b/sharepoint_sp/archive/2012/09/20/asignaci-243-n-de-perfiles-de-usuario-a-usuarios-de-saml-con-una-importaci-243-n-de-active-directory-en-sharepoint-2013.aspx.

Bien, ahora que FarmA ha encontrado el perfil de usuario de Steve, ¿qué puede hacer con él? La respuesta a esto sería “depende”, y por eso es tan importante que se planee este aspecto en la organización. De lo que depende es del tipo de autenticación que se utilice:

• Notificaciones de Windows: si está usando las notificaciones de Windows, todo lo que necesita en la mayor parte del proceso lo encontrará en el perfil de usuario. Contiene su nombre de cuenta y sus pertenencias a grupos de Active Directory. En un momento explicaré lo que quiero decir con "en la mayor parte". La versión corta es que si está usando las notificaciones de Windows, mucho mejor.
• Notificaciones de Autenticación basada en formularios: si está usando la Autenticación basada en formularios (FBA, por sus siglas en inglés), hay un par de cosas que debe saber. La primera es que tiene que completar su aplicación de perfil de usuario y mantenerla actualizada. Si resulta que está usando la Autenticación basada en formularios con el proveedor LDAP y su directorio es Windows Active Directory, está en una situación bastante buena. Puede crear una conexión de perfil a Active Directory y simplemente asociarla con el proveedor de FBA de un modo similar al descrito en la publicación cuyo vínculo he incluido anteriormente. Sin embargo, en la mayoría de los casos, Active Directory no será su proveedor, por lo que tendrá que escribir código personalizado para llenar la aplicación de perfil de usuario. Esto debería bastar para conseguir el único atributo que realmente nos interesa para los usuarios de FBA: el nombre de cuenta. Pero, como sabe, "en la mayor parte" de las veces (que explicaré en breve), el resto de los datos provienen de su proveedor de funciones. Lo mejor de todo esto es que cuando rehidratamos un usuario de FBA, también invocamos al proveedor de funciones asociado, así que es como si el usuario de FBA hubiera iniciado sesión localmente. Esto le permite seleccionar todas las notificaciones de funciones para un usuario de FBA.
• Notificaciones de SAML: esto es parecido a la Autenticación basada en formularios en el sentido de que lo primero que debe hacer es completar su aplicación de perfil de usuario. Con un poco de suerte, los usuarios estarán en Active Directory y solo tendrá que importarlos directamente siguiendo la guía de la entrada de blog indicada antes. En caso contrario, tendrá que encontrar otra manera de conectar con un directorio de origen y realizar la importación desde allí. Esto es probablemente lo más complicado de las notificaciones de SAML, ya que puede que tenga directorios múltiples, y puede que ni siquiera sea propietario de todos ellos (es posible que tenga asociados, que tenga una federación con ACS y esté usando Facebook u otro proveedor, etc.). Sea como sea, si quiere que todo esto funcione, deberá encontrar el modo de completar su aplicación de perfil de usuario. Existe, no obstante, un segundo aspecto que cabe destacar: cuando inicia sesión como usuario de SAML, obtiene un conjunto de notificaciones emitidas por su proveedor de identidades (IdP). Este proceso de rehidratación de usuario no puede simular ese inicio de sesión de ninguna manera. Sí, esa es la naturaleza de SAML: es posible que se le redireccione muchas veces y que proporcione una cantidad de tipos y solicitudes de autenticación (como una autenticación de dos factores) de los que no podríamos dar cuenta. ¿Qué cree que significa esto? Que es preciso que agregue sus notificaciones mediante el aumento de notificaciones si desea usarlas para asegurar su contenido y permitir el acceso al mismo mediante este proceso de rehidratación del usuario. Durante la rehidratación del proveedor de identidades no tendrá notificaciones, así que si las quiere concédalas localmente. Ahora viene el “en la mayor parte” que comentaba anteriormente, y que explicaré en seguida.
• “En la mayor parte”, ¿qué quiere decir? Afortunadamente, ahora ya se ve bastante claro: sea un usuario de Windows, de FBA o de SAML, además de las notificaciones que obtiene de su proveedor de autenticación, también puede obtener notificaciones adicionales agregadas mediante el aumento: https://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx. Lo que también hacemos durante el proceso de rehidratación es invocar todos los proveedores de notificaciones personalizados que se hayan registrado, de modo que podamos seleccionar notificaciones adicionales para el usuario rehidratado que habrían recibido si hubiesen iniciado sesión localmente y hubiesen invocado a esos proveedores.

Por eso me gusta tanto el escenario del índice de SharePoint remoto para explicar la planificación que se necesita. Como podrá imaginar, en una granja de servidores puede conceder derechos de acceso a contenido basado en un grupo de Windows, un rol de FBA, una notificación de SAML o cualquier otra notificación agregada mediante aumento. Si no posee estas notificaciones cuando busque contenido, no podrá verlo porque estará protegido por el recorte de seguridad. Y aquí radica la importancia de todo eso, ya que las notificaciones que se le conceden cuando inicia sesión localmente también las obtiene cuando rehidratamos una versión de usted.

Hay muchas cosas que planificar a la hora de realizar todo esto, así que esperamos que el artículo le haya servido de ayuda para identificar los principales elementos móviles y saber en qué centrarse.

Esta entrada de blog es una traducción. Puede consultar el artículo original en OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That and What do I Need to Know