test

Notas de la version de Sun Java System Access Manager 7 2005Q4

Revisión 3 de Access Manager 7 2005Q4

La revisión 3 de Access Manager 7 (versión 03) soluciona diversos problemas, como se indica en el archivo README (LÉAME) incluido con la revisión. Además, incluye también las siguientes nuevas funciones y problemas conocidos:

Nuevas funciones de la revisión 3

Problemas conocidos y limitaciones de la revisión 3

Nuevas propiedades de configuración para la supervisión de sitios

La función de supervisión de sitios de Access Manager incluye las siguientes nuevas propiedades:

Propiedad 

Descripción 

com.sun.identity.sitemonitor.interval

Intervalo de tiempo en milisegundos para la supervisión de sitios. La función de supervisión de sitios comprueba la disponibilidad de cada sitio en el intervalo de tiempo especificado. Valor predeterminado: 60.000 milisegundos (1 minuto). 

com.sun.identity.sitemonitor.timeout

Tiempo de espera en milisegundos para la comprobación de disponibilidad del sitio. La función de supervisión de sitios espera durante el valor de tiempo de espera especificado la recepción de una respuesta del sitio. Valor predeterminado: 5.000 milisegundos (5 segundos).  

La revisión no agrega estas propiedades al archivo AMConfig.properties . Para utilizar las nuevas propiedades con valores diferentes a los predeterminados:

  1. Agregue las propiedades y sus valores al archivo AMConfig.properties en el siguiente directorio en función de su plataforma:

    • Sistemas Solaris: /etc/opt/SUNWam/config

    • Sistemas Linux: /etc/opt/sun/identity/config

    Si utiliza agentes de directivas, agregue estas propiedades al archivo AMAgents.properties.

  2. Reinicie el contenedor Web de Access Manager para que se apliquen los valores.

Implementación personalizada. Además, la clase com.sun.identity.sitemonitor.SiteStatusCheck le permite personalizar su propia implementación para la comprobación de la disponibilidad del sitio mediante la siguiente interfaz:

package com.iplanet.services.naming.WebtopNaming$SiteStatusCheck

Cada clase de implementación debe utilizar el método doCheckSiteStatus.

public interface SiteStatusCheck { 
public boolean doCheckSiteStatus(URL siteurl);
}

Compatibilidad con Liberty Identity Web Services Framework (ID-WSF) 1.1

La versión predeterminada de ID-WSF de la revisión 3 de Access Manager 7 es WSF1.1. No es necesario realizar ninguna configuración independiente para activar ID-WSF, aunque las muestras deben utilizar los nuevos mecanismos de seguridad. Los nuevos mecanismos de seguridad de ID-WSF1.1 son:

urn:liberty:security:2005-02:null:X509
urn:liberty:security:2005-02:TLS:X509
urn:liberty:security:2005-02:ClientTLS:X509
urn:liberty:security:2005-02:null:SAML
urn:liberty:security:2005-02:TLS:SAML
urn:liberty:security:2005-02:ClientTLS:SAML
urn:liberty:security:2005-02:null:Bearer
urn:liberty:security:2005-02:TLS:Bearer
urn:liberty:security:2005-02:ClientTLS:Bearer

Nueva propiedad para la compatibilidad con Liberty ID-WSF

La propiedad com.sun.identity.liberty.wsf.version determina la estructura de Liberty ID-WSF cuando ésta no puede determinar a partir del mensaje entrante o la oferta de recursos si Access Manager está actuando como WSC. Los valores pueden ser 1.0 ó 1.1. El valor predeterminado es 1.1.

Nota: la instalación de la revisión no agrega la propiedad com.sun.identity.liberty.wsf.version al archivo AMConfig.properties (CR# 6458184). Para utilizar esta nueva propiedad, agréguela al archivo AMConfig.properties con el valor adecuado después de instalar la revisión y, a continuación, reinicie el contenedor Web de Access Manager.

Una vez instalada la revisión 3 de Access Manager 7, ejecute el siguiente comando para cargar los cambios de esquema, el cual aparece con Access Manager instalado en el directorio predeterminado en los sistemas Solaris:

# /opt/SUNWam/bin/amadmin -u amadmin -w amadmin_password 
-t /etc/opt/SUNWam/wsf1.1_upgrade.xml

Al efectuar el registro, la función de detección de ID-WSF podrá utilizar estos nuevos mecanismos de seguridad. Además, los WSC detectarán automáticamente la versión que se utilizará al establecer comunicación con los WSP. Al realizar la configuración para ID-WSF1.1, consulte los archivos Readme (Léame) para obtener la muestra1 de Liberty ID-FF y las muestras de ID-WSF incluidas con el producto.

CR# 6463779: el registro amProfile_Client de autenticación distribuida y el registro amProfile_Server del servidor de Access Manager incluyen una gran cantidad de excepciones inofensivas.

Las solicitudes al servidor de Access Manager mediante la IU de autenticación distribuida genera excepciones en el registro distAuth/amProfile_Client y en el registro debug/amProfile_Server del servidor de Access Manager. Tras numerosas sesiones, el tamaño del registro amProfile_Client y del registro amProfile_Server del servidor de Access Manager puede aumentar hasta varios gigabytes. Estas excepciones en los registros no provocan ninguna pérdida de funcionalidad, pero pueden causar una falsa alarma a los usuarios además de que los registros pueden ocupar potencialmente una gran parte del espacio del disco duro.

Solución. Ejecute los trabajos cron que convertirán el contenido de los archivos de registro en nulo. Por ejemplo:

CR# 6460974: el usuario predeterminado de la aplicación de autenticación distribuida no debe ser amadmin.

Si va a implementar un servidor de la IU de autenticación distribuida, el administrador de autenticación distribuida no debe ser amadmin. El usuario predeterminado de la aplicación de autenticación distribuida es amadmin en el archivo Makefile.distAuthUI y, posteriormente, en el archivo AMConfig.properties una vez implementado el archivo distAuth.war en el cliente. El usuario amadmin tiene un AppSSOToken que caduca una vez agotado el tiempo de sesión de amadmin, lo que puede provocar un ERROR GRAVE en el archivo de registro amSecurity (ubicado de forma predeterminada en el directorio /tmp/distAuth).

Solución. Especifique UrlAccessAgent como usuario de la aplicación de autenticación distribuida. Por ejemplo:

Antes de implementar el archivo distAuth.war en el contenedor Web, cambie los siguientes parámetros en el archivo Makefile.distAuthUI :

APPLICATION_USERNAME=UrlAccessAgent
APPLICATION_PASSWORD=shared-secret-password or amldapuser-password

o

Después de implementar el archivo distAuth.war en el contenedor Web, cambie las siguientes propiedades en el archivo AMConfig.properties para cada servidor de Access Manager:

com.sun.identity.agents.app.username=UrlAccessAgent
com.iplanet.am.service.password=shared-secret-password or amldapuser-password

Consulte también CR# 6440697: la autenticación distribuida debe ejecutarse con un usuario que no sea amadmin..

CR# 6460576: no hay ningún vínculo para el Servicio de usuario en Rol filtrado en la ayuda en línea de la consola.

La ayuda en línea de la consola de Access Manager no incluye ningún vínculo para el Servicio de usuario en Rol filtrado. En la ayuda en línea, vaya a Contenido, Rol filtrado y "Para crear un rol filtrado". Desplácese a la siguiente página y, en función del tipo de identidad seleccionado, aparecerá una lista de servicios, pero no estará disponible ningún vínculo de Servicio de usuario.

Solución. Ninguna.

CR# 6460085: el servidor de WebSphere no está accesible después de ejecutar reinstallRTM y reimplementar las aplicaciones Web.

Después de aplicar la revisión 3 de Access Manager 7 para una implementación DEPLOY_LEVEL=1 en IBM WebSphere Application Server 5.1.1.6 en Red Hat Linux AS 3.0 Update 4, la secuencia de comandos reinstallRTM se ejecuta para restablecer los RPM de RTM. A continuación, se reimplementan las aplicaciones Web después de editar el archivo amsilent generado por la secuencia de comandos reinstallRTM. WebSphere se reinicia mediante las secuencias de comandos stopServer.sh y startServer.sh. Sin embargo, al acceder a la página de inicio de sesión, WebSphere muestra un error 500, relacionado con el filtro amlcontroller.

Este problema se produce debido a que el nuevo archivo server.xml generado por la secuencia de comandos reinstallRTM está dañado.

Solución. El archivo server.xml del que la secuencia de comandos amconfig ha realizado una copia de seguridad aún es válido. Utilice esta copia anterior de la siguiente forma:

  1. Pare el servidor.

  2. Sustituya el archivo server.xml dañado por la copia de seguridad realizada por la secuencia de comandos amconfig.

    El archivo server.xml del que la secuencia de comandos amconfig ha realizado una copia de seguridad presenta el nombre server.xml-orig- pid, donde pid es el Id. de proceso de la secuencia de comandos amwas51config. El archivo se encuentra en el siguiente directorio:

    WebSphere-home-directory/config/cells/WebSphere-cell
/nodes/WebSphere-node/servers/server-name

  3. Reinicie el servidor.

CR# 6455757: el marcador sunISManagerOrganization debe agregarse a una organización antes de realizar una actualización.

Es posible que una organización de un DIT de Access Manager creada con una versión anterior a Access Manager 7 no presente la clase de objeto sunISManagerOrganization. Además, una organización creada con un producto diferente a Access Manager no incluirá la clase de objeto sunISManagerOrganization en su definición.

Solución. Antes de actualizar a Access Manager 7 2005Q4, asegúrese de que todas las organizaciones del DIT incluyan la clase de objeto sunISManagerOrganization en su definición. Si es necesario, agregue manualmente esta clase de objeto antes de realizar la actualización.

CR# 6454489: la actualización de la revisión 2 de Access Manager 7 2005Q4 provoca un error en la ficha Sesiones actuales de la consola.

Una actualización ha provocado el siguiente error en la ficha Sesiones actuales de la consola de Access Manager:

Failed to get valid Sessions from the Specified server

Este problema hace referencia a las implementaciones que se actualizan desde las versiones de Access Manager 6 que tienen un sufijo root con el formato o=orgname.

Solución. Después de instalar Manager 7 2005Q4, aplique la revisión 3 de Access Manager 7 y, a continuación, ejecute la secuencia de comandos amupgrade para migrar los datos de la siguiente forma:

  1. Realice una copia de seguridad del DIT de Access Manager 6.

  2. Ejecute la secuencia de comandos ampre70upgrade.

  3. Instale Access Manager 7 2005Q4 con la opción Configurar más tarde.

  4. Anule la implementación de las aplicaciones Web de Access Manager.

  5. Implemente las aplicaciones Web de Access Manager.

  6. Aplique la revisión 3 de Access Manager 7, pero no aplique los cambios de XML/LDIF. Estos cambios deben aplicarse después de ejecutar la secuencia de comandos amupgrade en el siguiente paso.

  7. Ejecute la secuencia de comandos amupgrade.

  8. Reimplemente las aplicaciones Web de Access Manager debido a los cambios efectuados por la revisión 3 de Access Manager 7.

  9. Acceda a la consola de Access Manager.

CR# 6452320: se generan excepciones al utilizar el sondeo con el SDK de cliente.

Al implementar el SDK de cliente de Access Manager (amclientsdk.jar) y habilitar la función de sondeo, pueden producirse errores como los siguientes:

ERROR: Send Polling Error:
com.iplanet.am.util.ThreadPoolException: 
amSessionPoller thread pool's task queue is full.

Estos errores pueden producirse después de implementar un servidor de la IU de autenticación distribuida, los agentes de J2EE o en cualquier situación en la que se implemente el SDK de cliente de Access Manager en un equipo cliente.

Solución. Si sólo tiene varias centenas de sesiones concurrentes, agregue las siguientes propiedades y valores al archivo AMConfig.properties o AMAgents.properties:

com.sun.identity.session.polling.threadpool.size=10
com.sun.identity.session.polling.threadpool.threshold=10000

Si tiene varios miles o decenas de miles de sesiones, deben establecerse los mismos valores que los de la notificación en el archivo AMConfig.properties de Access Manager después de ejecutar la secuencia de comandos amtune-identity. Por ejemplo, en un equipo con 4 GB de RAM, la secuencia de comandos amtune-identity de Access Manager establece los siguientes valores:

com.sun.identity.session.notification.threadpool.size=28
com.sun.identity.session.notification.threadpool.threshold=76288

Establezca valores parecidos en el archivo AMAgent.properties o AMConfig.properties del cliente al implementar el servidor de la IU de autenticación distribuida o el SDK de cliente de Access Manager en un equipo cliente con 4 GB de RAM.

CR# 6442905: el SSOToken del usuario autenticado puede mostrarse de forma accidental en sitios poco fiables.

Un usuario autenticado de Access Manager puede mostrar de forma accidental el SSOToken en un sitio poco fiable haciendo clic en una URL de dicho sitio.

Solución. Cree siempre un perfil de usuario de agente exclusivo en Access Manager para todos los agentes de directivas que participen para asegurarse de que el sitio sea fiable. Además, compruebe que ninguno de los usuarios de agente exclusivos utilice la misma contraseña que la contraseña secreta compartida o la contraseña de amldapuser. Los agentes de directivas se autentican de forma predeterminada en el módulo de autenticación de la aplicación Access Manager como usuario UrlAccessAgent.

Para obtener más información sobre cómo crear un agente mediante la consola de administración de Access Manager, consulte Agents de Sun Java System Access Manager 7 2005Q4 Administration Guide.

CR# 6441918: propiedades de tiempo de espera e intervalo de supervisión de sitios.

La función de conmutación por error de sitios de Access Manager incluye las siguientes nuevas propiedades:

com.sun.identity.sitemonitor.interval
com.sun.identity.sitemonitor.timeout

Para obtener más información, consulte Nuevas propiedades de configuración para la supervisión de sitios.

CR# 6440697: la autenticación distribuida debe ejecutarse con un usuario que no sea amadmin.

Para crear un administrador de autenticación distribuida que no sea el usuario administrativo predeterminado (amadmin) para la autenticación de la aplicación de autenticación distribuida, siga el siguiente procedimiento:

  1. Cree un usuario LDAP para el administrador de autenticación distribuida. Por ejemplo:

    uid=DistAuthAdmin,ou=people,o=am

  2. Agregue el administrador de autenticación distribuida a la lista de usuarios especiales. Por ejemplo:

    com.sun.identity.authentication.special.users=cn=dsameuser,
ou=DSAME Users,o=am|cn=amService-UrlAccessAgent,ou=DSAME Users,
o=am|uid=DistAuthAdmin,ou=People,o=am

    Agregue esta propiedad al archivo AMConfig.properties de todos los servidores de Access Manager para que el AppSSOToken del administrador de autenticación distribuida no caduque al finalizar la sesión.

CR# 6440695: servidores de la IU de autenticación distribuida con equilibrador de carga.

Si la implementación incluye un equilibrador de carga frente a varios servidores de la IU de autenticación distribuida, establezca las siguientes propiedades en el archivo AMConfig.properties después de implementar el archivo WAR.

com.iplanet.am.lbcookie.name=DistAuthLBCookieName
com.iplanet.am.lbcookie.value=DistAuthLBCookieValue

CR# 6440651: la repetición de las cookies requiere la propiedad com.sun.identity.session.resetLBCookie

Para que la repetición de las cookies funcione correctamente para una migración tras error de sesión de Access Manager, agregue la propiedad com.sun.identity.session.resetLBCookie con un valor true tanto para el agente de directivas como para el servidor de Access Manager. Por ejemplo:

com.sun.identity.session.resetLBCookie='true'

Nota: esta propiedad es necesaria sólo si se ha implementado la migración tras error de sesión de Access Manager.

CR# 6440648: la propiedad com.iplanet.am.lbcookie.name asume el valor predeterminado amlbcookie.

De forma predeterminada, un agente de directivas y los servidores de Access Manager asumen el nombre de cookie de equilibrador de carga amlbcookie. Si cambia el nombre de la cookie en el servidor de servicios de fondo, debe utilizar el mismo nombre en el archivo AMAgent.properties del agente de directivas. Además, si utiliza el SDK de cliente de Access Manager, debe usar el mismo nombre de cookie utilizado por el servidor de servicios de fondo.

CR# 6440641: la propiedad com.iplanet.am.lbcookie.value se ha dejado de utilizar.

Access Manager ya no admite la propiedad com.iplanet.am.lbcookie.value en los servidores para personalizar la cookie del equilibrador de carga. En su lugar, Access Manager utiliza ahora el Id. de servidor, que se configura como parte del proceso de configuración de sesión, para el valor de la cookie y para el nombre que va a repetir el agente.

CR# 6429610: no se puede crear el token SSO al utilizar ID-FF SSO.

Después de configurar la muestra 1 de Liberty Identity Federation Framework (ID-FF), la federación se realiza con éxito, pero se producen errores en SSO.

Solución. Agregue el uuid de dsameuser a la propiedad com.sun.identity.authentication.special.users del archivo AMConfig.properties. En la autenticación de aplicaciones, dsameuser necesita un token SSO que no caduque para el servidor de Access Manager.

CR# 6389564: se producen consultas sucesivas recurrentes sobre los miembros del rol del usuario en el almacén de datos LDAP v3 durante el inicio de sesión de Access Manager.

Cuando un usuario inicia una sesión en Access Manager, se realizan varias búsquedas de LDAP recurrentes en el atributo nsRoleDN del usuario.

Solución. Una vez instalada la revisión 3 de Access Manager 7, ejecute el siguiente comando que aparece con Access Manager instalado en el directorio predeterminado en los sistemas Solaris:

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/idRepoServiceAddAttrSchemaRequest_Cache.xml

CR# 6385185: el módulo de autenticación debe poder anular la URL "goto" y especificar una URL diferente.

Un módulo de autenticación puede anular la URL "goto" y solicitar la redirección a una URL diferente de un sitio Web externo para obtener la validación del estado del usuario.

Para anular la URL "goto" una vez completada la autenticación, establezca la propiedad que aparece en el siguiente ejemplo en el SSOToken. Debe establecer esta propiedad mediante el método onLoginSuccess de la clase PostProcess que implementa AMPostAuthProcessInterface. Por ejemplo, OverridingURL es la URL que anula la URL "goto":

public class <..> implements AMPostAuthProcessInterface {  
...
    public void onLoginSuccess(...) {
        try {
            ssoToken.setProperty("PostProcessSuccessURL", OverridingURL);
         } catch (Exception ...) {
         ...         }
...
}

CR# 6385184: redirección desde un módulo de autenticación personalizado cuando el token SSO no presenta aún un estado válido.

La nueva función RedirectCallback del módulo de autenticación personalizado permite la redirección a un sitio Web externo mediante la IU de administración para conseguir la validación de un usuario. Si la autenticación se realiza con éxito, el usuario se redirige de nuevo a la URL original del servidor de Access Manager. Entre los archivos de muestra, se incluyen:

Para implementar esta función:

  1. Cree un módulo de autenticación personalizado utilizando el archivo de muestra LoginModuleSample.java.

  2. Cargue el módulo en el servidor de Access Manager.

  3. Cree la función RedirectCallback en el archivo XML mediante el archivo de muestra LoginModuleSample.xml.

  4. Para probar el módulo, utilice el archivo de muestra testExtWebSite.jsp del sitio Web externo.

  5. Inicie sesión mediante esta URL:

    http://example.com/amserver/UI/Login?module=LoginModuleSample

El nombre de usuario y la contraseña se redirigen al sitio Web externo para la validación. Si el nombre y la contraseña son válidos, la autenticación se realiza con éxito y el usuario se redirige de nuevo a la URL original del servidor de Access Manager.

Por ejemplo, imagine una situación en la que la implementación utiliza un módulo de autenticación personalizado para acceder a un sitio de suministro/tarjetas de crédito.

  1. El usuario ejecuta el proceso de autenticación o la página de inicio de sesión para el módulo de autenticación personalizado.

  2. El usuario introduce las credenciales (el nombre de usuario y la contraseña) y envía una solicitud al módulo de autenticación personalizado.

  3. El módulo de autenticación personalizado redirecciona al usuario a un sitio de suministro/tarjetas de créditos externo con la información de usuario necesaria junto con la solicitud.

  4. Este sitio externo comprueba el estado del usuario y devuelve la solicitud con una respuesta de éxito o fallo, que se establece como parte de la solicitud devuelta.

  5. El módulo de autenticación valida el usuario en función del estado devuelto en el paso 4 y devuelve el correspondiente estado al servicio de autenticación.

  6. El proceso de autenticación del usuario se completa de forma satisfactoria o, por el contrario, con errores.

CR# 6324056: la federación falla al utilizar un perfil de artefacto.

Solución: Para solucionar este problema, aplique la versión más reciente de la revisión "Core Mobile Access" en función de la plataforma que utilice:

Una vez aplicada la revisión, reinicie el contenedor Web.