Identity Manager 8.1 Deployment Reference

Esta sección contiene nueva información y corrección de erratas del documento Sun Identity Manager Deployment Reference:

Errores de la documentación relativos a los formularios

En este capítulo falta la siguiente descripción sobre la adición de preguntas de comprobación de contraseñas a los formularios: (ID-7604)

Puede utilizar la propiedad RequiresChallenge para agregar una pregunta de comprobación de contraseñas a determinados formularios. Cuando se habilita esta función, Identity Manager pide al administrador que haya iniciado la sesión que especifique su contraseña antes de procesar una petición. Los formularios que admiten esta opción incluyen:

userForm (formularios de usuario asistente, con fichas y predeterminado)

changePassword (de forma predeterminada, el formulario Modificar contraseña de usuario)

resetPassword (de forma predeterminada, el formulario Reinicializar contraseña de usuario)

La propiedad se especifica de forma diferente para cada uno de los formularios.

Configuración de la propiedad RequiresChallenge para los formularios de usuario

Para agregar preguntas de confirmación de la contraseña a un formulario de usuario, agregue el siguiente elemento RequiredElement como se muestra a continuación, con valores de sustitución para contraseña, correo electrónico y nombre completo:

<Property name='RequiredChallenge'>
    <List>
      <String>password</String>
      <String>email</String>
      <String>fullname</String>
    </List>
</Property>

El valor de la propiedad es una lista con uno o varios de los siguientes nombres de atributos de la vista de usuario: aplicaciones, adminRoles, assignedLhPolicy, capacidades, controlledOrganizations, correo electrónico, nombre, nombre completo, apellidos, organización, contraseña, recursos, roles.

Configuración de la propiedad RequiresChallenge para los formularios Modificar contraseña y Reinicializar contraseña

Para agregar preguntas de confirmación de la contraseña a un formulario changePassword o resetPassword, añada el siguiente elemento <RequiresChallenge> como se muestra a continuación, con valores de sustitución para contraseña, correo electrónico y nombre completo (password, email, y fullname):

<Property name='RequiresChallenge' value='true'/>

Donde el valor de la propiedad puede ser "true" o "false".

Si la propiedad se configura como "true" en el formulario, Identity Manager pedirá al administrador que esté solicitando el cambio que introduzca la contraseña que utilizase para entrar en Lighthouse. Si no se responde correctamente a esta petición (es decir, no se introduce la contraseña actual del administrador), Identity Manager no autoriza el cambio. Si se responde adecuadamente a la petición, Identity Manager autoriza la petición de cambio. Ambos formularios de administración de contraseñas admiten el uso de la propiedad "RequiresChallenge". Cuando esta propiedad tiene el valor "true", se pide al usuario que introduzca la contraseña antigua después de especificar la nueva.

Supresión de la información de versión

Es posible crear dos claves de catálogos de mensajes personalizados que impidan a Identity Manager mostrar la información de versión cuando un usuario sitúa el cursor sobre el botón de ayuda. La clave UI_END_USER_VERSION oculta la información de la versión en la interfaz de usuario, mientras que la clave UI_VERSION se utiliza en la interfaz de administrador.

Si se configura el valor de la clave como una cadena vacía, no se muestra ninguna información de versión.

En el ejemplo siguiente se inhabilita la versión de información en ambas interfaces.

<Waveset>
   <Configuration name="sampleCustomCatalog">
      <Extension>
         <CustomCatalog id="defaultCustomCatalog" enabled="true">
            <MessageSet language="en" country="US">
               <Msg id="UI_END_USER_VERSION"></Msg>
               <Msg id="UI_VERSION"></Msg>
            </MessageSet>
         </CustomCatalog>
      </Extension>
   </Configuration>
</Waveset>

Otras cuestiones relativas a los formularios

En el capítulo de formularios ("Forms") falta la siguiente explicación: (ID-18869)

Inicialmente existen dos implementaciones del formulario de cambio de contraseña:

El formulario de cambio de contraseña de usuario final es el predeterminado. Presenta un grupo de campos sencillos con los que el usuario puede cambiar su contraseña. Se agregan y resumen las directivas de contraseña correspondientes a todos los recursos asignados a ese usuario e Identity Manager aplica el cambio de contraseña a todos los recursos asignados.

El formulario de cambio de contraseña básico está presente en las interfaces de administrador y usuario. Proporciona información sobre los recursos asignados al usuario y permite a éste seleccionar de forma individual en qué recursos deberá cambiar la contraseña Identity Manager.

Ambos formularios admiten el uso de la propiedad "RequiresChallenge". Cuando esta propiedad se define como "true", se pide al usuario que introduzca la contraseña antigua después de especificar la nueva.

Cuestiones comunes a los flujos de trabajo y los formularios

En los capítulos de formularios y flujos de trabajo de esta guía faltan las siguientes explicaciones sobre la asignación de alcance a los elementos <Variable>: (ID-14915)

Identity Manager asigna un alcance a todos los elementos <Variable> en el momento de declarar el elemento. Si no se asigna ningún valor al atributo de alcance, Identity Manager le asigna un valor local, lo que significa que sólo se puede acceder a la variable desde la sección XPRESS en la que se haya declarado.

Otros atributos de Variable que definen el alcance incluyen:

input: declara que el elemento <Variable> tiene un alcance local y que el valor puede ser inicializado por la acción de llamada.

output: declara que el elemento <Variable> tiene alcance local pero puede devolverse a la acción de llamada.

external: declara una <Variable> que no tiene alcance local, es decir, las asignaciones a esta variable se realizarán dentro del ámbito en que se declarase inicialmente.

En este capítulo falta la siguiente explicación sobre la función de lista blanca de Identity Manager. (ID-19474)

La función de lista blanca de Identity Manager permite cotejar los formularios y flujos de trabajo que utilizan la acción SaveNoValidate con una lista de ID o nombres de formulario. (comprueba la lista en busca de nombres de formulario o ID de propietarios de formularios). La lista de ID, llamada saveNoValidateAllowedFormsAndWorkflows, está situada en el atributo de seguridad del objeto System Configuration. Si el nombre del formulario o el ID de su propietario se encuentran en la lista blanca, el formulario o el flujo de trabajo pueden usar la acción SaveNoValidate. En caso de que ni el nombre del formulario ni el ID del propietario se encuentren en la lista, el formulario o el flujo de trabajo se procesará utilizando una acción Save. Si la lista no está presente, todos los formularios y flujos de trabajo pueden procesarse como SaveNoValidate.

Para implementar esta función en su implantación, deberá agregar cualquier formulario o flujo de trabajo que utilice SaveNoValidate a la lista saveNoValidateAllowedFormsAndWorkflows del objeto System Configuration. Para ver los ID o nombres de formulario que debe agregar, compruebe el registro syslog o active el nivel de seguimiento 4 para com.waveset.ui.util.GenericEditForm y envíe cualquier formulario o flujo de trabajo personalizado que utilice SaveNoValidate. Se registrará una advertencia que incluirá el ID correspondiente. Si se registran nombres de formulario "null" en syslog, compruebe si el formulario de TaskDefinition que se ha ejecutado tiene algún atributo de nombre.

Cuestiones relativas a los flujos de trabajo

En el capítulo de flujos de trabajo falta la siguiente explicación sobre el flujo handleNativeChangeToAccountAttributes (ID-3275):

Cuando Identity Manager detecta un cambio nativo (es decir, uno que no se ha realizado a través de Identity Manager) en los valores de un atributo auditable de una cuenta de recursos, la aplicación responde ejecutando el flujo de trabajo handleNativeChangeToAccountAttributes, que está asociado a este atributo del objeto System Configuration:

<Attribute name='process'>
  <Object>
    <Attribute name='handleNativeChangeToAccountAttributes' value='Audit Native
      Change To Account Attributes'/>
  </Object>
</Attribute>

Este flujo de trabajo registra los eventos de cambio nativos en el registro de eventos si se ha habilitado el filtro de auditoría de cambios fuera de Lighthouse. En caso contrario, Identity Manager hace caso omiso del evento. Advertencia: preste atención a los métodos que llama desde cualquier flujo de trabajo que sustituya al flujo de trabajo citado anteriormente.

Dado que Identity Manager ejecuta este flujo cada vez que una búsqueda de la cuenta de recursos descubre un cambio nativo, no se debe llamar a ningún método o flujo de trabajo que pueda activar otra búsqueda de esa misma cuenta. Por ejemplo, se producirá un bucle infinito si se hace una llamada a algún método WorkflowServices que ensamble la vista de usuario: getView(User), checkoutView(User) y posiblemente checkinView(User).

El hecho de que Identity Manager maneje cada cambio nativo ejecutando un flujo de trabajo le permite detectar el evento de cambio nativo y manejarlo como considere adecuado, sustituyéndolo o añadiéndolo al flujo de trabajo de cambios nativos predeterminado. Por ejemplo, puede que opte por enviar un correo electrónico a un administrador o un usuario, grabar el evento en una base de datos, poner en cola una actualización que dejaría sin efecto el cambio nativo o incluso llevar ese cambio a los otros recursos.

En el capítulo de flujos de trabajo de esta guía falta la siguiente descripción sobre la forma de especificar el asunto o administrador de una tarea del adaptador de origen. (ID-19694).

Es posible asignar un asunto o administrador a una tarea del adaptador de origen y designar el servidor en el que se ejecuta editando los siguientes atributos del objeto System Configuration. sources.subject especifica el nombre de acceso del administrador designado como propietario de la tarea. sources.host especifica el servidor en el que se ejecuta la tarea. Los nuevos valores del objeto de configuración son, de forma predeterminada:

<Attribute name='sources'>
           <Object>
             <Attribute name='hosts'/> <!-- any host is the default -->
           <Attribute name='subject' value='Configurator'/>
         </Object>
         </Attribute>