sharepoint - ¿Cómo realizo la suplantación WIF/reclamos sin que el reclamo se asigne a una cuenta AD?

claims-based-identity windows-identity

Question

Necesito realizar una suplantación de búsqueda en SharePoint 2010 para usuarios de Reclamos. Para poner esto en contexto, me gustaría primero exponer cómo hago esto para trabajar con las cuentas de Windows y luego discutir Reclamos / WIF.

Cuentas de Windows

Puedo hacer esto para usuarios "clásicos" de Windows Integrated Authenticated que usan:

WindowsImpersonationContext wic = null;
try
{  
    WindowsIdentity impersonatedUser = new WindowsIdentity("john.doe@mydomain");
    wic = impersonatedUser.Impersonate();

    // do impersonated work here...
    // in my case this is a SharePoint KeywordQuery
}
finally
{
    if (wic != null)
    {
        wic.Undo();
    }
}

Para que funcione lo anterior, la cuenta suplantada debe estar en el mismo dominio que el usuario actual y debo asegurarme de que el propietario del grupo de aplicaciones sea:

• Una cuenta de dominio en un dominio que tiene un "nivel funcional de dominio" de Windows 2003 o superior
• Tiene el privilegio de "actuar como parte del sistema operativo" en el recuadro local
• Tiene el privilegio de "suplantar a un cliente después de la autenticación" en el recuadro local

(Nota: si alguien puede encontrar la manera de evitar el problema de que la cuenta actual debe estar en el mismo dominio que la cuenta suplantada, soy todo oídos).

Cuentas de reclamaciones

Me gustaría hacer lo mismo con las cuentas de reclamaciones / WIF. Estas cuentas no están necesariamente asociadas con cuentas AD (tengo que asumir que no).

¿Hay alguna forma de decirle al STS que quiero suplantar a una cuenta en particular y que me dé el token apropiado para esa cuenta? No tendré la contraseña del usuario al que me estoy haciendo pasar.

Citando SharePoint Brew Tengo que lidiar con mi código que se ejecuta en una interfaz web de SharePoint (WFE) que llama a un procesador de consultas a través de una llamada WCF. Quiero que la llamada WCF esté en el contexto del usuario suplantado.

El elemento web de búsqueda de WFE (Servidor1) se comunica con el proxy de la aplicación de servicio. El proxy de la aplicación del servicio de búsqueda asociado llama al STS local para obtener un token SAML para el usuario. Una vez que se recoge el token SAML, el proxy de la aplicación del servicio de búsqueda llama a un servidor que ejecuta el procesador de consultas a través de una llamada WCF. Llamaré a este servidor, "Servidor 2". El servidor 2 recibe la solicitud entrante y valida el token SAML contra su STS local. Una vez validado, el Servidor 2 se conecta a varios componentes para reunir, fusionar y recortar los resultados de búsqueda de seguridad. El servidor 2 envía los resultados de búsqueda recortados al servidor 1, que luego se presentan al usuario.

Un poco más de investigación me lleva a mirar ActAs y OnBehalfOf . Creo que me gustaría usar OnBehalfOf, pero no estoy seguro de que ninguno de los dos funcione todavía. Algunas referencias que he encontrado se enumeran a continuación. Cualquier orientación es apreciada.

• .NET Framework Developer Center - Actuar como vs. en nombre de
• Blog de Pablo M. Cibraro (alias Cibrax) - Soporte de ActAs y OnBehalfOf en WIF
• Programando Windows Identity Foundation (tengo el libro)

Answer 1

Pasé varios meses trabajando en tratar de resolver este problema y, después de pasar mucho tiempo trabajando con Microsoft SharePoint, los ingenieros de WIF llegaron a la conclusión de que esto no es posible. Parece que el problema es básicamente a lo que Kirk alude. Al crear una sesión suplantada mediante reclamos (por ejemplo, creando un SPClaim y convirtiéndolo en un SPUser), SharePoint en realidad no está creando una sesión completamente suplantada. La sesión que se crea realmente solo se entiende por el modelo de objetos. Esto significa que cuando salga del límite de la aplicación web y en la búsqueda, estará realizando un salto doble porque ingresará a otro dominio de aplicación / espacio de proceso.

Intenté hacer algo similar a lo que sugiere eppesuig y no pude hacer que funcionara. Quizás si escribió un STS completamente nuevo que podría generar un token de reclamo de confianza que SharePoint aceptaría, entonces podría ser capaz de evitar esto usando el token de ActAs (SharePoint no aceptará el token de OnBehalfOf). Sin embargo, las implicaciones de seguridad de hacer eso son bastante preocupantes. Teóricamente, debería funcionar, pero conseguir que el STS personalizado y SharePoint se entremezclen / confianza demostró estar fuera de mi capacidad. Me encantaría ver a alguien más intentarlo, sin embargo.

Answer 2

Por lo que entiendo, no puedes usar directamente ninguna otra identidad que no sea la tuya. Si desea usar una función similar a OnBehalfOf, necesita un STS que pueda manejar la delegación. para que el STS verifique su identidad y luego permita el uso de identidades delegadas.