test

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

Versiones de las revisiones de Access Manager 7 2005Q4

Las versiones más recientes de las revisiones de Access Manager 7 2005Q4 pueden descargarse en SunSolve Online: http://sunsolve.sun.com. Los Id. de revisión más recientes son:

Nota –

Las revisiones de Access Manager 7 2005Q4 son acumulativas. Puede instalar la revisión 7 sin necesidad de instalar en primer lugar la revisión 1, 2, 3, 4, 5 o 6. Sin embargo, si no ha instalado ninguna revisión anterior, revise las nuevas funciones y problemas de las secciones de la revisión anterior para determinar si alguna de las funciones o problemas se aplican a su implementación.

Entre la información acerca de las revisiones de Access Manager 7 2005Q4, se incluye:

Revisión 7 de Access Manager 7 2005Q4

La revisión 7 (versión 07) de Access Manager 7 soluciona diversos problemas, como se indica en el archivo README (LÉAME) incluido con la revisión.

La revisión 7 incluye estos cambios:

CR# 6637806: tras el reinicio, Access Manager envió un token SSO de aplicaciones no válido a un agente

Tras el reinicio de un servidor Access Manager, el SDK de cliente de Access Manager ahora envía una excepción significativa a un agente, por lo que el agente puede volver a autenticarse para obtener una nueva sesión de aplicaciones. Anteriormente, tras aplicar la revisión 5 de Access Manager 7 2005Q4, el SDK de cliente de Access Manager enviaba un token SSO de aplicaciones no válido al agente tras reiniciar el servidor Access Manager.

Este problema se ha solucionado mediante el duplicado CR 6496155. La revisión 7 también cuenta con una opción (propiedad comp.iplanet.dpro.session.dnRestrictionOnly) para enviar el token SSO de aplicaciones en un contexto restrictivo. De forma predeterminada, los agentes envían la dirección IP del servidor en el que están instalados, pero si es necesario realizar una comprobación de DN estricta, establezca esta propiedad en el archivo AMConfig.properties de la siguiente manera:

com.iplanet.dpro.session.dnRestrictionOnly=true

CR# 6612609: la conmutación por error de sesión funciona si el cable de red está desconectado del servidor Message Queue

En una implementación de conmutación por error de sesión, si todas las instancias de Access Manager y los agentes de Message Queue están instalados en el mismo servidor, la conmutación por error de sesión ahora funciona si el cable de red está desconectado de uno de los servidores. De forma predeterminada, el atributo de fábrica de conexión imqAddressListBehavior de Message Queue está establecido en PRIORITY, lo que provoca que Message Queue pruebe las direcciones en el orden en que aparecen en la lista de direcciones del agente (por ejemplo: localhost:7777,server2:7777,server3:7777). Si el atributo está establecido en RANDOM, las direcciones se prueban en orden aleatorio.

Para establecer este atributo en RANDOM, establezca el siguiente parámetro en la secuencia de comandos amsessiondb:

-DimqAddressListBehavior=RANDOM

Para obtener información acerca de los atributos PRIORITY y RANDOM de Message Queue, consulte Broker Address List de Sun Java System Message Queue 3.7 UR1 Administration Guide.

CR# 6570409: el servicio de interacción del equilibrador de carga funciona correctamente como proveedor de identidades

En una implementación con dos servidores conectados con un equilibrador de carga y funcionando como un único proveedor de identidades, debe establecer las siguientes propiedades en el archivo AMConfig.properties:

com.sun.identity.liberty.interaction.lbWspRedirectHandler
com.sun.identity.liberty.interaction.trustedWspRedirectHandlers

La clase com.sun.identity.liberty.interaction.interactionConfigClass es la única compatible actualmente. Por lo tanto, de forma predeterminada, la clase de configuración de interacción integrada en Federation Liberty se utiliza para acceder a los parámetros de configuración de interacción.

CR# 6545176: las URL de redirección se pueden establecer de forma dinámica en el complemento SPI de procesamiento posterior a la autenticación

Las URL de redirección se pueden establecer ahora de forma dinámica en los complementos SPI de procesamiento posterior a la autenticación para un inicio de sesión correcto e incorrecto y para el cierre de sesión. Si no se ejecuta un complemento de procesamiento posterior, no se utilizará la URL de redirección establecida en la SPI de procesamiento posterior, y las URL de redirección establecidas a través de otros medios se ejecutarán de la misma forma que antes.

Para obtener más información, consulte el ejemplo com.iplanet.am.samples.authentication.spi.postprocess.ISAuthPostProcessSample.java .

Consideraciones previas a la instalación

Copia de seguridad de los archivos

Importante. Si se ha personalizado alguno de los archivos de la instalación actual, realice una copia de seguridad de éstos antes de instalar la revisión. Después de instalar la revisión, compare los archivos de los que se ha realizado una copia de seguridad con los nuevos archivos instalados por la revisión para identificar los elementos que se han personalizado. Combine las personalizaciones con los nuevos archivos y guárdelos. Para obtener más información sobre cómo administrar los archivos personalizados, lea la siguiente información.

Antes de instalar una revisión, realice también una copia de seguridad de los siguientes archivos.

Sistemas Solaris

  • AccessManager-base/SUNWam/bin/amsfo

  • AccessManager-base/SUNWam/lib/amsfo.conf

  • Archivos del directorio /etc/opt/SUNWam/config/xml/template/:

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml, amAuth.xml , amSession.xml

  • Archivos del directorio AccessManager-base/SUNWam/locale/ :

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

Sistemas Linux y HP-UX

  • AccessManager-base/identity/bin/amsfo

  • AccessManager-base/identity/lib/amsfo.conf

  • Archivos del directorio /etc/opt/sun/identity/config/xml/template/ :

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml , amAuth.xml, amSession.xml

  • Archivos del directorio AccessManager-base/identity/locale/ :

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

Sistemas Windows

  • AccessManager-base\identity\setup\AMConfigurator.properties

  • AccessManager-base\identity\bin\amsfo

  • AccessManager-base\identity\lib\amsfo.conf

  • Archivos del directorio AccessManager-base\identity\config\xml\template :

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml , amAuth.xml, amSession.xml

  • Archivos del directorio AccessManager-base\identity\locale :

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

AccessManager-base es el directorio base de instalación. El directorio base de instalación predeterminado depende de la plataforma:

  • Sistemas Solaris: /opt

  • Sistemas Linux y HP-UX: /opt/sun

  • Sistemas Windows: javaes-install-directory\AccessManager . Por ejemplo: C:\Program Files\Sun\AccessManager

Instalación y configuración de Access Manager

Las revisiones de Access Manager descritas en este documento no instalan Access Manager. Antes instalar la revisión, Access Manager 7 2005Q4 debe instalarse en el servidor. Para obtener más información sobre la instalación, consulte la Guía de instalación de Sun Java Enterprise System 2005Q4 para UNIX.

Si instala la revisión en un sistema Windows, consulte la Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows .

Además, debe familiarizarse con la secuencia de comandos amconfig para implementar, reimplementar y configurar Access Manager, como se describe en el Capítulo 1, Access Manager 7 2005Q4 Configuration Scripts de Sun Java System Access Manager 7 2005Q4 Administration Guide.

Para obtener una lista de las revisiones de Access Manager obsoletas debido a esta nueva revisión y a todas las revisiones que debe instalar antes de instalar este revisión, consulte el archivo README (LÉAME) incluido con la revisión.

Precaución – Precaución –

Las revisiones de Access Manager (al igual que cualquier otra revisión) debe probarse en un sistema en el que no se haya realizado aún una implementación o en el que se esté iniciando una implementación antes de aplicarlas en un entorno de producción. Además, el programa de instalación de revisiones no actualiza adecuadamente los archivos JSP personalizados, por lo es que es posible que deba realizar cambios manuales en estos archivos para que Access Manager funcione correctamente.

Instrucciones de instalación de las revisiones

Instrucciones de instalación de revisiones para los sistemas Solaris

Antes de instalar la revisión de Solaris, asegúrese de que ha hecho una copia de seguridad de los archivos enumerados en Consideraciones previas a la instalación.

Para agregar o eliminar revisiones en los sistemas Solaris, utilice los comandos patchadd y patchrm, que se proporcionan con el SO.

Comando patchadd

Utilice el comando patchadd para instalar una revisión en un sistema independiente. Por ejemplo:

# patchadd /var/spool/patch/120954-07
Nota –

Si está instalando la revisión de Solaris en una zona global de Solaris 10, llame al comando patchadd con el argumento -G. Por ejemplo:

patchadd -G /var/spool/patch/120954-07

La secuencia de comandos postpatch muestra un mensaje acerca de la reimplementación de las aplicaciones de Access Manager, excepto en un sistema con un único componente de SDK de Access Manager instalado.

La secuencia de comandos postpatch crea el archivo amsilent en el siguiente directorio:

AccessManager-base es el directorio base de instalación. El directorio base de instalación predeterminado es /opt en los sistemas Solaris y /opt/sun en los sistemas Linux.

El archivo amsilent se basa en el archivo amsamplesilent, aunque se han establecido algunos parámetros necesarios en función de los archivos de configuración de Access Manager en el sistema. Sin embargo, los parámetros de contraseña contienen valores predeterminados. Elimine el delimitador y modifique el valor de cada parámetro de contraseña, y compruebe atentamente los valores de los demás parámetros de este archivo según las necesidades de su implementación.

El parámetro COMMON_DEPLOY_URI, el prefijo URI de la aplicación web de dominio común, también contiene un valor predeterminado. Si ha elegido un valor no predeterminado para este URI, asegúrese de actualizar este valor. De lo contrario, fallará la reimplementación de las aplicaciones web con amconfig y el archivo amsilent generado por la revisión.

A continuación, ejecute el siguiente comando (que se muestra con Access Manager instalado en el directorio predeterminado):

# cd /opt/SUNWam/bin 
# ./amconfig -s /opt/SUNWam/amsilent
Precaución – Precaución –

El archivo amsilent contiene datos confidenciales como por ejemplo las contraseñas de administrador en texto sencillo, así que asegúrese de que protege el archivo adecuadamente para su implementación.

Tras ejecutar la secuencia de comandos amconfig, ejecute la secuencia de comandos updateschema.sh para cargar los archivos XML y LDIF. La secuencia de comandos updateschema.sh está disponible tras la instalación de la revisión 7 en el siguiente directorio:

Después de ejecutar la secuencia de comandos updateschema, reinicie los procesos de Access Manager. Por ejemplo:

# cd /opt/SUNWam/bin
# ./amserver stop
# ./amserver start

A continuación, reinicie el contenedor web de Access Manager.

Comando patchrm

Utilice el comando patchrm para eliminar una revisión de un sistema independiente. Por ejemplo:

# patchrm 120954-03

La secuencia de comandos backout muestra un mensaje parecido al del comando patchadd, excepto en un sistema con un único componente de SDK de Access Manager instalado.

Tras eliminar la revisión, vuelva a implementar las aplicaciones de Access Manager utilizando el archivo amsilent del directorio AccessManager-base /SUNWam, donde AccessManager-base es el directorio base de instalación. El directorio base de instalación predeterminado es /opt en los sistemas Solaris.

Establezca los parámetros del archivo amsilent según las necesidades de su implementación.

A continuación, ejecute el siguiente comando, que aparece con Access Manager instalado en el directorio predeterminado en los sistemas Solaris:

# cd /opt/SUNWam/bin
# ./amconfig -s /opt/SUNWam/amsilent

Para obtener información y ejemplos adicionales sobre los comandos patchadd y patchrm, consulte las páginas de comando man correspondientes de Solaris.

Consulte también Consideraciones posteriores a la instalación para obtener más información.

Zonas de Solaris 10

El sistema operativo Solaris 10 introdujo el nuevo concepto de “zonas”. Por lo tanto, el comando patchadd incluye la nueva opción -G, que permite agregar una revisión sólo a la zona global. Este comando busca de forma predeterminada la variable SUNW_PKG_ALLZONES en el elemento pkginfo de los paquetes a los que se va a aplicar la revisión. Sin embargo, la variable SUNW_PKG_ALLZONES no se ha establecido para todos los paquetes de Access Manager y la opción -G es necesaria si Access Manager 7 2005Q4 se ha instalado en la zona global. Si Access Manager se ha instalado en una zona local, la opción patchadd -G no tiene ningún efecto.

Si va a instalar las revisiones de Access Manager 7 2005Q4 en un sistema Solaris, se recomienda que utilice la opción -G. Por ejemplo:

 # patchadd -G AM7_patch_dir

Del mismo modo, si Access Manager se ha instalado en la zona global, la opción -G es necesaria para ejecutar el comando patchrm. Por ejemplo:

# patchrm -G 120954-07

Instrucciones de instalación de revisiones para los sistemas Linux

Antes de instalar la revisión de Linux, asegúrese de que ha hecho una copia de seguridad de los archivos enumerados en Consideraciones previas a la instalación.

El comando installpatch instala una revisión en sistema Linux independiente. Por ejemplo:

# ./installpatch

La secuencia de comandos postpatch imprime mensajes similares a los mensajes del sistema Solaris. Sin embargo, el procedimiento para deshacer una revisión en un sistema Linux es diferente al de un sistema Solaris. No existe ninguna secuencia de comandos genérica para deshacer una revisión de Linux. Si se ha instalado anteriormente una versión inferior de la revisión, puede reinstalar esa versión y, a continuación, seguir las instrucciones posteriores a la aplicación de las revisiones para reimplementar las aplicaciones de Access Manager ejecutando la secuencia de comandos amconfig.

Tras ejecutar la secuencia de comandos amconfig, ejecute la secuencia de comandos updateschema.sh (revisión 5 y posteriores) para cargar los archivos XML y LDIF. La secuencia de comandos updateschema.sh está disponible tras la instalación de la revisión 7 en el directorio patch-home-directory/120956-07/scripts .

Tras ejecutar las secuencias de comandos amconfig y updateschema.sh , reinicie el contenedor web de Access Manager.

Si la revisión se ha instalado en la versión Access Manager 7 2005Q4 RTM, y desea eliminarla y restablecer el sistema al estado de RTM, debe reinstalar los bits de RTM de Access Manager mediante la secuencia de comandos reinstallRTM. La secuencia de comandos utiliza la ruta en la que se han almacenado los RPM de RTM de Access Manager e instala los RPM de RTM sobre los RPM a los que se les ha aplicado la revisión. Por ejemplo:

# ./scripts/reinstallRTM path_of_AM7_RTM_RPM_directory

Tras ejecutar la secuencia de comandos reinstallRTM, vuelva a implementar las aplicaciones de Access Manager ejecutando la secuencia de comandos amconfig y reinicie el contenedor web.

Consulte también Consideraciones posteriores a la instalación para obtener más información.

Instrucciones de instalación de revisiones para los sistemas Windows

Entre los requisitos para instalar la revisión de Windows se encuentran:

Instalación de la revisión de Windows

Antes de instalar la revisión de Windows, asegúrese de que ha hecho una copia de seguridad de los archivos enumerados en Consideraciones previas a la instalación.

En la ruta de entrada del directorio base a las secuencias de comandos de revisión, utilice una barra diagonal (/). Por ejemplo: c:/sun

Para instalar la revisión de Windows:

  1. Inicie una sesión en el sistema Windows como miembro del grupo de administradores.

  2. Cree un directorio para descargar y descomprimir el archivo de revisión de Windows. Por ejemplo: AM7p7

  3. Descargue y descomprima el archivo 124296-07.zip en el directorio indicado en el paso anterior.

  4. Detenga todos los servicios de Java ES 2005Q4.

  5. Ejecute la secuencia de comandos AM7p7\scripts\prepatch.pl.

  6. Ejecute AM7p7\124296-07.exe para instalar la revisión.

  7. Ejecute la secuencia de comandos AM7p7\scripts\postpatch.pl.

  8. Reinicie los servicios de Java ES 2005Q4.

  9. Vuelva a implementar las aplicaciones de Access Manager. Consulte Consideraciones posteriores a la instalación para obtener más información.

  10. Ejecute la secuencia de comandos AM7p7\scripts\updateschema.pl para actualizar el esquema de servicios de Directory Server. La secuencia de comandos valida sus entradas y, a continuación, carga los archivos. La secuencia de comandos también escribe el siguiente archivo de registro:

    javaes-install-directory\AccessManager\AM70Patch-upgrade-schema- timestamp

  11. Reinicie los servicios de Java ES 2005Q4.

Cómo deshacer la revisión de Windows

Para deshacer la revisión de Windows:

  1. Inicie una sesión en el sistema Windows como miembro del grupo de administradores.

  2. Ejecute el archivo Uninstall_124296-07.bat.

  3. Ejecute la secuencia de comandos AM7p7\scripts\postbackout.pl.

  4. Vuelva a implementar las aplicaciones de Access Manager.

  5. Reinicie los servicios de Java ES 2005Q4.

Nota: si deshace la revisión, los cambios de esquema agregados por la secuencia de comandos AM7p7\scripts\updateschema.pl no se eliminan de Directory Server. Sin embargo, no es necesario eliminar esos cambios manualmente porque no afectarán a la funcionalidad ni a la facilidad de uso de Access Manager una vez eliminada la revisión.

Instrucciones de instalación de revisiones para los sistemas HP-UX

Para instalar o eliminar la revisión HP-UX, utilice los comandos swinstall y swremove. Por ejemplo, para instalar la revisión en un sistema independiente:

# swinstall /var/spool/patch/126371-07

O bien, para eliminar la revisión de un sistema independiente:

# swremove 126371-07

Para obtener información sobre los comandos swinstall y swremove , consulte las páginas de comando man swinstall y swremove .

Tras instalar o eliminar la revisión, debe volver a implementar las aplicaciones de Access Manager, tal y como se describe en la sección Consideraciones posteriores a la instalación.

Tras volver a implementar las aplicaciones de Access Manager, ejecute la secuencia de comandos updateschema.sh (revisión 5 y revisiones posteriores) para cargar los archivos XML y LDIF. La secuencia de comandos updateschema.sh está disponible tras la instalación de la revisión 7 en el directorio patch-home-directory/120956-07/scripts . Tras ejecutar las secuencias de comandos amconfig y updateschema.sh , reinicie el contenedor web de Access Manager.

Nota: si elimina la revisión, los cambios realizados en el esquema agregados por la secuencia de comandos updateschema.sh no se eliminan de Directory Server. Sin embargo, no es necesario eliminar estos cambios de esquema manualmente, pues la funcionalidad y la facilidad de uso de Access Manager no se verán afectadas una vez que se haya eliminado la revisión.

Para obtener más información sobre la implementación de Access Manager en los sistemas HP-UX, consulte Sun Java System Access Manager 7 2005Q4 Release Notes for HP-UX.

Consideraciones posteriores a la instalación

Entre las consideraciones posteriores a la instalación de la revisión de Access Manager 7 2005Q4, se incluyen:

CR# 6254355: las revisiones de Access Manager no implementan las aplicaciones de Access Manager en las secuencias de comandos posteriores a la aplicación de las revisiones.

Es posible que el programa de instalación de revisiones no conserve algunos de los archivos WAR personalizados y los sustituya por versiones no personalizadas. Para ayudarle a identificar y, a continuación, actualizar manualmente el contenido personalizado de un archivo WAR, tenga en cuenta el siguiente procedimiento.

En los siguientes ejemplos, AccessManager-base es el directorio base de instalación. El directorio base de instalación predeterminado es /opt en los sistemas Solaris y /opt/sun en los sistemas Linux.

En los sistemas Windows, AccessManager-base es javaes-install-directory\AccessManager. Por ejemplo: C:\Program Files\Sun\AccessManager

Los archivos WAR en los que se aplica la revisión son:

Estos archivos se encuentran en AccessManager-base/SUNWam en los sistemas Solaris y AccessManager-base/identity en los sistemas Linux.

En los sistemas Windows: los archivos WAR en los que se aplica la revisión se ubican en AccessManager-base\.

Entre el contenido modificable de un archivo WAR, se incluye:

Para asegurarse de que se conserven todos los cambios personalizados, siga estos pasos. Antes de realizar cambios en un archivo, realice siempre antes una copia de seguridad del mismo.

  1. Instale la revisión.

  2. Expanda los archivos WAR en un directorio temporal. Por ejemplo, con Access Manager instalado en el directorio predeterminado en los sistemas Solaris:

    # cd temporary-directory 
# jar -xvf /opt/SUNWam/console.war
# jar -xvf /opt/SUNWam/services.war
# jar -xvf /opt/SUNWam/password.war

  3. Compruebe los archivos expandidos para ver si el programa de instalación de revisiones ha realizado algún cambio en los archivos personalizados y agregue manualmente los cambios personalizados originales a aquéllos que han sufrido modificaciones en el directorio temporal. No es necesario rehacer los cambios para los archivos que se encuentran en el directorio AccessManager-base/web-src/ , pero que no se han incluido en los archivos WAR a los que se ha aplicado la revisión.

  4. Actualice los archivos WAR con los archivos modificados. Por ejemplo, con Access Manager instalado en el directorio predeterminado en los sistemas Solaris:

    # cd temporary-directory
# jar -uvf /opt/SUNWam/console.war $path/$modified file
# jar -uvf /opt/SUNWam/services.war $path/$modified file
# jar -uvf /opt/SUNWam/password.war $path/$modified file

    Por ejemplo, para los pasos 2-4:

    # mkdir /tmp/war.tmp 
# cd /tmp/war.tmp
# jar -xvf /opt/SUNWam/services.war
# vi index.html
# jar -uvf /opt/SUNWam/services.war index.html

  5. Reutilice el archivo de configuración silenciosa (amsilent) generado por la revisión o cree uno nuevo basado en el archivo de plantilla amsamplesilent y, a continuación, establezca las variables de configuración adecuadas en el archivo, incluidas:

    • DEPLOY_LEVEL=21

    • DIRECTORY_MODE=5

    • Las contraseñas de DS_DIRMGRPASSWD, ADMINPASSWD y AMLDAPUSERPASSWD

    • Las variables del contenedor Web de Access Manager

    En los sistemas Windows, reutilice el archivo de configuración silenciosa (amsilent ) generado por la secuencia de comandos postpatch.pl y asegúrese de que los valores de AccessManager-base\setup\AMConfigurator.properties-tmp son válidos. A continuación cambie el nombre de este archivo a AccessManager-base \setup\AMConfigurator.properties.

    Para obtener más información sobre las variables del contenedor Web, consulte el archivo amsamplesilent en el directorio /opt/SUNWam/bin en los sistemas Solaris o en el directorio /opt/sun/identity/bin en los sistemas Linux.

    En los sistemas Windows, el archivo de configuración es AccessManager-base\setup\AMConfigurator.properties.

  6. Ejecute la secuencia de comandos amconfig como se muestra a continuación. Antes de ejecutar amconfig, deben estar en ejecución Directory Server y el contenedor Web de Access Manager. Por ejemplo, para ejecutar amconfig en un sistema Solaris con Access Manager instalado en el directorio base de instalación predeterminado: 

    # cd /opt/SUNWam/bin 
# ./amconfig -s /opt/SUNWam/amsilent

  7. Después de ejecutar amconfig, reinicie los procesos de Access Manager. Por ejemplo:

    # cd /opt/SUNWam/bin
# ./amserver stop
# ./amserver start

  8. Asegúrese de que todos los archivos JSP personalizados se encuentren en los subdirectorios adecuados en el directorio AccessManager-base/SUNWam/web-src/ en los sistemas Solaris o AccessManager-base /identity/web-src/ en los sistemas Linux, y de que haya realizado una copia de seguridad de todos los archivos personalizados.

    En los sistemas Windows, los archivos se encuentran en AccessManager-base\web-src\ .

  9. Reinicie el contenedor Web de Access Manager.

Para obtener más información acerca de la ejecución de la secuencia de comandos amconfig, consulte el Capítulo 1, Access Manager 7 2005Q4 Configuration Scripts de Sun Java System Access Manager 7 2005Q4 Administration Guide.

CR# 6436409: reimplementación de los archivos WAR de autenticación distribuida y SDK de cliente.

Si utiliza la autenticación distribuida o el SDK de cliente, vuelva a crear e implementar los archivos WAR de autenticación distribuida y de SDK de cliente después de instalar la revisión. Para obtener información, consulte los siguientes documentos:

Revisión 6 de Access Manager 7 2005Q4

La revisión 6 de Access Manager 7 (versión 06) soluciona diversos problemas, como se indica en el archivo README (LÉAME) incluido con la revisión. La revisión 6 también incluye las siguientes nuevas funciones, problemas y actualizaciones de documentación.

Nuevas funciones de la revisión 6

Problemas conocidos y limitaciones de la revisión 6

Nota –

Antes de instalar la revisión 6, se recomienda que actualice o revise los siguientes componentes:

Access Manager es compatible con el método JDK 1.5 HttpURLConnection setReadTimeout

Para admitir el método setReadTimeout, el archivoAMConfig.properties cuenta con la siguiente nueva propiedad para que establezca el valor de tiempo de espera de lectura: 

com.sun.identity.url.readTimeout

Si el contenedor web está utilizando JDK 1.5, establezca esta propiedad en un valor adecuado para que se agote el tiempo de espera de las conexiones y evitar así la presencia de demasiadas conexiones HttpURLConnections abiertas, lo que podría provocar que el servidor se bloquease. El valor predeterminado es de 30.000 milisegundos (30 segundos).

El método setReadTimeout se omitirá si com.sun.identity.url.readTimeout no está presente en el archivo AMConfig.properties o si se ha establecido en una cadena vacía.

Access Manager SDK conmuta por error a la instancia principal de Directory Server una vez que el servidor principal vuelve a estar activo.

Si Sun Java System Directory Server se ha configurado para la repetición de varias réplicas principales (MMR), Access Manager SDK conmutará ahora por error a la instancia principal de Directory Server después de que el servidor principal deje de funcionar y vuelva a estar activo a continuación. Anteriormente, Access Manager SDK seguía accediendo a la instancia secundaria de Directory Server una vez que el servidor principal volvía a estar activo.

Para admitir este nuevo comportamiento, Access Manager incluye la siguiente nueva propiedad en el archivo AMConfig.properties:

com.sun.am.ldap.fallback.sleep.minutes

Esta propiedad establece el tiempo en minutos que la instancia secundaria de Directory Server permanece inactiva antes de que conmute por error al servidor principal una vez que éste vuelve a estar activo. El valor predeterminado es de 15 minutos.

La propiedad com.sun.am.ldap.fallback.sleep.minutes está oculta. Para establecer esta propiedad en un valor distinto del predeterminado (15 minutos), agréguela de forma explícita al archivo AMConfig.properties. Por ejemplo, establezca el valor en 7 minutos:

com.sun.am.ldap.fallback.sleep.minutes=7

Para que el nuevo valor se aplique, reinicie el contenedor web de Access Manager.

Las diferentes instancias de Access Manager se registran en varios archivos.

Las diversas instancias de Access Manager que se ejecutan en el mismo host pueden registrarse ahora en distintos archivos de registro ubicados en diferentes subdirectorios. Para ello, establezca la siguiente nueva propiedad en el archivo AMConfig.properties:

com.sun.identity.log.logSubdir

A menos que cambie el directorio de registro predeterminado en la consola de administración, los directorios de registro predeterminados son:

La primera instancia de Access Manager siempre se registra en el directorio de registro predeterminado. Para especificar subdirectorios de registro diferentes para las instancias adicionales de Access Manager, establezca la propiedad com.sun.identity.log.logSubdir en el archivo AMConfig.properties para cada instancia de Access Manager adicional.

Por ejemplo, si tiene tres instancias, am-instance-1, am-instance-2 y am-instance-3, que se ejecutan en el mismo servidor host de Solaris, establezca la propiedad de la siguiente forma:

com.sun.identity.log.logSubdir=am-instance-2
com.sun.identity.log.logSubdir=am-instance-3

La propiedad com.sun.identity.log.logSubdir está oculta. Debe agregar de forma explícita esta propiedad al archivo AMConfig.properties según sea pertinente y reiniciar el contenedor web de Access Manager para que se apliquen los valores del subdirectorio.

Las instancias de Access Manager se registrarán a continuación en los siguientes directorios:

/var/opt/SUNWam/logs/log-files-for-am-instance-1
/var/opt/SUNWam/logs/am-instance-2/log-files-for-am-instance-2
/var/opt/SUNWam/logs/am-instance-3/log-files-for-am-instance-3

Access Manager 7 permite varios dominios de cookies.

Para admitir varios dominios de cookies, Access Manager presenta la siguiente nueva propiedad:

com.sun.identity.authentication.setCookieToAllDomains

El valor predeterminado es true (verdadero). Esta nueva propiedad está oculta. Para establecer el valor en false (falso), agregue de forma explícita esta propiedad al archivo AMConfig.properties y reinicie el contenedor web de Access Manager.

El complemento posterior a la autenticación de Microsoft IIS 6.0 admite SharePoint Server

El complemento de autenticación de los Servicios de Internet Information Server (IIS) 6.0 de Microsoft admite ahora Microsoft Office SharePoint Server. Un usuario puede iniciar una sesión en Access Manager con un Id. de usuario o un nombre de inicio de sesión. Sin embargo, SharePoint Server sólo acepta un nombre de inicio de sesión, lo que puede provocar problemas cuando el usuario especifique un Id. de usuario.

Para permitir el inicio de sesión en SharePoint Server, el complemento posterior a la autenticación (ReplayPasswd.java) utiliza ahora la siguiente nueva propiedad:

com.sun.am.sharepoint_login_attr_name

Esta nueva propiedad indica el atributo de usuario que usa SharePoint Server para la autenticación. Por ejemplo, la siguiente propiedad especifica el nombre común (cn) para la autenticación: 

com.sun.am.sharepoint_login_attr_name=cn

El complemento posterior a la autenticación lee la propiedad com.sun.am.sharepoint_login_attr_name y obtiene el valor de atributo correspondiente para el usuario de Directory Server. A continuación, el complemento establece los encabezados de autorización para permitir el acceso del usuario a SharePoint Server.

Esta propiedad está oculta. Para establecer la propiedad, agréguela de forma explícita al archivo AMConfig.properties y, a continuación, reinicie el contenedor web de Access Manager para que se aplique el valor.

Access Manager es compatible con Internet Explorer 7

El parche 6 de Access Manager 7 2005Q4 admite ahora Microsoft Windows Internet Explorer 7.

CR# 6379325: el acceso a la consola durante una conmutación por error de una sesión genera una excepción de puntero nulo

En este escenario, varios servidores de Access Manager se implementan en el modo de conmutación por error de sesión detrás de un equilibrador de carga configurado para el enrutamiento de solicitudes persistentes basadas en cookies. El administrador de Access Manager accede a la consola de Access Manager mediante el equilibrador de carga. Cuando el administrador inicie una sesión en la consola, ésta se creará en uno de los servidores de Access Manager. Si el servidor deja de funcionar, se efectuará una conmutación por error de la sesión de la consola en otro servidor de Access Manager según lo previsto. Sin embargo, a veces, el administrador obtiene excepciones de puntero nulo intermitentes en el navegador y en el registro de errores del contenedor web.

Este problema sólo afecta a la sesión activa de la consola de Access Manager durante la conmutación por error y no al funcionamiento de los servidores de Access Manager.

Solución: para evitar que se generen excepciones de puntero nulo intermitentes:

CR# 6508103: en Windows, al hacer clic en Ayuda en la consola de administración, se devuelve un error de aplicación

En Windows 2003 Enterprise Edition con una instancia de Access Manager implementada en Sun Java System Application Server que utiliza una configuración regional distinta al inglés, al hacer clic en Ayuda en el modo de dominio de administración, la consola devuelve un error de aplicación.

Solución:

  1. Copie el archivo javaes-install-dir\share\lib\jhall.jar en el directorio %JAVA_HOME%\jre\lib\ext,

    donde javaes-install-dir es el directorio de instalación de Windows.

  2. Reinicie la instancia de Application Server.

CR# 6564877: la instalación de la revisión de Access Manager 7 sobrescribe los archivos de SAML v2

Si se ha instalado el complemento SAML v2, al instalar la revisión, se sobrescribirán los archivos de SAML v2 relacionados y la secuencia de comandos postpatch mostrará el siguiente mensaje:

La secuencia de comandos posterior a la aplicación de la revisión ha detectado que el complemento SAML v2 se ha instalado en el entorno. Al ejecutar la secuencia de configuración "amconfig" para volver a implementar las aplicaciones de Access Manager, la secuencia de comandos volverá a crear el archivo amserver.war y los archivos de SAML v2 relacionados se perderán. Por lo tanto, después de ejecutar "amconfig", vuelva a crear e implementar el archivo "amserver.war", tal y como se describe en "Sun Java System SAML v2 Plug-in for Federation Services User's Guide".

Solución: después de instalar la revisión y ejecutar la secuencia de comandos amconfig, vuelva a crear e implementar el archivo amserver.war para las implementaciones de Federation Manager o Access Manager que utilicen el complemento SAML v2.

Para conocer los pasos específicos, consulte el Capítulo 2, Installing the SAML v2 Plug-in for Federation Services de Sun Java System SAML v2 Plug-in for Federation Services User’s Guide.

Access Manager 7 2005Q4 revisión 5

Access Manager 7 revisión 5 (versión 05) soluciona diversos problemas, como se indica en el archivo README incluido con la revisión. La revisión 5 también incluye las siguientes nuevas funciones, problemas y actualizaciones de documentación.

Nuevas funciones de la revisión 5

Problemas conocidos y limitaciones de la revisión 5

Problemas de internacionalización (g11n)

Actualizaciones de la documentación

Compatibilidad con los sistemas HP-UX

La revisión 126371 cuenta con compatibilidad con los sistemas HP-UX. Para obtener más información, consulte:

Para obtener información sobre la instalación en sistemas HP-UX, consulte Guía de instalación de Sun Java Enterprise System 2005Q4 para UNIX.

Compatibilidad con sistemas de Microsoft Windows

La revisión 124296 proporciona compatibilidad con los sistemas Windows. Para obtener más información, consulte:

Para obtener información sobre la instalación en sistemas Windows, consulte la Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows .

Nueva secuencia de comandos updateschema.sh para cargar archivos LDIF y XML

La revisión 5 (y posteriores) incluye la secuencia de comandos updateschema.sh, que carga los archivos siguientes para actualizar el esquema de servicio de Directory Server:

En versiones de revisiones anteriores de Access Manager, se le solicitó que cargara estos archivos manualmente.

Para ejecutar la secuencia de comandos updateschema.sh:

  1. Inicie una sesión como superusuario o conviértase en uno (root).

  2. Cambie al directorio de la revisión.

  3. Ejecute la secuencia de comandos. Por ejemplo, en sistemas Solaris:

    # cd /120954-07 
# ./updateschema.sh

    En sistemas Windows, la secuencia de comandos es updateschema.pl.

  4. Cuando la secuencia de comandos se lo solicite, introduzca estos elementos:

    • Nombre de host y número de puerto de Directory Server

    • DN y contraseña de usuario administrativo de Directory Server

    • DN y contraseña amadmin

  5. La secuencia de comandos valida sus entradas y, a continuación, carga los archivos. La secuencia de comandos también escribe el siguiente archivo de registro:

    • Sistemas Solaris: /var/opt/SUMWam/logs/AM70Patch.upgrade.schema. timestamp

    • Sistemas Linux: /var/opt/sun/identity/logs/AM70Patch.upgrade.schema. timestamp

  6. Una vez finalizada la secuencia de comandos, reinicie el contenedor web de Access Manager.

Nota si elimina la revisión 5, los cambios realizados en el esquema agregados por la secuencia de comandos updateschema.sh no se eliminan de Directory Server. Sin embargo, no es necesario eliminar esos cambios manualmente porque no afectarán a la funcionalidad ni a la facilidad de uso de Access Manager una vez eliminada la revisión.

Compatibilidad con valores de tiempo de espera inactivo de sesión de aplicaciones específicas

La revisión 5 permite que distintas aplicaciones tengan valores de tiempo de espera inactivo de diferentes sesiones. En una empresa, puede que algunas aplicaciones necesiten valores de tiempo de espera inactivo de sesión inferiores al tiempo de espera inactivo de sesión especificado en el servicio de sesión. Por ejemplo, suponga que ha establecido el valor de tiempo de espera de inactividad de sesión en el servicio de sesión en 30 minutos, pero una aplicación de RR.HH. debe agotar el tiempo de espera si un usuario ha estado inactivo durante más de 10 minutos.

Los requisitos para utilizar esta función son:

Para usar esta función:

Por ejemplo, considere una directiva http://host.sample.com/hr/*, con esta condición de esquema de autenticación:

Si hay varias directivas definidas para proteger los recursos de la aplicación de RR.HH., debe agregar la condición a todas ellas.

Si un usuario intenta acceder, en una sesión distinta, a la aplicación de RR.HH. protegida por el agente de Access Manager, se le solicitará su autenticación para el esquema LDAP (si aún no se ha autenticado).

Si ya se ha autenticado para el esquema LDAP, podrá acceder sólo si el tiempo es inferior a 10 minutos desde la última autenticación o si el tiempo es inferior a 10 minutos desde el último acceso del usuario a la aplicación de RR.HH. De lo contrario, el usuario debe autenticarse de nuevo para el esquema LDAP para acceder a la aplicación.

CDC Servlet puede implementarse en un servidor de la IU de autenticación distribuida

CDC Servlet puede coexistir con un servidor de la IU de autenticación distribuida en DMZ para habilitar el inicio de sesión único de dominio cruzado (CDSSO). El servidor de Access Manager puede implementarse detrás de un servidor de seguridad, y CDC Servlet se encarga de todo el acceso a Access Manager para habilitar CDSSO en el servidor de la IU de autenticación distribuida. Para habilitar CDSSO, consulte la documentación del agente de directivas específica y realice los siguientes pasos adicionales:

Se puede especificar un dominio cuando el servlet de CDC redirige a la URL de inicio de sesión de Access Manager

Ahora puede especificar un nombre de dominio en el servlet de CDC para que, cuando se produzca el redireccionamiento a la URL de inicio de sesión de Access Manager, el nombre de dominio esté incluido y el usuario pueda iniciar una sesión en el dominio específico. Por ejemplo:

com.sun.am.policy.agents.config.cdcservlet.url=
    http://lb.example.com/amserver/cdcservlet?org=realm1

El certificado de autenticación puede utilizar un valor UPN para asignar un perfil de usuario.

Previamente, el certificado de autenticación utilizó sólo el componente dn en subjectDN para asignar un perfil de usuario. Access Manager ahora permite el valor de nombre principal de usuario (UPN) en SubjectAltNameExt para la asignación de perfiles.

El proceso de cierre de la sesión posterior a la autenticación se produce en un entorno de varios servidores.

Este proceso ahora se produce cuando un usuario finaliza una sesión en un servidor distinto de aquel en el que inició la sesión originalmente en un entorno de varios servidores, con o sin la opción de migración tras error de sesión configurada.

SAML es compatible con una nueva SPI de identificador de nombres.

SAML ahora es compatible con una nueva interfaz de proveedor de servicios (SPI) de identificador de nombres, para que un sitio pueda personalizar el identificador de nombres en la afirmación SAML. Un sitio puede implementar la nueva interfaz NameIdentifierMapper para asignar una cuenta de usuario a un identificador de nombres en el asunto de una afirmación SAML.

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 que permiten especificar el comportamiento de la comprobación de estado del sitio.

Propiedad 

Descripción 

com.sun.identity.urlchecker.invalidate.interval

Intervalo de tiempo en milisegundos para reconocer un sitio que no responde o está inactivo.  

Valor predeterminado: 70.000 milisegundos (70 segundos). 

com.sun.identity.urlchecker.sleep.interval

Intervalo de tiempo en milisegundos que debería permanecer suspendida la comprobación de estado del sitio. 

Valor predeterminado: 30.000 milisegundos (30 segundos). 

com.sun.identity.urlchecker.targeturl

Distintas URL de destino para la comprobación del estado del proceso de Access Manager. 

Valor predeterminado: "/amserver/namingservice".

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 . 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.

El usuario ya no tiene que autenticarse dos veces en la cadena de autenticación.

Considere el siguiente escenario. Un sitio configura una cadena de autenticación con tres módulos LDAP. Todos los módulos se configuran en SUFFICIENT y las opciones iplanet-am-auth-shared-state-enabled y iplanet-am-auth-store-shared-state-enabled se configuran en true. Por ejemplo:

<AttributeValuePair>
   <Value>A-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
   <Value>B-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
   <Value>C-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
</AttributeValuePair>

La revisión 5 agrega la nueva opción iplanet-am-auth-shared-state-behavior-pattern a las opciones de módulo con dos valores posibles: tryFirstPass (default) and useFirstPass.

Para evitar que un usuario tenga que introducir dos veces el Id. de usuario y la contraseña para autenticarse (tal como se describe en el escenario anterior), configure la nueva opción en useFirstPass para todos los módulos de la cadena. Anteriormente, se le solicitó a un usuario que existía sólo en la tercera instancia LDAP que introdujera un Id. de usuario y contraseña dos veces para autenticarse.

Cambios en las secuencias de comandos de ajuste del rendimiento

La revisión 5 incluye estos cambios en las secuencias de comandos de ajuste del rendimiento:

Consulte también CR# 6527663: el valor predeterminado de la propiedad com.sun.identity.log.resolveHostName debe ser false en lugar de true.

Las secuencias de comandos de ajuste son compatibles con un archivo de contraseñas

La revisión 5 permite especificar contraseñas para las secuencias de comandos de ajuste en un archivo de texto. Anteriormente, podía introducir contraseñas sólo como argumento de la línea de comandos, opción que podía producir problemas de seguridad. Para utilizar un archivo de contraseñas, configure las variables siguientes como desee en el archivo:

DS_ADMIN_PASSWORD=DirectoryServer-admin-password
AS_ADMIN_PASSWORD=ApplicationServer8-admin-password

Por ejemplo, para ajustar Application Server 8:

# ./amtune-as8 password-file

donde password-file contiene AS_ADMIN_PASSWORD definido en la contraseña de administrador de Application Server 8.

Las secuencias de comandos de ajuste utilizan la opción -j password-file cuando llaman a las utilidades ldapmodify, ldapsearch, db2index y dsconf de Directory Server.

La secuencia de comandos de ajuste elimina los ACI innecesarios de Directory Server

Si Access Manager 7 2005Q4 está instalado en modo de dominio, se utilizan privilegios de delegación para determinar los permisos de acceso y, por tanto, no son necesarios algunos ACI de Directory Server. La revisión 5 de Access Manager 7 2005Q4 permite eliminar los ACI innecesarios ejecutando la secuencia de comandos amtune-prepareDSTuner. Esta secuencia de comandos lee una lista de ACI del archivo remacis.ldif y, a continuación, llama a la utilidad ldapmodify para eliminarlos.

Puede ejecutar la secuencia de comandos amtune-prepareDSTuner para eliminar los ACI innecesarios de los sistemas Solaris, Linux, HP-UX y Windows. Para obtener más información, incluido cómo ejecutar la secuencia de comandos, consulte la Technical Note: Sun Java System Access Manager ACI Guide .

Las secuencias de comandos de ajuste pueden ajustar el contenedor web del servidor de la IU de autenticación distribuida

Después de implementar el servidor de la IU de autenticación distribuida en un contenedor web, puede ajustar el contenedor web ejecutando las secuencias de comandos de ajuste de Access Manager. Las siguientes secuencias de comandos de ajuste definen la máquina virtual de Java (Java Virtual Machine) y otras opciones de ajuste para el contenedor web correspondiente:

Tabla 2 Secuencias de comandos de ajuste del contenedor web de Access Manager

Contenedor web 

Secuencia de comandos de ajuste 

amtune-ws61

Web Server 6.1 

amtune-as7

Application Server 7 

amtune-as8

Application Server Enterprise Edition 8.1 

Para ajustar un contenedor web para un servidor de la IU de autenticación distribuida:

  1. Como el servidor de Access Manager no está instalado en el sistema en el que está implementado el servidor de la IU de autenticación distribuida, copie la secuencia de comandos de ajuste del contenedor web adecuado (mostrada en la tabla anterior), el archivo de configuración amtune-env y la secuencia de comandos amtune-utils de una instalación de servidor de Access Manager. Si desea ajustar el sistema operativo Solaris o Linux, copie también la secuencia de comandos amtune-os.

  2. Edite los parámetros en el archivo de configuración amtune-env para especificar el contenedor web y las opciones de ajuste. Para ejecutar la secuencia de comandos en modo REVIEW, defina AMTUNE_MODE=REVIEW en el archivo amtune-env .

  3. Ejecute la secuencia de comandos de ajuste del contenedor web en modo REVIEW. En modo REVIEW, la secuencia de comandos sugiere cambios de ajuste basados en los valores del archivo amtune-env pero no realiza ningún cambio en la implementación.

  4. Revise las recomendaciones de ajuste en el archivo de registro de depuración. Si es necesario, haga cambios en el archivo amtune-env basados en esta ejecución.

  5. Para hacer cambios de ajuste, defina AMTUNE_MODE=CHANGE en el archivo amtune-env.

  6. Ejecute la secuencia de comandos de ajuste en modo CHANGE para realizar los cambios de ajuste en la implementación.

Para obtener más información acerca de la ejecución de la secuencia de comandos de ajuste para ajustar un contenedor web de Access Manager, consulte el Capítulo 2, Access Manager Tuning Scripts de Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide.

La secuencia de comandos única amtune-os ajusta los SO Solaris y Linux

La revisión 5 incluye una secuencia de comandos única amtune-os para ajustar ambos SO. La secuencia de comandos determina el tipo de SO del comando uname -s. Anteriormente, Access Manager proporcionaba secuencias de comandos amtune-os individuales para ajustar cada SO.

Las secuencias de comandos de ajuste se ejecutan hasta su finalización en una zona local de Solaris 10

Si Access Manager está instalado en una zona local de Solaris 10, todas las secuencias de comandos de ajuste excepto amtune-os pueden ejecutarse en la zona local. En una zona local, la secuencia de comandos amtune-os muestra un mensaje de advertencia pero no ajusta el SO. La secuencia de comandos continúa ejecutando otras secuencias de comandos de ajuste que usted haya solicitado. Anteriormente, en una zona local, la secuencia de comandos amtune-os se cancelaría, además de no ejecutarse las posteriores secuencias de comandos de ajuste solicitadas.

En una zona global de Solaris 10, la secuencia de comandos amtune llama a amtune-os para ajustar el SO además de otras secuencias de comandos que haya solicitado.

Las secuencias de comandos de ajuste están disponibles para sistemas Windows

La revisión 5 incluye secuencias de comandos de ajuste para sistemas Windows. La ejecución de secuencias de comandos de ajuste en un sistema Windows es similar a la ejecución de las secuencias de comandos en un sistema Solaris o Linux, con estas diferencias:

Consideraciones de ajuste para servidores Sun Fire T1000 y T2000

Si Access Manager está instalado en un servidor Sun Fire T1000 o T2000, las secuencias de comandos de ajuste de la revisión 5 para Web Server 6.1 y Application Server 8 definen el parámetro JVM GC ParallelGCThreads en 8:

-XX:ParallelGCThreads=8

Este parámetro reduce el número de subprocesos de liberación de recursos, que podría ser innecesariamente elevado en un sistema compatible con 32 subprocesos. Sin embargo, puede incrementar el valor a 16 o incluso 20 para una CPU virtual de 32 como, por ejemplo, un servidor Sun Fire T1000 o T2000, si minimiza todas las actividades de liberación de recursos.

Además, para los sistemas Solaris SPARC con un procesador CMT con tecnología CoolThreads, se recomienda que agregue la siguiente propiedad al final del archivo /etc/opt/SUNWam/config/AMConfig.properties:

com.sun.am.concurrencyRate=value

El value predeterminado es 16, pero puede definir esta propiedad en un valor inferior, dependiendo del número de núcleos del servidor Sun Fire T1000 o T2000.

Autenticación básica en el agente de directivas de IIS 6.0

Para habilitar la autenticación básica en Microsoft Internet Information Services (IIS) 6.0, el agente de directivas debe obtener el nombre de usuario y la contraseña. La revisión 5 incluye las siguientes nuevas clases que habilitan esta funcionalidad utilizando cifrado DES de la contraseña del usuario.

Para utilizar la autenticación básica en IIS 6.0, debe realizar estos pasos tanto en el servidor de Access Manager como en el agente de directivas de IIS 6.0.

En el servidor de Access Manager:

  1. Ejecute DESGenKey.java para generar una clave de cifrado exclusiva para el cifrado y el descifrado de la contraseña. En los sistemas Solaris, el archivo DESGenKey.java se ubica en el directorio com/sun/identity/common , incluido en am_sdk.jar en el directorio /opt/SUNWam/lib. Por ejemplo, el siguiente comando genera una clave de cifrado:

    # cd /opt/SUNWam/lib
# java -cp am_sdk.jar com.sun.identity.common.DESGenKey

  2. Asigne un valor de clave de cifrado del Paso 1 a la propiedad com.sun.am.replaypasswd.key del archivo AMConfig.properties.

  3. Implemente ReplayPasswd.java como un complemento posterior a la autenticación. Utilice el nombre de clase completo cuando configure el complemento: com.sun.identity.authentication.spi.ReplayPasswd .

En el agente de directivas de IIS 6.0:

  1. Asigne el valor de clave de cifrado del servidor a la propiedad com.sun.am.replaypasswd.key del archivo AMAgent.properties . Tanto el servidor de Access Manager como el agente de directivas de IIS 6.0 deben utilizar la misma clave de cifrado.

  2. Habilite la autenticación básica en IIS 6.0 Manager.

El agente de directivas de IIS 6.0 lee la contraseña cifrada de la respuesta de sesión, descifra la contraseña de la propiedad com.sun.am.replaypasswd.key y configura los encabezados de autenticación para que la autenticación básica comience a funcionar.

Para obtener más información acerca del agente de directivas de IIS 6.0, consulte Sun Java System Access Manager Policy Agent 2.2 Guide for Microsoft Internet Information Services 6.0 .

CR# 6567746: en los sistemas HP-UX, la revisión 5 de Access Manager informa de un valor incorrecto de "errorCode" si se supera el recuento de reintentos de introducción de la contraseña

Cuando se bloquea una cuenta de usuario, la revisión 5 de Access Manager 7 2005Q4 en los sistemas HP-UX informa de errorCode = null en lugar de errorCode = 107 si se supera el recuento de reintentos de introducción de la contraseña.

Solución. Ninguna.

CR# 6527663: el valor predeterminado de la propiedad com.sun.identity.log.resolveHostName debe ser false en lugar de true

Antes de ejecutar la secuencia de comandos de ajuste amtune-identity, se recomienda que agregue la siguiente propiedad definida en false al archivo AMConfig.properties:

com.sun.identity.log.resolveHostName=false

Un valor false minimiza el impacto de resolver nombres de host y, por tanto, puede mejorar el rendimiento. Sin embargo, si desea que el nombre de sistema anfitrión del equipo cliente se imprima en el registro amAuthentication.access, establezca el valor en true.

CR# 6527528: la eliminación de la revisión deja los archivos XML con la contraseña amldapuser en texto sin formato

Si elimina la revisión 5 de una instalación de servidor completo de Access Manager, los archivos amAuthLDAP.xml y amPolicyConfig.xml contienen la contraseña amldapuser en texto sin formato. Estos archivos se encuentran en el siguiente directorio, dependiendo de la plataforma:

Solución: Edite los archivos amAuthLDAP.xml y amPolicyConfig.xml y elimine la contraseña de texto sin formato.

CR# 6527516: el servidor completo en WebLogic necesita archivos JAR JAX-RPC 1.0 para comunicarse con el SDK de cliente

En las revisiones de Access Manager 7 2005Q4, la secuencia de comandos de configuración de Access Manager para BEA WebLogic Server (amwl81config) agrega los archivos JAR JAX-RPC 1.1 a la classpath de la instancia WebLogic. Aunque esta modificación es beneficiosa para productos como Sun Java System Portal Server, una instalación de servidor completo (DEPLOY_LEVEL=1) implementado en WebLogic Server no puede comunicarse con una instalación de SDK de cliente y, posteriormente, se producirán excepciones.

Si el servidor de Access Manager 7 2005Q4 está instalado en BEA WebLogic Server, la CLASSPATH de la secuencia de comandos startWebLogic.sh debe configurarse en la ubicación de los archivos JAR JAX-RPC 1.0 para comunicarse con el SDK de cliente de Access Manager.

Solución: antes de aplicar la revisión de Access Manager, establezca la ruta de clase, CLASSPATH, en la secuencia de comandos startWebLogic.sh para que la instancia de WebLogic Server utilice los archivos JAR de JAX-RPC 1.0 en lugar de los archivos JAR de JAX-RPC 1.1:

  1. En el servidor de Access Manager, inicie una sesión como superusuario o conviértase en uno (root).

  2. Edite la secuencia de comandos startWebLogic.sh y sustituya la CLASSPATH para utilizar los archivos JAR JAX-RPC 1.0. Por ejemplo:

Valor actual:

CLASSPATH=/etc/opt/SUNWam/config:
AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar:
AccessManager-base/AccessManager-package-dir/lib/namespace.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-api.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-spi.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-impl.jar:

Valor nuevo:

CLASSPATH=/etc/opt/SUNWam/config:
AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar:
AccessManager-base/AccessManager-package-dir/lib/namespace.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc_1.0/jaxrpc-api.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-ri.jar:

donde AccessManager-base es el directorio base de instalación. El valor predeterminado es /opt en los sistemas Solaris y /opt/sun en los sistemas Linux y HP-UX. AccessManager-package-dir es el directorio de paquetes de Access Manager.

5. Reinicie la instancia de WebLogic Server.

CR # 6523499: el archivo amsilent de la revisión 5 puede ser leído por todos los usuarios en los sistemas Linux

En los sistemas Linux. la secuencia de comandos postpatch crea el archivo /opt/sun/identity/amsilent con los permisos 644, opción que permite que todos los usuarios tengan acceso de lectura.

Solución: Una vez ejecutada la secuencia de comandos installpatch, cambie los permisos del archivo amsilent para que sólo el propietario tenga acceso de lectura y escritura. Por ejemplo:

# chmod 600 /opt/sun/identity/amsilent

CR# 6520326: la aplicación de la revisión 5 a una segunda instancia de Access Manager en un servidor sobrescribe serverconfig.xml en la primera instancia

En este escenario de implementación, dos instancias de Access Manager se instalan en el mismo servidor del sistema anfitrión, con cada instancia en una instancia de contenedor web distinto. A continuación siga estos pasos:

  1. Aplique la revisión 5.

  2. Modifique el archivo amsilent y vuelva a implementar la primera instancia de Access Manager.

  3. Modifique el archivo amsilent de nuevo para la segunda instancia de Access Manager y, a continuación, vuelva a implementar esa instancia.

Si NEW_INSTANCE=false en el archivo amsilent, el archivo serverconfig.xml de la primera instancia de Access Manager se sobrescribe con la información de la segunda instancia de Access Manager. Falla un reinicio posterior de la primera instancia de Access Manager. El archivo serverconfig.xml se encuentra en el siguiente directorio dependiendo de su plataforma:

Solución: Si implementa la segunda instancia de Access Manager, establezca NEW_INSTANCE=true en el archivo amsilent. El archivo serverconfig.xml de la segunda instancia de Access Manager se actualiza con la información correcta, y el archivo serverconfig.xml de la primera instancia de Access Manager no se sobrescribe.

CR# 6520016: la instalación sólo de SDK de la revisión 5 sobrescribe los archivos MAKE de ejemplos

La aplicación de la revisión 5 a un equipo sólo de SDK sobrescribe los archivos MAKE de ejemplos.

Solución: La aplicación de la revisión 5 a un equipo sólo de SDK no necesita una reconfiguración; sin embargo, si desea utilizar los archivos MAKE de ejemplos, siga estos pasos para actualizar los archivos LDIF y de propiedades (es decir, realice un intercambio de etiquetas) de los archivos MAKE de ejemplos:

  1. Ejecute la secuencia de comandos amconfig con DEPLOY_LEVEL=14 para desinstalar SDK y desconfigurar el contenedor web.

  2. Ejecute la secuencia de comandos amconfig con DEPLOY_LEVEL=4 para reinstalar SDK y volver a configurar el contenedor web.

CR#6515502: el complemento de depósito LDAPv3 no siempre administra correctamente el atributo de búsqueda de alias

Para la mayoría de las búsquedas, este problema se ha solucionado. Sin embargo, tenga cuidado cuando configure el atributo de búsqueda de alias. El valor de los atributos de búsqueda de alias debe ser exclusivo en una organización. Si se configura más de un atributo de búsqueda de alias, es posible que una entrada del almacén de datos coincida con un atributo y que otra entrada coincida con el otro atributo. En esta situación, el servidor de Access Manager emite el siguiente error:

An internal authentication error has occurred. Contact your system administrator.

Solución: Ninguna

CR# 6515383: la autenticación distribuida y el agente J2EE no funcionan en el mismo contenedor web

Un servidor de la IU de autenticación distribuida y un agente de directivas J2EE no funcionan si están instalados en el mismo contenedor web.

Solución: Cree una instancia de un segundo contenedor web e implemente el servidor de la IU de autenticación distribuida y el agente de directivas J2EE en distintas instancias del contenedor.

CR# 6508103: la ayuda en línea devuelve un error de aplicación con Application Server en los sistemas Windows

Si implementa Access Manager en Sun Java System Application Server en un sistema Windows, al hacer clic en la Ayuda del panel izquierdo de la pantalla de ayuda de la consola en modo de dominio aparece un error de aplicación.

Solución: copie el archivo javaes-install-dir\share\lib\jhall.jar en el directorio JAVA_HOME\jre\lib\ext y, a continuación, reinicie Application Server.

CR# 6507383 and CR# 6507377: la autenticación distribuida necesita el parámetro de URL goto explícito

Si no se especifica un parámetro de URL goto específico, un servidor de la IU de autenticación distribuida intenta redirigir al parámetro goto en una URL satisfactoria especificada en Access Manager. Este redireccionamiento puede fallar por estos motivos:

Solución: Especifique siempre un parámetro de URL goto explícito para un servidor de la IU de autenticación distribuida.

CR# 6402167: LDAP JDK 4.18 causa problemas en el cliente LDAP/Directory Server

Access Manager 7 2005Q4 fue lanzado con LDAP JDK 4.18 como parte de la revisión de Java ES 2005Q4, que causó una serie de problemas de conexión de Access Manager y Directory Server.

Solución: Aplique una de las siguientes revisiones de Java Development Kit de Sun Java System LDAP:

Las revisiones están disponibles en SunSolve Online: http://sunsolve.sun.com.

CR# 6352135: los archivos del servidor de la IU de autenticación distribuida se instalan en una ubicación incorrecta

En los sistemas Solaris, el programa de instalación de Java ES instala el servidor de la IU de autenticación distribuida Makefile.distAuthUI, README.distAuthUI y los archivos amauthdistui.war en una ubicación incorrecta: /opt/SUNComm/SUNWam.

Solución: Copie estos archivos en la ubicación correcta: /opt/SUNWam.

Nota: cualquier problema de servidor de la IU de autenticación distribuida solucionado en una revisión se reflejará en el archivo /opt/SUNComm/SUNWam/amauthdistui.war , así que siempre que aplique una revisión en el servidor de Access Manager y, a continuación, genere de nuevo e implemente el archivo WAR, también debe copiar estos archivos en el directorio /opt/SUNWam.

CR# 6522720: la búsqueda en la ayuda en línea de la consola no funciona con caracteres de varios bytes en los sistemas Windows y HP-UX

Si se instala Access Manager en un idioma que utilice caracteres de varios bytes (como, por ejemplo, japonés) en un sistema Windows o HP-UX, no funcionará la búsqueda en la ayuda en línea de la consola con palabras clave introducidas utilizando caracteres de varios bytes.

Solución: Ninguna

Actualización de la revisión 6: la revisión 6 de Access Manager 7 2005Q4 soluciona este problema en los sistemas Windows. Sin embargo, el problema aún persiste en los sistemas HP-UX.

CR# 6524251: los caracteres de varios bytes en los mensajes de salida están distorsionados durante la configuración de Access Manager en los sistemas Windows

Si se instala Access Manager en un idioma que utilice caracteres de varios bytes (como, por ejemplo, japonés o chino) en un sistema Windows, durante la configuración de Access Manager, las palabras se distorsionan en los mensajes de salida en la ventana de terminal.

Solución: Ninguna, pero este problema no afecta a la configuración.

CR# 6526940: las claves de propiedad aparecen en lugar del texto del mensaje durante la instalación de la revisión 5 en idiomas diferentes del inglés en los sistemas Windows

Si instala la revisión 5 (124296-05) en un idioma distinto del inglés en un sistema Windows, algunas cadenas de los paneles de instalación aparecen como claves de propiedad en lugar del texto del mensaje. Ejemplos de claves de propiedad son PRODUCT_NAME, JES_Patch_FinishPanel_Text1 y JES_Patch_FinishPanel_Text2.

Solución: Ninguna

CR# 6513653: problema con la configuración de la propiedad com.iplanet.am.session.purgedelay

La secuencia de comandos amtune de Access Manager configura la propiedad com.iplanet.am.session.purgedelay en 1, para permitir el mayor número posible de sesiones de Access Manager. Esta propiedad especifica el número de minutos de retraso de la operación de sesión de purga. Sin embargo, para clientes como, por ejemplo, Sun Java System Portal Server, no es suficiente un valor de 1.

Solución: Restablezca la propiedad com.iplanet.am.session.purgedelay una vez ejecutada la secuencia de comandos amtune:

  1. En el archivo AMConfig.properties, defina la propiedad en el nuevo valor. Por ejemplo:

    com.iplanet.am.session.purgedelay=5

  2. Reinicie el contenedor web de Access Manager para que se aplique el nuevo valor.

Revisión 4 de Access Manager 7 2005Q4

La revisión 4 de Access Manager 7 2005Q4 (versión 04) soluciona los siguientes problemas:

Problemas conocidos y limitaciones de la revisión 4

CR# 6470055: mejora del rendimiento del servidor de la IU de autenticación distribuida

Para mejorar el rendimiento en la lectura, búsqueda y comparación de atributos de usuario para un usuario de servidor de la IU de autenticación distribuida, siga estos pasos:

  1. En el archivo Makefile.distAuthUI, cambie el nombre de usuario de la aplicación de anonymous a otro usuario. Por ejemplo: 

    APPLICATION_USERNAME=user1

  2. En Directory Server, agregue el nuevo usuario (user1 en el ejemplo) y ACI para permitir la lectura, búsqueda y comparación de atributos de usuario. El siguiente ejemplo agrega el nuevo ACI:

    dn:ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com 
changetype:modify add:aci 
aci: (target="ldap:///ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com")
(targetattr = *")(version 3.0; 
acl "SunAM client data access to a Distributed Auth App User"; 
allow (read, search, compare) 
userdn =  "ldap:///uid=user1,ou=people,dc=example,dc=com";)

CR# 6455079: el servicio de restablecimiento de contraseña informa de errores de notificación cuando se modifica una contraseña

Cuando se modifica una contraseña, Access Manager envía una notificación por correo electrónico utilizando un nombre de remitente inadecuado Identity-Server que da lugar a entradas de errores en los registros de amPasswordReset. Por ejemplo:

07/19/2006 10:26:04:010 AM PDT: Thread[service-j2ee,5,main]
ERROR: Could not send email to user [Ljava.lang.String;@999262
com.sun.mail.smtp.SMTPSendFailedException: 553 5.5.4 <Identity-Server>...
Domain name required for sender address Identity-Server

Solución: cambie la dirección del remitente para que incluya el nombre de dominio completo del servidor host en el archivo amPasswordResetModuleMsgs.properties :

  1. cambie la etiqueta de dirección del remitente. Por ejemplo:

    fromAddress.label=<Identity-Server@amhost.example.com>

  2. Cambie la propiedad lockOutEmailFrom para garantizar que las notificaciones de bloqueo utilicen la dirección del remitente correcta. Por ejemplo:

    lockOutEmailFrom=<Identity-Server@amhost.example.com>

    El archivo amPasswordResetModuleMsgs.properties está en el directorio AccessManager-base/SUNWam/locale en los sistemas Solaris y en el directorio AccessManager-base/identity/locale en los sistemas Linux.

    AccessManager-base es el directorio base de instalación. El directorio base de instalación predeterminado es /opt en los sistemas Solaris y /opt/sun en los sistemas Linux.

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.

Revisión 2 de Access Manager 7 2005Q4

La revisión 2 de Access Manager 7 (versión 02) 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:

New Features in Patch 2

Problemas conocidos y limitaciones de la revisión 2

Nuevas propiedades de las cachés de administración de usuarios, repositorio de identidades y administración de servicios

La revisión 2 incluye las siguientes nuevas propiedades para las cachés de administración de usuarios, el repositorio de identidades (IdRepo) y la administración de usuarios (SDK de Access Manager). Estas propiedades permiten habilitar y deshabilitar de forma independiente las diferentes cachés en función de los requisitos de implementación, y establecer el periodo de vida (TTL, Time To Live) de las entradas de la caché.

Tabla 3 Nuevas propiedades de las cachés de administración de usuarios, repositorio de identidades y administración de servicios

Propiedad 

Descripción 

Nuevas propiedades para habilitar y deshabilitar las cachés

com.iplanet.am.sdk.caching.enabled

Propiedad global que habilita (true) o deshabilita (false) las cachés del repositorio de identidades (IdRepo), la administración de usuarios y la administración de servicios. Si se establecer como true (verdadero), o si la propiedad no está presente en el archivo AMConfig.properties, se habilitan las tres cachés.

Nota Las siguientes tres propiedades para habilitar o deshabilitar las cachés específicas sólo se aplican si la propiedad global anterior se establece en false (falso).

com.sun.identity.amsdk.cache.enabled

Habilita (true) o deshabilita (false) únicamente la caché de administración de usuarios (Access Manager SDK). 

com.sun.identity.idm.cache.enabled

Habilita (true) o deshabilita (false) sólo la caché del repositorio de identidades (IdRepo). 

com.sun.identity.sm.cache.enabled

Habilita (true) o deshabilita (false) sólo la caché de administración de servicios. 

Nuevas propiedades de la caché de administración de usuarios para TTL

com.iplanet.am.sdk.cache.entry.expire.enabled

Habilita (true) o deshabilita (false) la caducidad (tal y como se define en las dos propiedades siguientes) para la caché de administración de usuarios. 

com.iplanet.am.sdk.cache.entry.user.expire.time

Especifica el tiempo en minutos que las entradas de usuario de la caché de administración de usuarios seguirán siendo válidas desde su última modificación. Es decir, una vez transcurrido el periodo de tiempo especificado (después de la última modificación o lectura desde el directorio), los datos de la entrada almacenada en la caché caducarán. Las solicitudes de datos de dichas entradas deberán leerse desde el directorio. 

com.iplanet.am.sdk.cache.entry.default.expire.time

Especifica el tiempo en minutos que las entradas de la caché de administración de usuarios que no son de usuario seguirán siendo válidas desde su última modificación. Es decir, una vez transcurrido el periodo de tiempo especificado (después de la última modificación o lectura desde el directorio), los datos de la entrada almacenada en la caché caducarán. Las solicitudes de datos de dichas entradas deberán leerse desde el directorio. Nuevas propiedades de la caché del repositorio de identidades para TTL  

com.sun.identity.idm.cache.entry.expire.enabled

Habilita (true) o deshabilita (false) la caducidad (como se define en la siguiente propiedad) para la caché de IdRepo.  

com.sun.identity.idm.cache.entry.default.expire.time

Especifica el tiempo en minutos que las entradas de la caché de IdRepo que no son de usuario seguirán siendo válidas desde su última modificación. Es decir, una vez transcurrido el periodo de tiempo especificado (después de la última modificación o lectura desde el repositorio), los datos de la entrada almacenada en la caché caducarán. Las nuevas solicitudes de datos de dichas entradas deberán leerse desde el repositorio. 

Using the New Caching Properties

Las revisiones de Access Manager 7 2005Q4 no actualizan automáticamente las nuevas propiedades de caché en el archivo AMConfig.properties.

Para utilizar las nuevas propiedades de caché:

  1. Con un editor de textos, 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

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

Nueva propiedad para el proveedor de servicios de federación

La nueva propiedad com.sun.identity.federation.spadapter define la clase de implementación para com.sun.identity.federation.plugins.FederationSPAdapter , que se utiliza para agregar el procesamiento específico de la aplicación durante el procesamiento de la federación en el proveedor de servicios.

Consulte también CR# 6385696: los IDP y SP nuevos y existentes no están visibles..

Compatibilidad con la condición de filtro LDAP

Se ha agregado la compatibilidad con la condición de filtro LDAP en la revisión 2. Un administrador de directivas puede ahora especificar un filtro LDAP en la condición al definir una directiva. La directiva sólo se aplica al usuario si la entrada LDAP del usuario satisface el filtro LDAP especificado en la condición. La entrada LDAP del usuario se consulta desde el directorio especificado en el servicio de configuración de directivas.

Para registrar y utilizar la condición de filtro LDAP, ejecute los siguientes comandos una vez instalada la revisión 2 de Access Manager 7 que aparece con Access Manager instalado en el directorio predeterminado en los sistemas Solaris:

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-s /etc/opt/SUNWam/AddLDAPFilterCondition.xml
# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/amPolicyConfig_mod_ldfc.xml

Nota sobre la revisión 5 si agregó la revisión 5 de Access Manager 7 2005Q4 y ejecutó la secuencia de comandos updateschema.sh, no es necesario cargar estos archivos utilizando amadmin. Para obtener más información consulte Nueva secuencia de comandos updateschema.sh para cargar archivos LDIF y XML.

CR# 6283582: el número de fallos de inicio de sesión no se comparte entre las instancias de Access Manager.

Una vez instalada la revisión 2 de Access Manager 7, ejecute los siguientes comandos que aparecen con Access Manager instalado en el directorio predeterminado en los sistemas Solaris:

# cd DirectoryServer-base/shared/bin
# ./ldapmodify -h DirectoryServerHost -p DirectoryServerPort 
-D "cn=Directory Manager" -w DirectoryMangerPassword 
-a -f /etc/opt/SUNWam/accountLockout.ldif
# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/accountLockoutData.xml

El valor predeterminado de DirectoryServer-base es /var/opt/mps/serverroot en los sistemas Solaris y /var/opt/sun/directory-server en los sistemas Linux.

Nota sobre la revisión 5 si agregó la revisión 5 de Access Manager 7 2005Q4 y ejecutó la secuencia de comandos updateschema.sh, no es necesario cargar estos archivos utilizando amadmin. Para obtener más información consulte Nueva secuencia de comandos updateschema.sh para cargar archivos LDIF y XML.

CR# 6293673: es necesario conservar la información de sesión original al enviar la notificación de tiempo de espera de sesión agotado.

La nueva propiedad com.sun.identity.session.property.doNotTrimList del archivo AMConfig.properties puede contener una lista de nombres de propiedades de sesión separados por comas. Una vez agotado el tiempo de espera de una sesión, las propiedades definidas en esta lista no se recortarán, para que se pueda acceder a ellas antes de que se purgue la sesión. Por ejemplo:

com.sun.identity.session.property.doNotTrimList=UserId,HostName

CR# 6244578: Access Manager debería avisar al usuario de que la compatibilidad con las cookies del explorador se ha deshabilitado o no está disponible.

La nueva propiedad com.sun.identity.am.cookie.check del archivo AMConfig.properties indica si el servidor debe comprobar si existe compatibilidad con las cookies o si las cookies están habilitadas en el explorador. El valor true (verdadero) provoca que el servidor compruebe la compatibilidad con las cookies o si éstas están habilitadas en el explorador, y genera una página de error en caso de que no exista compatibilidad o no estén habilitadas. Este valor debería establecerse como "false" (falso), que es el valor predeterminado, si se espera que el servidor admita el modo sin cookies para la función de autenticación.

CR# 6236892: se muestra un marcador de imagen/texto mientras CDCServlet procesa AuthNResponse tras el inicio de sesión.

CDCServlet agrega las siguientes propiedades a AMConfig.properties y las lee:

CR# 6363157: la nueva propiedad deshabilita las búsquedas persistentes si son absolutamente necesarias

La nueva propiedad com.sun.am.event.connection.disable.list del archivo AMConfig.properties especifica la conexión que puede deshabilitarse. Los valores (no se distingue entre mayúsculas y minúsculas) pueden ser:

aci - Cambios del atributo aci con la búsqueda utilizando el filtro LDAP (aci=*)

sm - Cambios en el árbol de información de Access Manager (o nodo de administración de servicios), que incluye objetos con la clase de objeto de marcador sunService o sunServiceComponent. Por ejemplo, puede crear una directiva que defina privilegios de acceso a un recurso protegido o puede modificar las reglas, temas, condiciones o proveedores de respuesta de una directiva existente.

um - Cambios en el directorio de usuario (o nodo de administración de usuarios). Por ejemplo, puede cambiar el nombre o la dirección del usuario.

Por ejemplo, para deshabilitar las búsquedas persistentes de cambios en el árbol de información de Access Manager (o nodo de administración de servicios):

com.sun.am.event.connection.disable.list=sm

Para especificar varios valores, separe cada valor con una coma.

Precaución – Precaución –

Las búsquedas persistentes causan una sobrecarga en el rendimiento en Directory Server. Si cree que el hecho de eliminar parte de esta sobrecarga en el rendimiento es muy importante en un entorno de producción, puede deshabilitar una o más búsquedas persistentes utilizando la propiedad com.sun.am.event.connection.disable.list.

Sin embargo, antes de deshabilitar una búsqueda persistente, debe comprender las limitaciones descritas anteriormente. Se recomienda que no se modifique esta propiedad a menos que sea absolutamente necesario. Esta propiedad fue introducida principalmente para evitar la sobrecarga en Directory Server cuando se utilizan varios agentes J2EE 2.1, porque cada uno de estos agentes establece estas búsquedas persistentes. Los agentes J2EE 2.2 ya no establecen estas búsquedas persistentes, así que puede que no sea necesario utilizar esta propiedad.

Para obtener más información, consulte Información acerca de la deshabilitación de búsquedas persistentes (6486927).

CR# 6385696: los IDP y SP nuevos y existentes no están visibles.

La nueva propiedad com.sun.identity.federation.spadapter del archivo AMConfig.properties especifica la implementación predeterminada del adaptador del proveedor de servicios de federación en el que la aplicación puede obtener la información de aserciones y de respuesta. Por ejemplo:

com.sun.identity.federation.spadapter=com.sun.identity.federation.plugins.FSDefaultSPAdapter

Revisión 1 de Access Manager 7 2005Q4

La revisión 1 de Access Manager 7 (versión 01) 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:

Creación de archivos de depuración

Los archivos de depuración de Access Manager se crean de forma predeterminada en el directorio de depuración, incluso aunque la propiedad com.iplanet.services.debug.level del archivo AMConfig.properties se haya establecido en error. Antes del lanzamiento de la revisión 1 de Access Manager 7, sólo se creaba un archivo de depuración al registrar el primer mensaje de depuración en el archivo.

Compatibilidad con los roles y los roles filtrados en el complemento LDAPv3

La revisión 1 de Access Manager proporciona compatibilidad con los roles y los roles filtrados en el complemento LDAPv3 si los datos se han almacenado en Sun Java System Directory Server. Para obtener más información, consulte Información sobre la compatibilidad de los roles y los roles filtrados con el complemento LDAPv3 (6365196).

CR# 6320475: la propiedad com.iplanet.am.session.client.polling.enable del servidor no debe ser "true" (verdadera).

La propiedad com.iplanet.am.session.client.polling.enable del archivo AMConfig.properties del servidor se establece como "false" (falsa) de forma predeterminada y nunca debe restaurarse a "true" (verdadera).

CR# 6358751: la aplicación de la revisión 1 de Access Manager 7 falla si hay espacios incrustados en la clave de cifrado.

Si la clave de cifrado de la contraseña contiene espacios, no se podrá aplicar la revisión.

Solución. Utilice una nueva clave de cifrado que no incluya espacios. Para obtener los pasos detallados para cambiar la clave de cifrado, consulte: Apéndice B, Changing the Password Encryption Key de Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.