tridion - ¿Cómo puedo detectar si mi código debe suplantar o no?

Question

Tengo un código que se ejecuta como parte de un controlador de eventos y necesito crear una nueva sesión de TOM.NET (no puedo reutilizar subject.Session ). Este controlador de eventos se carga en muchos procesos de Tridion (TcmServiceHost, COM +, Publisher, TcmTemplateDebugHost, grupo de aplicaciones de IIS) y estos procesos pueden:

• ejecutar bajo una identidad que tiene acceso a Tridion (por ejemplo, la aplicación COM + se ejecuta bajo MTSUser, que es un administrador de Tridion)
• ejecutar bajo una identidad que no tiene acceso a Tridion, pero se le permite suplantar a los usuarios de Tridion (p. ej., TcmServiceHost se ejecuta como NetworkService, que está configurado como un usuario de personificación de Tridion).

Intento atender ambos casos con este código TOM.NET:

Session session = null;
try
{
    session = new Session();
}
catch (AccessDeniedException ex)
{
    // this process doesn''t have TCM access, so impersonate a user that does
    session = new Session("Administator");
}
if (session != null)
{
    var item = session.GetObject(id);
    ...

¿Es esta la forma correcta de verificar si mi código se está ejecutando en un proceso que tiene acceso a Tridion (ignorando el hecho de que yo codifiqué al "Administrador")? El código funciona, pero me pregunto si hay una manera más eficiente de realizar una verificación "tiene acceso a Tridion".

Nota : la misma pregunta surge cuando uso el Servicio Core para acceder a Tridion, por lo que la pregunta no es si TOM.NET es la API correcta para usar aquí.

Answer 1

Cuando se implementó originalmente el método TDSE.Impersonate (), se diseñó conscientemente para que falle silenciosamente si la identidad del hilo invocador no era un usuario de suplantación de identidad. Esto permitió, por ejemplo, que el código ASP en la GUI del día intente la suplantación a ciegas (basado en el encabezado REMRCE_USER IIRC). El punto era que si no era un usuario de suplantación de identidad, está bien, bien, podría ser usted mismo, pero si lo fuera, podría / podría hacerse pasar por una personificación.

Acabo de probar esto con la API COM (lo dejaré para que verifique que la API .NET sea coherente). Mis resultados (en Tridion 2011 SP1) son los siguientes:

1). Un usuario de suplantación que es un fideicomisario y no se hace pasar por él mismo se convierte en él mismo. 2). Un usuario de suplantación que es un fideicomisario y se hace pasar por persona, se convierte en quien se hace pasar por ella (NB, por lo general, preferiría no crear dicho usuario). 3). Un usuario sin suplantación que llama suplantación sigue siendo él mismo.

Obviamente, mucho depende de si la identidad del proceso es un usuario de suplantación de identidad. Quizás haya escenarios en los que prefiera evitar usar el SERVICIO DE RED y crear explícitamente una identidad para TcmServiceHost, simplemente para permitir un control preciso sobre si ese usuario puede suplantar la identidad.

Entonces ... ¿debería necesitar probar explícitamente si su proceso se está ejecutando como un imitador? Puede ser mejor simplemente intentar la suplantación y aceptar el resultado. El pensamiento original ciertamente incluía esta intención, pero sospecho que las cosas se han vuelto más complejas.

+1 para la pregunta, porque es absolutamente esencial que no haya dudas sobre el comportamiento esperado en esta área.

Answer 2

En primer lugar, esta es una gran pregunta / tema.

Creo que estás intentando "construir" algo genérico que puede funcionar en cada proceso de Tridion. En mi opinión, debe saber cuándo está en un proceso u otro, ya que, de acuerdo con las Mejores Prácticas (I + D / usted), no deberíamos crear objetos de Sesión, sino usar el Servicio Core en aquellos procesos que no tienen acceda al objeto Session y reutilice la sesión disponible cuando sea posible.

Como saben, por ejemplo, en Templating and Event System, tenemos acceso a la sesión, por lo que deberíamos reutilizarla (a menos que queramos hacer cosas que el usuario no puede hacer, en cuyo caso deberíamos suplantarnos).

Si en otro proceso la sesión no está disponible, debe usar el Servicio Core.

Así que mi respuesta a tu pregunta es no usar TOM.NET. Cambiaría mi enfoque y lo construiría usando el Servicio Core, donde puedo suplantar a un usuario específico que ya he configurado previamente. Y su código sería más genérico y se ejecutaría "en todas partes" (aunque no en una tostadora).

Entiendo lo que intenta identificar aquí, "¿quién diablos está ejecutando mi proceso actual"? para que pueda personificar en consecuencia,

Desafortunadamente (AFAIK), tendría que escribir algún código para ver quién es la identidad que está ejecutando el proceso y luego hacerse pasar por él. Esto es complicado, y por eso recomendaría usar el Servicio Core en lugar de la API TOM.NET.

Espero que esto tenga sentido.

Answer 3

Este código me parece bastante eficiente, pero al verificar si puede crear el objeto de la sesión, de ninguna manera se garantizará que el código podrá realizar la acción que realmente desea realizar en el CMS.

También parece que dicho código está creando una gran vulnerabilidad de seguridad que permite a los procesos retroceder a un nivel más alto de seguridad cuando no tienen permisos. También tenga en cuenta que si está modificando algún elemento en el CMS, esa suplantación tendrá el resultado de no mostrar el nombre real de la persona que pudo haber activado el cambio. Se almacenará como el usuario que está personificando.

Answer 4

Yo no usaría este código. La captura de excepciones es lenta y actualmente está dando acceso (Administrador) a cualquier persona que no pueda acceder al sistema, lo cual es un gran agujero de seguridad.

En cambio, me gustaría ver quién es el usuario actual y averiguar si es un usuario de suplantación o no. Puede leer los usuarios de suplantación del archivo Tridion.ContentManager.config directamente, si no hay una API para ello (no lo he comprobado).

var isImpersonationUser = IsImpersonationUser(WindowsIdentity.GetCurrent());
var session = isImpersonationUser ? new Session("Administrator") : new Session();
var item = session.GetObject(id);

O usted tendría que ser configurable por separado para su código de evento. O incluso codificado, si no te importa que el código sea genérico.