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

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

que puedo hacer esto para los usuarios de Windows integrada autenticados "clásicos" Uso:

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 conseguir lo anterior para trabajar la cuenta suplantada tiene que estar en el mismo dominio que el actual de usuario y tengo que asegurarse de que el propietario del grupo de aplicaciones es:

• una cuenta de dominio en un dominio que tiene un "nivel funcional de dominio" de Windows 2003 o mayor
• tiene "actuar como parte del sistema operativo" privilegio en el local de la caja
• tiene "suplantar a un cliente tras la autenticación" privilegio en el local de la caja

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

Reclamaciones cuentas

me gustaría hacer lo mismo con las cuentas de Reclamaciones WIF /. Estas cuentas son no asociadas necesariamente con cuentas AD (tengo que asumir que no).

¿Hay alguna manera de decirle al STS que quiero suplantar a una cuenta en particular y que me proporcione el token adecuado 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 (Server1) 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 - Act As vs. On BehalfOf
• Pablo M. Cibraro (aka Cibrax) blog - ActAs and OnBehalfOf support in WIF
• Programming 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 y los ingenieros de WIF llegamos 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, crear un SPClaim y convertirlo en un SPUser), SharePoint no está creando realmente 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. Tal vez 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 solucionarlo con 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 se puede utilizar directamente cualquier otra identidad, sino 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.