test

Notes de version de Sun Java System Access Manager 7 2005Q4

Access Manager 7 2005Q4 Patch 3

Le patch 3 (révision 3) d'Access Manager 7 résout de nombreux problèmes, répertoriés dans le fichier LISEZMOI accompagnant le patch. Le patch 3 inclut également les nouvelles fonctions et problèmes connus suivants :

Nouvelles fonctions du patch 3

Problèmes et restrictions connus du patch 3

Nouvelles propriétés de configuration pour le contrôle de site

La fonction de contrôle de site d'Access Manager inclut les nouvelles propriétés suivantes :

Propriété 

Description 

com.sun.identity.sitemonitor.interval

Intervalle de contrôle de site exprimé en millisecondes. La fonction de contrôle de site vérifie la disponibilité de chaque site dans l'intervalle de temps spécifié. Par défaut : 6 0000 millisecondes (1 minute). 

com.sun.identity.sitemonitor.timeout

Délai de vérification de la disponibilité du site exprimé en millisecondes. La fonction de contrôle de site attend une réponse du site pendant le délai spécifié. Par défaut : 5 000 millisecondes (5 secondes).  

Le patch n'ajoute pas ces propriétés au fichier AMConfig.properties . Pour utiliser ces nouvelles propriétés avec des valeurs autres que celles par défaut :

  1. Ajoutez les propriétés et leurs valeurs au fichier AMConfig.properties dans le répertoire suivant, en fonction de votre plate-forme :

    • Systèmes Solaris : /etc/opt/SUNWam/config

    • Systèmes Linux : /etc/opt/sun/identity/config

    Pour les agents de stratégie, ajoutez ces propriétés au fichier AMAgents.properties .

  2. Redémarrez le conteneur Web d'Access Manager pour appliquer les valeurs.

Mise en œuvre personnalisée. La classe com.sun.identity.sitemonitor.SiteStatusCheck vous permet en outre de personnaliser votre mise en œuvre de vérification de la disponibilité du site à l'aide de l'interface suivante :

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

Chaque classe de mise en œuvre doit utiliser la méthode doCheckSiteStatus.

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

Prise en charge de Liberty Identity Web Services Framework (ID-WSF) 1.1

La version par défaut de ID-WSF dans le patch 3 d'Access Manager 7 est WSF1.1. Aucune autre configuration n'est nécessaire pour déclencher ID-WSF, à l'exception des exemples, qui doivent doivent utiliser les nouveaux mécanismes de sécurité. Les nouveaux mécanismes de sécurité pour ID-WSF1.1 sont :

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

Nouvelle propriété pour la prise en charge de Liberty ID-WSF

La propriété com.sun.identity.liberty.wsf.version détermine la structure de Liberty ID-WSF lorsque celle-ci n'est pas en mesure de déterminer à partir du message entrant ou des ressources disponibles si Access Manager fait office de WSC. Les valeurs peuvent être 1.0 ou 1.1. La valeur par défaut est 1.1.

Remarque : l'installation du patch n'ajoute pas la propriété com.sun.identity.liberty.wsf.version au fichier AMConfig.properties (CR# 6458184). Pour utiliser cette nouvelle propriété, ajoutez-la au fichier AMConfig.properties avec la valeur appropriée après l'installation du patch, puis redémarrez le conteneur Web d'Access Manager.

Une fois Access Manager 7 patch 3 installé, exécutez la commande suivante, pour charger les modifications apportées au schéma. Cette commande est illustrée avec Access Manager installé dans le répertoire par défaut sous Solaris :

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

L'enregistrement de découverte ID-WSF peut utiliser ces nouveaux mécanismes de sécurité lors de l'enregistrement. Les WSC détecteront également automatiquement la version à utiliser lors d'une communication avec des WSP. Pour configurer pour ID-WSF1.1, consultez les fichiers LisezMoi de Liberty ID-FF sample1 et les exemples ID-WSF fournis avec le produit.

CR# 6463779 : Le journal amProfile_Client d'authentification distribuée et le journal amProfile_Server du serveur Access Manager répertorient les exceptions inoffensives.

Les demandes faites au serveur Access Manager via une interface utilisateur d'authentification distribuée entraîne la consignation d'exceptions dans le journal distAuth/amProfile_Client et dans le journal debug/amProfile_Server du serveur Access Manager. Après plusieurs sessions, le journal amProfile_Client peut atteindre plusieurs gigaoctets et le journal amProfile_Server du serveur Access Manager peut atteindre plusieurs mégaoctets. Ces exceptions n'entraînent aucune perte de fonctionnalité dans les journaux, mais peuvent provoquer une fausse alarme pour les utilisateurs et les journaux peuvent éventuellement saturer le disque dur.

Solution. Exécutez des tâches cron qui annuleront le contenu des fichiers journaux. Exemple :

CR# 6460974 : L'utilisateur de l'application d'authentification distribuée par défaut ne doit pas être amadmin

Si vous déployez un serveur d'interface utilisateur d'authentification distribuée, l'administrateur correspondant ne doit pas être amadmin. L'utilisateur de l'application d'authentification distribuée par défaut indiqué dans le fichier Makefile.distAuthUI est amadmin, et donc dans le fichier AMConfig.properties, une fois que le fichier distAuth.war est déployé côté client. L'utilisateur amadmin dispose d'un AppSSOToken expirant à la fin de la session amadmin, pouvant ainsi entraîner la consignation d'une ERREUR FATALE dans le fichier journal amSecurity (situé, par défaut, dans le répertoire /tmp/distAuth).

Solution. Spécifiez UrlAccessAgent comme utilisateur de l'application d'authentification distribuée. Exemple :

Avant de déployer le fichier distAuth.war du conteneur Web client, modifiez les paramètres suivants du fichier Makefile.distAuthUI :

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

eur

Après avoir déployé le fichier distAuth.war du conteneur Web client, modifiez les propriétés suivantes du fichier AMConfig.properties pour chaque serveur Access Manager :

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

Voir aussi CR# 6440697 : L'authentification distribuée doit être exécutée en tant qu'utilisateur non administratif..

CR# 6460576 : Aucun lien vers le service utilisateur dans Rôle filtré dans l'aide en ligne de la console

L'aide en ligne de la console Access Manager ne comprend pas de lien vers le service utilisateur dans Rôle filtré. Dans l'aide en ligne, accédez au sommaire, à Rôle filtré, puis à la procédure de création d'un rôle filtré. Faites défiler la page vers le bas puis, en fonction du type d'identité sélectionné, une liste de services s'affiche mais aucun lien de service utilisateur n'est disponible.

Solution. aucune

CR# 6460085 : Le serveur sur WebSphere est inaccessible après l'exécution de reinstallRTM et le redéploiement d'applications Web.

Après l'application du patch 3 d'Access Manager 7 pour un déploiement DEPLOY_LEVEL=1 sur IBM WebSphere Application Server 5.1.1.6 sur Red Hat Linux AS 3.0 Update 4, le script reinstallRTM a été exécuté pour restaurer les RPM RTM. Les applications Web ont alors été redéployées après modification du fichier amsilent généré par le script reinstallRTM. WebSphere a été redémarré à l'aide des scripts stopServer.sh et startServer.sh. Toutefois, lors de l'accès à la page de connexion, WebSphere a affiché une erreur 500 liée au filtre amlcontroller.

Ce problème est survenu car le nouveau fichier server.xml généré par le script reinstallRTM était corrompu.

Solution. Le fichier server.xml sauvegardé à l'aide du script amconfig est toujours valide. Utilisez cette copie précédente, comme suit :

  1. Arrêtez le serveur.

  2. Remplacez le fichier server.xml corrompu par la copie sauvegardée à l'aide du script amconfig.

    Le fichier server.xml sauvegardé à l'aide du script amconfig sera nommé server.xml-orig- pid, où pid correspond à l'ID de processus du script amwas51config. Le fichier se trouve dans le répertoire suivant :

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

  3. Redémarrez le serveur.

CR# 6455757 : La classe de marqueurs sunISManagerOrganization doit être ajoutée à une organisation avant une mise à niveau.

Une organisation dans une arborescence d'informations d'annuaire (DIT) Access Manager créée avant Access Manager version 7 risque de ne pas disposer de la classe d'objet sunISManagerOrganization. La définition d'une organisation créée par un produit autre qu'Access Manager ne comprendra pas non plus la classe d'objet sunISManagerOrganization.

Solution. Avant de mettre à niveau en Access Manager 7 2005Q4, vérifiez que la définition de toutes les organisations de l'arborescence d'informations d'annuaire (DIT) comprend la classe d'objet sunISManagerOrganization. Si nécessaire, ajoutez manuellement cette classe d'objet avant la mise à niveau.

CR# 6454489 : La mise à niveau en Access Manager 7 2005Q4 Patch 2 entraîne une erreur dans l'onglet des sessions en cours de la console

Une mise à niveau a entraîné l'erreur suivante dans l'onglet des sessions en cours de la console Access Manager :

Failed to get valid Sessions from the Specified server

Ce problème s'applique aux déploiements mis à niveau des versions Access Manager 6 ne disposant pas de suffixe racine sous la forme o=orgname.

Solution. Après l'installation d'Access Manager 7 2005Q4, appliquez le patch 3 d'Access Manager 7 puis exécutez le script amupgrade pour migrer les données comme suit :

  1. Sauvegardez votre arborescence d'informations d'annuaire (DIT) Access Manager 6.

  2. Exécutez le script ampre70upgrade.

  3. Installez Access Manager 7 2005Q4 avec l'option de configuration ultérieure.

  4. Annulez le déploiement des applications Web d'Access Manager.

  5. Déployez les applications Web d'Access Manager.

  6. Appliquez le patch 3 d'Access Manager 7, mais pas les changements XML/LDIF. Les changements XML/LDIF doivent être appliqués après l'exécution du script amupgrade à l'étape suivante.

  7. Exécutez le script amupgrade.

  8. Redéployez les applications Web d'Access Manager en raison des changements du patch 3 d'Access Manager 7.

  9. Accédez à la console Access Manager.

CR# 6452320 : Les exceptions sont rejetées en cas d'interrogation avec SDK client.

Lorsque vous déployez le SDK client d'Access Manager (amclientsdk.jar) et que vous activez l'interrogation, des erreurs comme la suivante peuvent se produire :

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

De telles erreurs peuvent se produire après avoir déployé un serveur d'interface utilisateur d'authentification distribuée, des agents J2EE ou dans toute autre situation de déploiement du SDK client d'Access Manager sur une machine client.

Solution. Si vous disposez de quelques centaines de sessions simultanées uniquement, ajoutez les propriétés et valeurs suivantes au fichier AMConfig.properties ou au fichier AMAgents.properties :

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

Pour des centaines ou des milliers de sessions, les valeurs doivent être identiques à celles données à titre d'exemple dans le fichier AMConfig.properties d'Access Manager après exécution du script amtune-identity. Par exemple, pour une machine disposant de 4 Go de RAM, le script amtune-identity d'Access Manager définit les valeurs suivantes :

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

Définissez des valeurs identiques côté client dans le fichier AMAgent.properties ou AMConfig.properties lors du déploiement du serveur d'interface utilisateur d'authentification distribuée ou du SDK client d'Access Manager sur une machine client avec 4 Go de RAM.

CR# 6442905 : Le SSOToken de l'utilisateur authentifié doit être indiqué pour les sites malveillants.

Un utilisateur Access Manager authentifié peut révéler sans le vouloir le SSOToken d'un site malveillant en cliquant sur une URL du site.

Solution. Créez toujours un profil d'utilisateur d'agent unique dans Access Manager pour tous les agents de stratégie participant afin de s'assurer que le site n'est pas erroné. Vérifiez également qu'aucun de ces utilisateurs d'agent n'utilise un mot de passe identique au mot de passe secret partagé ou au mot de passe amldapuser . Par défaut, les agents de stratégie sont authentifiés dans le module d'authentification d'Access Manager comme l'utilisateur UrlAccessAgent.

Pour plus d'informations sur la création d'un agent à l'aide la console d'administration d'Access Manager, reportez-vous à Agents du Sun Java System Access Manager 7 2005Q4 Administration Guide.

CR# 6441918 : Intervalle de contrôle de site et propriétés du délai d'expiration

Le basculement de site Access Manager inclut les nouvelles propriétés suivantes :

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

Pour plus d'informations, reportez-vous à Nouvelles propriétés de configuration pour le contrôle de site.

CR# 6440697 : L'authentification distribuée doit être exécutée en tant qu'utilisateur non administratif.

Pour créer un administrateur d'authentification distribuée autre que l'utilisateur administratif par défaut (amadmin) pour l'authentification d'application, suivez la procédure ci-dessous :

  1. Créez un utilisateur LDAP comme administrateur de l'authentification distribuée. Exemple :

    uid=DistAuthAdmin,ou=people,o=am

  2. Ajoutez l'administrateur de l'authentification distribuée à la liste d'utilisateurs spéciaux. Exemple :

    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

    Ajoutez cette propriété au fichier AMConfig.properties de tous les serveurs Access Manager afin que le AppSSOToken de l'administrateur de l'authentification distribuée n'expire pas à la fin de la session.

CR# 6440695 : Serveurs d'interface utilisateur d'authentification distribuée avec équilibreur de charge

Si votre déploiement comprend un équilibreur de charge et plusieurs serveurs d'interface utilisateur d'authentification distribuée, définissez les propriétés suivantes dans le fichier AMConfig.properties après avoir déployé le fichier WAR.

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

CR# 6440651 : la rediffusion de cookie requiert la propriété com.sun.identity.session.resetLBCookie .

Pour que la rediffusion de cookie fonctionne correctement dans le basculement de session d'Access Manager, ajoutez la propriété com.sun.identity.session.resetLBCookie définie sur true pour l'agent de stratégie et le serveur Access Manager. Exemple :

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

Remarque : Cette propriété n'est requise que si vous avez implémenté le basculement de session d'Access Manager.

CR# 6440648 : La propriété com.iplanet.am.lbcookie.name implique une valeur par défaut de amlbcookie

Par défaut, un agent de stratégie et des serveurs Access Manager impliquent le nom de cookie d'équilibreur de charge amlbcookie. Si vous renommez le cookie du serveur d'arrière-plan, utilisez le même nom dans le fichier AMAgent.properties de l'agent de stratégie. De même, si vous utilisez le SDK client Access Manager, utilisez également le même nom de cookie que celui utilisé par le serveur d'arrière-plan.

CR# 6440641 : La propriété com.iplanet.am.lbcookie.value est désapprouvée.

Access Manager ne prend plus en charge la propriété com.iplanet.am.lbcookie.value sur les serveurs afin de personnaliser le cookie d'équilibreur de charge. Access Manager utilise désormais, pour la valeur de cookie et le nom donné par l'agent, l'ID du serveur défini dans la configuration de la session.

CR# 6429610 : Impossible de créer le jeton SSO en cas d'utilisation d'ID-FF SSO.

Après la définition de l'exemple 1 du Liberty Identity Federation Framework (ID-FF), la fédération réussit mais SSO échoue.

Solution. Ajoutez uuid de dsameuser à la propriété com.sun.identity.authentication.special.users dans le fichier AMConfig.properties. Pour l'authentification d'applications, dsameuser requiert un jeton SSO sans date d'expiration pour le serveur Access Manager.

CR# 6389564 : Plusieurs requêtes successives sur les membres du rôle d'un magasin de données LDAP v3 lors de la connexion à Access Manager

Lorsqu'un utilisateur se connecte à Access Manager, plusieurs recherches LDAP se produisent sur l'attribut nsRoleDN de l'utilisateur.

Solution. Une fois Access Manager 7 patch 3 installé, exécutez la commande suivante, illustrée avec Access Manager installé dans le répertoire par défaut sous Solaris :

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

CR# 6385185 : Le module d'authentification ne peut pas remplacer l'URL 'aller à' et en spécifier une autre

Un module d'authentification peut remplacer l'URL 'aller à' et demander la redirection vers une autre URL d'un site Web externe afin de valider le statut de l'utilisateur.

Pour remplacer l'URL 'aller à' une fois l'authentification terminée, définissez la propriété de l'exemple suivant du SSOToken. Pour cela, utilisez la méthode onLoginSuccess de la classe PostProcess mettant en œuvre AMPostAuthProcessInterface. Par exemple, OverridingURL représente l'URL remplaçant l'URL 'aller à' :

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

CR# 6385184 : La redirection depuis un module d'authentification personnalisé lorsque le jeton SSO est toujours à l'état non valide.

La nouvelle propriété RedirectCallback pour module d'authentification personnalisé permet de rediriger vers un site Web externe via l'interface utilisateur d'authentification afin de valider un utilisateur. Si l'authentification réussit, l'utilisateur est alors redirigé vers l'URL du serveur Access Manager d'origine. Les fichiers d'exemple incluent :

Pour mettre en œuvre cette fonction :

  1. Créez un module d'authentification personnalisé basé sur l'exemple LoginModuleSample.java.

  2. Chargez le module sur un serveur Access Manager.

  3. Définissez RedirectCallback dans le fichier XML à l'aide de l'exemple LoginModuleSample.xml.

  4. Pour tester le module, utilisez le fichier d'exemple testExtWebSite.jsp pour le site Web externe.

  5. Connectez-vous via l'URL suivante :

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

Le nom d'utilisateur et le mot de passe sont redirigés vers le site Web externe pour validation. Si le nom et le mot de passe sont valides, l'authentification réussit et l'utilisateur est redirigé vers l'URL du serveur Access Manager d'origine.

Prenons un exemple dans lequel le déploiement utilise un module d'authentification personnalisé pour accéder à un site d'approvisionnement/carte bancaire :

  1. Un utilisateur ouvre la page de traitement d'authentification/de connexion du module d'authentification personnalisé.

  2. L'utilisateur entre les informations d'authentification (nom d'utilisateur et mot de passe) et envoie une requête au module d'authentification personnalisé.

  3. Le module d'authentification personnalisé redirige l'utilisateur vers un site d'approvisionnement/carte bancaire externe ainsi que les informations utilisateur nécessaires fournies avec la requête.

  4. Le site d'approvisionnement/carte de crédit externe vérifie le statut de l'utilisateur et renvoie la requête comme étant réussie ou en échec.

  5. Le module d'authentification personnalisé valide l'utilisateur en fonction du statut renvoyé à l'étape 4 et le renvoie au service d'authentification.

  6. L'authentification utilisateur se termine et est soit réussie, soit en échec.

CR# 6324056 : La fédération échoue en cas d'utilisation d'un profil d'artefact.

Solution : Pour résoudre ce problème, appliquez la dernière version du patch 'Core Mobile Access', en fonction de votre plate-forme :

Redémarrez le conteneur Web après application du patch.