Cette section présente les différents problèmes connus au moment de la mise sur le marché de cette version, ainsi que leurs solutions, le cas échéant.
Incompatibilité entre les serveurs Java ES 2004Q2 et Instant Messaging sous Java ES 2005Q4 (6309082)
Un agent ne peut pas se connecter, car son profil n'existe pas dans l'organisation (6295074)
Le scénario de déploiement ci-dessous a provoqué le problème suivant :
server-1 : Java ES 2004Q2 : Directory Server
serveur-2 : Java ES 2004Q2 : Application Server, Access Manager et Portal Server
serveur-3 : Java ES 2004Q2 : Calendar Server et Messaging Server
serveur-4 : Java ES 2005Q4 : Application Server, Instant Messaging et Access Manager SDK
Lors de l'exécution de l'utilitaire imconfig pour configurer Instant Messaging sur le serveur-4, la configuration a échoué. Le SDK d'Access Manager 7 2005Q4, utilisé par Instant Messaging (IM) sur le serveur 4, n'est pas compatible avec la version Java ES 2004Q2.
Solution : Idéalement, le serveur et le SDK Access Manager doivent tous deux être de la même version. Pour obtenir plus d'informations, consultez le Guide de mise à niveau de Sun Java Enterprise System 2005Q4.
Le mode Hérité d'Access Manager 7 2005Q4 présente les incompatibilités suivantes dans le module d'authentification principale d'Access Manager 6 2005Q1 :
Les modules d'authentification des organisations sont supprimés en mode hérité.
La présentation des configurations d'authentification des administrateurs et des organisations a été modifiée. Dans la console Access Manager 7 2005Q4, la liste déroulante est paramétrée par défaut sur ldapService. Dans la console Access Manager 6 2005Q1, le bouton Modifier apparaît et le module LDAP n'a pas été sélectionné par défaut.
Solution : aucune.
Dans la console Access Manager, vous avez créé un agent en mode Domaine. Si vous vous déconnectez, puis vous reconnectez à l'aide du nom de l'agent, Access Manager renvoie une erreur car l'agent ne dispose pas des privilèges requis pour accéder au domaine.
Solution : Modifiez les droits de manière à autoriser les accès en lecture/écriture pour cet agent.
La commande commadmin de l'utilitaire Delegated Administrator, utilisée avec l'option -S mail,cal, ne permet pas de créer un utilisateur dans le domaine par défaut.
Solution : Ce problème se produit si vous effectuez une mise à niveau vers Access Manager version 7 2005Q4, mais que vous ne mettez pas à niveau Delegated Administrator. Pour obtenir plus d'informations sur la mise à niveau de Delegated Administrator, consultez le Guide de mise à niveau de Sun Java Enterprise System 2005Q4.
Si vous ne souhaitez pas mettre à niveau Delegated Administrator, suivez la procédure ci-après :
Dans le fichier UserCalendarService.xml, définissez les attributs mail, icssubcribed et icsfirstday comme facultatifs au lieu de requis. Ce fichier se trouve par défaut dans le répertoire /opt/SUNWcomm/lib/services/ des systèmes Solaris.
Dans Access Manager, supprimez le fichier XML existant en exécutant la commande amadmin, comme suit :
# ./amadmin -u amadmin -w password -r UserCalendarService
Dans Access Manager, ajoutez le fichier XML mis à jour, comme suit :
# ./amadmin -u amadmin -w password -s /opt/SUNWcomm/lib/services/UserCalendarService.xml
Redémarrez le conteneur Web d'Access Manager.
La commande commadmin de l'utilitaire Delegated Administrator, utilisée avec l'option -S mail,cal, ne permet pas de créer une organisation.
Solution : Reportez-vous à la solution du précédent problème.
Après l'application du patch 1, le fichier /tmp/amsilent offre un accès en lecture à tous les utilisateurs.
Solution : Après avoir appliqué le patch, réinitiailisez les permissions du fichier pour n'autoriser l'accès en lecture que par l'administrateur Access Manager.
Si vous effectuez une installation du SDK avec la configuration du conteneur (DEPLOY_LEVEL=4), l'URL de notification est incorrect.
Solution :
Définissez la propriété ci-dessous dans le fichier AMConfig.properties :
com.iplanet.am.notification.url= protocol://fqdn:port/amserver/servlet/com.iplanet.services.comm.client. PLLNotificationServlet
Redémarrez Access Manager afin que la nouvelle valeur soit prise en compte.
La valeur classpath d'Access Manager fait référence au package Java Cryptography Extension (JCE) 1.2.1 (certificat de signature), qui a expiré le 27 juillet 2005.
Solution : aucune. Bien que la référence au package figure dans la variable classpath, Access Manager n'utilise pas ce package.
Afin d'améliorer les performances de recherche, Directory Server a été doté de nouveaux index.
Solution : Après avoir installé Access Manager dans une arborescence d'informations d'annuaire existante, vous devez recréer les index Directory Server en exécutant le script db2index.pl. Exemple :
# ./db2index.pl -D "cn=Directory Manager" -w password -n userRoot
Le script db2index.pl est accessible à partir du répertoire DS-install-directory/slapd-hostname/.
Lorsqu'un utilisateur non root est spécifié dans le fichier de configuration de l'installation silencieuse, les autorisations liées au débogage, aux journaux et aux répertoires de démarrage ne sont pas définies correctement.
Solution : Modifiez les droits associés à ces répertoires de manière à autoriser l'accès d'un utilisateur non root.
Bien que la variable classpath et les autres variables d'environnement de conteneur Web d'Access Manager soient mises à jour pendant l'installation, le processus d'installation ne redémarre pas le conteneur Web. Si vous essayez de vous connecter à Access Manager après l'installation et avant le redémarrage du conteneur Web, l'erreur suivante est renvoyée :
Authentication Service is not initialized. Contact your system administrator.
Solution : Redémarrez le conteneur Web avant de vous connecter à Access Manager. Directory Server doit également être en cours d'exécution au moment de la connexion.
Le programme d'installation de Java ES n'ajoute pas d'entrée de plate-forme pour un serveur d'annuaire existant (DIRECTORY_MODE=2).
Solution : Ajoutez manuellement les alias DNS et de domaine, ainsi que les entrées de la liste des serveurs de plate-forme. Pour connaître la procédure, consultez la section Adding Additional Instances to the Platform Server List and Realm/DNS Aliases du Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.
Le script ampre70upgrade d'Access Manager ne supprime pas les packages localisés (6378444)
Le fichier AMConfig.properties dispose d'une ancienne version du conteneur Web (6316833)
À l'issue d'une mise à niveau, la commande amadmin renvoie une version incorrecte (6283758)
Ajout de l'attribut ContainerDefaultTemplateRole après la migration des données (4677779)
Si vous procédez à une mise à niveau depuis Access Manager vers Access Manager 7 2005Q4, le script ampre70upgrade ne supprime aucun package Access Manager localisé présent sur votre système.
Solution : Avant de procéder à la mise à niveau vers Access Manager 7 2005Q4, utilisez la commande pkgrm pour supprimer manuellement tous les packages Access Manager localisés installés sur votre système.
Après la mise à niveau d'Access Manager et d'Application Server vers Java ES 2005Q4, le fichier AMConfig.properties d'Access Manager dispose d'une ancienne version d'Application Server.
Solution : Avant d'exécuter le programme de configuration de Delegated Administrator (config-commda), modifiez la propriété ci-dessous dans le fichier AMConfig.properties :
com.sun.identity.webcontainer=IAS8.1
À l'issue de la mise à niveau d'Access Manager, le fichier server.policy de l'agent de nœud n'est pas mis à jour.
Solution : Remplacez le fichier server.policy de l'agent de nœud par le fichier suivant :
/var/opt/SUNWappserver/domains/domain1/config/server.policy
Après une mise à niveau d'Access Manager version 2005Q1 vers la version 2005Q4, la condition de propriété de session n'est pas proposée comme choix dans la liste des conditions de stratégie si vous tentez d'ajouter une condition à une stratégie.
Solution : Sélectionnez le type de la condition de propriété de session dans le modèle du service de configuration de stratégie, au niveau du domaine correspondant.
À l'issue de la mise à niveau d'Access Manager version 2005Q1 vers la version 2005Q4, le type Objet d'identité, nouveau type d'objet de stratégie, n'est pas proposé comme choix dans la liste des objets de stratégie.
Solution : Sélectionnez le type Objet d'identité comme type d'objet par défaut dans le modèle du service de configuration de stratégie.
Lors de la mise à niveau d'Access Manager, de Java ES 2004Q2 vers Java ES 2005Q4, la mise à niveau de Java ES 2004Q2 vers Java ES 2005Q4 a échoué. Access Manager a été déployé sur Application Server, ce dernier ayant également été mis à niveau de Java ES 2004Q2 vers Java ES 2005Q4. Le classpath dans le fichier domain.xml ne contenait pas de chemins d'accès aux fichiers JAR Access Manager.
Solution : Procédez comme indiqué ci-dessous.
Avant d'exécuter le script amupgrade, vous devez réindexer Directory Server, en raison d'un problème avec le script comm_dssetup.pl.
Ajoutez des entrées associées à Access Manager dans le fichier server.policy de l'agent de nœud. Il vous suffit de copier le fichier server.policy à partir du fichier par défaut (/var/opt/SUNWappserver/domains/domain1/config/server.policy).
Mettez à jour la variable classpath dans le fichier domain.xml de l'agent de nœud, de la manière suivante : Copiez les éléments classpath-suffix et classpath appropriés à partir des attributs server-classpath de l'élément java-config du fichier server.xml et utilisez-les pour les attributs correspondants, dans l'élément java-config du fichierdomain.xml. L'élément java-config se trouve sous l'élément config du fichier domain.xml.
À l'issue de la mise à niveau d'Access Manager version 6 2005Q1 vers la version 7 2005Q4, la commande amadmin --version a renvoyé une version incorrecte : Sun Java System Access Manager version 2005Q1.
Solution : Après avoir mis à niveau Access Manager, exécutez le script amconfig pour configurer Access Manager. Lors de l'exécution de amconfig, spécifiez le chemin d'accès complet au fichier de configuration (amsamplesilent ). Par exemple, sous un système Solaris :
# ./amconfig -s ./config-file
eur
# ./amconfig -s /opt/SUNWam/bin/config-file
Le rôle de l'utilisateur n'apparaît pas sous une organisation qui n'a pas été créée dans Access Manager. En mode de débogage, le message suivant apparaît :
ERROR: DesktopServlet.handleException() com.iplanet.portalserver.desktop.DesktopException: DesktopServlet.doGetPost(): no privilige to execute desktop
Cette erreur devient évidente après l'exécution des scripts de migration du programme d'installation de Java ES. L'attribut ContainerDefaultTemplateRole n'est pas ajouté automatiquement à l'organisation lorsque cette dernière est migrée depuis une arborescence d'informations d'annuaire existante ou depuis une autre source.
Solution : Utilisez la console Directory Server pour copier l'attribut ContainerDefaultTemplateRole depuis une autre organisation Access Manager, puis ajoutez-le à l'organisation affectée.
Validation de données d'attributs requis dans les services (6308653)
Exception lors du déploiement sur une instance WebLogic 8.1 sécurisée (6295863)
Échec de signature d'URL dans IBM WebSphere avec une clé RSA (6271087)
Si vous déployez Access Manager 7 2005Q4 sur Application Server 8.1 et que vous utilisez des URI autres que ceux par défaut pour les services, la console et les applications Web avec mot de passe qui disposent des URI par défaut amserver, amconsole et ampassword, vous devez modifier le fichier server.policy correspondant au domaine du serveur d'application avant de tenter d'accéder à Access Manager via un navigateur Web.
Solution : Modifiez le fichier server.policy de la manière suivante :
Arrêtez l'instance Application Server sur laquelle Access Manager est déployé.
Accédez au répertoire /config. Exemple :
cd /var/opt/SUNWappserver/domains/domain1/config
Effectuez une copie de sauvegarde du fichier server.policy. Exemple :
cp server.policy server.policy.orig
Dans le fichier server.policy, recherchez les stratégies suivantes :
grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/amserver/-" { ... }; grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/amconsole/-" { ... }; grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/ampassword/-" { ... };
Dans la ligne ci-dessous, remplacez l'URI par défaut amserver par l'URI qui est utilisé pour l'application Web des services :
grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/amserver/-" {
Pour les installations en mode Hérité, remplacez l'URI par défaut amconsole par l'URI qui est utilisé pour l'application Web de la console (et qui est différent de celui par défaut) dans la ligne suivante :
grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/amconsole/-" {
Remplacez l'URI par défaut ampassword par l'URI utilisé pour l'application Web avec mot de passe dans la ligne ci-dessous:
grant codeBase "file:\${com.sun.aas.instanceRoot}/ applications/j2ee-modules/ampassword/-" {
Démarrez l'instance Application Server sur laquelle Access Manager est déployé.
Dans le cadre d'un déploiement avec plusieurs serveurs, la liste des serveurs de plate-forme et l'attribut d'alias FQDN ne sont pas mis à jour si vous installez Access Manager sur le deuxième serveur et les suivants.
Solution : Ajoutez manuellement les alias DNS et de domaine, ainsi que les entrées de la liste des serveurs de plate-forme. Pour connaître la procédure, consultez la section Adding Additional Instances to the Platform Server List and Realm/DNS Aliases du Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.
Avec Access Manager 7 2005Q4, les attributs requis dans les fichiers XML des services doivent utiliser les valeurs par défaut.
Solution : Si un service comporte des attributs sans valeur, ajoutez des valeurs à ces attributs, puis relancez le service.
Si vous déployez Access Manager 7 2005Q4 sur une instance BEA WebLogic 8.1 SP4 sécurisée (SSL activé), une exception est générée au cours du déploiement de chacune des applications Web d'Access Manager.
Solution : Procédez comme indiqué ci-dessous.
Appliquez le patch de WebLogic 8.1 SP4, CR210310_81sp4.jar, disponible auprès de BEA.
Dans le script /opt/SUNWam/bin/amwl81config (système Solaris) ou /opt/sun/identity/bin/amwl81config (système Linux), mettez à jour les fonctions doDeploy et undeploy_it de manière à ajouter le chemin d'accès au fichier JAR du patch à la variable wl8_classpath , qui contient la variable classpath utilisée pour déployer et annuler le déploiement des applications Web d'Access Manager.
Trouvez la ligne contenant la variable wl8_classpath :
wl8_classpath= ...
Immédiatement à la suite de la ligne trouvée à l'étape 2, ajoutez la ligne suivante :
wl8_classpath=path-to-CR210310_81sp4.jar:$wl8_classpath
Dans le cadre d'un déploiement sur plusieurs serveurs, le script amconfig ne met pas à jour les alias DNS et de domaine, ni les entrées de la liste des serveurs de plate-forme pour les instances Access Manager supplémentaires.
Solution : Ajoutez manuellement les alias DNS et de domaine, ainsi que les entrées de la liste des serveurs de plate-forme. Pour connaître la procédure, consultez la section Adding Additional Instances to the Platform Server List and Realm/DNS Aliases du Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.
Par défaut, le mode Domaine (variable AM_REALM), d'Access Manager est activé dans le modèle de fichier d'état de configuration.
Solution : Pour installer ou configurer Access Manager en mode hérité, vous devez réinitialiser la variable dans le fichier d'état :
AM_REALM = disabled
Avec une clé RSA dans IBM WebSphere, la signature de la chaîne URL échoue avec l'exception suivante :
ERROR: FSSignatureUtil.signAndReturnQueryString: FSSignatureException occured while signing query string: no such provider: SunRsaSign
Solution : Le fournisseur SunRsaSign est manquant dans le JDK intégré WebSphere. Pour résoudre ce problème, modifiez le fichier websphere_jdk_root/jre/lib/security/java.security et ajoutez la ligne suivante pour activer SunRsaSign en tant que fournisseur :
security.provider.6=com.sun.rsajca.Provider
Pour SAML, erreurs d'édition de doublon Trusted Partner (6326634)
La nouvelle console Access Manager ne permet pas de définir les priorités du modèle CoS (6309262)
En mode hérité, vous ne pouvez pas supprimer tous les utilisateurs d'un rôle (6293758)
Access Manager ne peut pas créer une organisation sous un conteneur en mode hérité (6290720)
L'ancienne console apparaît lors de l'ajout de services associés à Portal Server (6293299)
Dans la console Access Manager, vous avez créé un partenaire de confiance SAML sous l'onglet Fédération > SAML. Si vous tentez de le dupliquer, des erreurs se produisent.
Solution : aucune. Ce problème est résolu dans le patch 1. Pour plus d'informations sur l'application du patch à votre plate-forme spécifique, reportez-vous à la section Access Manager 7 2005Q4 Patch 1.
Lorsque la fonction de journalisation à distance est activée, tous les journaux sont écrits dans l'instance Access Manager distante, à l'exception des journaux amConsole.accesset amPasswordReset.access regroupant les informations de réinitialisation de mot de passe. L'enregistrement de journal n'est écrit nulle part.
Solution : aucune.
L'ajout ou la modification de certaines propriétés de l'utilisateur amadmin dans la console d'administration entraîne la modification du mot de passe de l'utilisateur amadmin.
Solution : aucune. Ce problème est résolu dans le patch 1. Pour plus d'informations sur l'application du patch à votre plate-forme spécifique, reportez-vous à la section Access Manager 7 2005Q4 Patch 1.
La nouvelle console Access Manager 7 2005Q4 ne peut pas définir ou modifier la priorité d'un modèle de classe de service (COS).
Solution : Connectez-vous à la console Access Manager 6 2005Q1 pour définir ou modifier la priorité du modèle CoS.
La console Access Manager renvoie une exception lorsque vous ajoutez un groupe à un utilisateur en tant qu'administrateur de stratégies.
Solution : aucune.
En mode hérité, si vous essayez de supprimer tous les utilisateurs d'un rôle, il reste un utilisateur.
Solution : Essayez de nouveau de supprimer l'utilisateur du rôle.
La console d'administration d'Access Manager ne vous permet pas d'ajouter, de supprimer ou de modifier les offres de ressources d'un utilisateur, d'un rôle ou d'un domaine.
Solution : aucune. Ce problème est résolu dans le patch 1. Pour plus d'informations sur l'application du patch à votre plate-forme spécifique, reportez-vous à la section Access Manager 7 2005Q4 Patch 1.
La console d'administration d'Access Manager ne renvoie pas d'erreur lors de l'utilisation d'un mot de passe incorrect pour la liaison LDAP.
Solution : aucune.
Si vous créez un conteneur, puis essayez de créer une organisation sous ce conteneur, Access Manager signale une violation de contrainte d'unicité.
Solution : aucune.
Portal Server et Access Manager sont installés sur le même serveur. En mode hérité, vous vous connectez à la nouvelle console Access Manager en utilisant /amserver. Si vous choisissez un utilisateur existant et que vous essayez d'ajouter des services (tels que NetFile ou Netlet), l'ancienne console Access Manager (/amconsle) apparaît.
Solution : aucune. La version actuelle de Portal Server requiert la console Access Manager 6 2005Q1.
Installez Directory Server, puis Access Manager avec l'option d'arborescence d'informations d'annuaire (DIT) existante. Connectez-vous à la console Access Manager et créez un groupe. Modifiez les utilisateurs du groupe. Par exemple, ajoutez des utilisateurs avec le filtre uid=*999*. La zone de liste qui en résulte est vide, mais la console n'affiche aucune erreur ou information, ni aucun message d'avertissement.
Solution : La taille du groupe ne doit pas dépasser la taille limite de la recherche Directory Server. Si la taille du groupe est supérieure, modifiez la taille limite de la recherche en conséquence.
Impossible de supprimer la configuration du service de session d'un sous-domaine (6318296)
Les clients ne reçoivent pas de notifications après le redémarrage du serveur (6309161)
Redémarrer les clients SDK après une modification du schéma de service (6292616)
Après l'ajout d'un sous-domaine au domaine supérieur, puis l'ajout d'un service de session à ce sous-domaine, si vous tentez de supprimer la configuration du service de session, un message d'erreur apparaît.
Solution : Supprimez le référentiel d'identités supérieur par défaut, AMSDK1, puis ajoutez-le à nouveau dans la configuration.
Ce problème est résolu dans le patch 1. Pour plus d'informations sur l'application du patch à votre plate-forme spécifique, reportez-vous à la section Access Manager 7 2005Q4 Patch 1.
Avec l'agent Apache 2.2 en mode d'authentification unique interdomaines (CDSSO), lors de l'accès à la ressource protégée par l'agent, le servlet CDC redirige l'utilisateur vers une page d'authentification anonyme, au lieu de la page de connexion par défaut.
Solution : aucune. Ce problème est résolu dans le patch 1. Pour plus d'informations sur l'application du patch à votre plate-forme spécifique, reportez-vous à la section Access Manager 7 2005Q4 Patch 1.
Les applications écrites à l'aide du SDK client (amclientsdk.jar) ne reçoivent pas de notifications lorsque le serveur redémarre.
Solution : aucune.
Si vous modifiez un schéma de service, ServiceSchema.getGlobalSchema renvoie l'ancien schéma et non le nouveau.
Solution : Redémarrez le client après avoir modifié un schéma de service.
Ce problème est résolu dans le patch 1. Pour plus d'informations sur l'application du patch à votre plate-forme spécifique, reportez-vous à la section Access Manager 7 2005Q4 Patch 1.
Si vous utilisez Sun Java System Directory Proxy Server, une recherche LDAP d'attributs null renvoie une erreur. Exemple :
# ldapsearch -b base-dn uid=user ""
Si Access Manager pointe directement vers le serveur d'annuaire LDAP, la même recherche aboutit.
Solution : si vous utilisez Directory Proxy Server, activez les recherches d'attributs null ou saisissez un nom d'attribut pour la recherche.
Après l'installation, lorsque vous devez exécuter le script amserveradmin pour charger les services dans Directory Server, le script ne contient pas les fichiers de schéma defaultDelegationPolicies.xml et idRepoDefaults.xml.
Solution : Chargez manuellement les fichiers defaultDelegationPolicies.xml et idRepoDefaults.xml à l'aide de la commande amadmin dotée de l'option -t.
Si vous ajoutez un caractère d'échappement (tel que la chaîne amp; à côté du caractère &) dans un fichier XML, le fichier est correctement enregistré. Cependant, si par la suite vous récupérez le profil XML via Internet Explorer 6.0, le fichier ne s'affichera pas correctement. Si vous essayez de réenregistrer le profil, une erreur est renvoyée.
Solution : aucune.
Le jeton SSO UrlAccessAgent arrive à expiration, car le module d'application ne renvoie pas le DN de l'utilisateur spécial, ce qui entraîne l'échec de la correspondance du DN et celui du jeton.
Solution : aucune. Ce problème est résolu dans le patch 1. Pour plus d'informations sur l'application du patch à votre plate-forme spécifique, reportez-vous à la section Access Manager 7 2005Q4 Patch 1.
En mode Domaine, si vous créez un magasin de données LDAPv3 dans un domaine avec un certain mot de passe et que, par la suite, vous modifiez le mot de passe en tant qu'utilisateur amadmin parce qu'il ne vous convient pas, lorsque vous tentez de vous reconnecter avec le compte de l'utilisateur dont vous avez modifié le mot de passe, la connexion échoue, indiquant que ce profil n'existe pas.
Solution : aucune.
À l'issue de l'installation d'Access Manager en mode hérité, la configuration par défaut du service des statistiques a été modifiée :
Le service est activé par défaut (com.iplanet.services.stats.state=file ). Auparavant, il était désactivé.
L'intervalle par défaut (com.iplanet.am.stats.interval) est passé de 3600 à 60.
Le répertoire de statistiques par défaut (com.iplanet.services.stats.directory ), /var/opt/SUNWam/debug, a été remplacé par /var/opt/SUNWam/stats.
Solution : aucune.
Après avoir installé Access Manager, connectez-vous en tant qu'utilisateur amadmin et ajoutez les attributs o, sunPreferredDomain, associatedDomain, sunOrganizationAlias, uid et mail à la liste des attributs uniques. Si vous créez deux nouvelles organisations avec le même nom, l'opération échoue, mais Access Manager affiche le message “L'organisation existe déjà.” au lieu du message “Unicité d'attribut violée”.
Solution : aucune. Ignorez le message. Access Manager fonctionne correctement.
Échec du script de reprise de session (amsfoconfig) sous Linux 2.1 (6298462)
Utilisation de HttpSession avec des conteneurs Web tiers (pas de numéro CR)
L'installation d'instances Access Manager avec différents fuseaux horaires et un même cercle de confiance entraîne l'expiration des sessions utilisateur.
Le script de configuration de reprise de session (/opt/sun/identity/bin/amsfoconfig) comporte des droits incorrects et ne peut pas être exécuté sous un système Linux 2.1.
Solution : Modifiez les droits de sorte que le script amsfoconfig devienne exécutable (par exemple, 755).
Ce problème est résolu dans le patch 1. Pour plus d'informations sur l'application du patch à votre plate-forme spécifique, reportez-vous à la section Access Manager 7 2005Q4 Patch 1.
Le script de configuration de reprise de session (amsfoconfig) échoue sur un serveur Linux 2.1, car le caractère de tabulation (\t) n'est pas correctement interprété.
Solution : Configurez la reprise de session manuellement. Pour obtenir la procédure, consultez la section Configuring Session Failover Manually du Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.
Ce problème est résolu dans le patch 1. Pour plus d'informations sur l'application du patch à votre plate-forme spécifique, reportez-vous à la section Access Manager 7 2005Q4 Patch 1.
Si vous déployez Access Manager en utilisant Web Server comme conteneur Web avec un équilibreur de charge doté d'une terminaison SSL, les clients ne sont pas dirigés vers la page Web Server appropriée. Si vous cliquez sur l'onglet Sessions dans la console Access Manager, une erreur est renvoyée, car l'hôte n'est pas valide.
Solution : dans les exemples suivants, Web Server écoute sur le port 3030. L'équilibreur de charge écoute sur le port 80 et redirige les requêtes vers Web Server.
Dans le fichier web-server-instance-name/config/server.xml, vous devez modifier l'attribut servername de sorte qu'il désigne l'équilibreur de charge, en fonction de la version Web Server utilisée.
Avec les versions Web Server 6.1 Service Pack (SP), modifiez l'attribut servername, de la manière suivante :
<LS id="ls1" port="3030" servername="loadbalancer.example.com:80" defaultvs="https-sample" security="false" ip="any" blocking="false" acceptorthreads="1"/>
Web Server 6.1 SP2 (ou version ultérieure) peut modifier le protocole http en https ou https en http. Par conséquent, modifiez l'attribut servername comme suit :
<LS id="ls1" port="3030" servername="https://loadbalancer.example.com:443" defaultvs="https-sample" security="false" ip="any" blocking="false" acceptorthreads="1"/>
La méthode par défaut de maintenance de sessions pour l'authentification est la session interne et non pas HttpSession. La valeur maximale de session non valide par défaut de trois minutes est suffisante. Le script amtune définit la valeur sur une minute pour Web Server ou Application Server. Toutefois, si vous utilisez un conteneur Web tiers (IBM WebSphere ou BEA WebLogic Server) et l'option HttpSession, il se peut que vous deviez limiter le temps HttpSession maximum du conteneur Web pour éviter les problèmes de performances.
La suppression des attributs dynamiques dans le service de configuration des stratégies entraîne des problèmes de modification des stratégies dans le scénario suivant :
Vous créez deux attributs dynamiques dans le service de configuration des stratégies.
Vous créez une stratégie et sélectionnez les attributs dynamiques de l'étape 1 dans le fournisseur de réponses.
Vous supprimez les attributs dynamiques du service de configuration des stratégies et créez deux autres attributs.
Vous essayez ensuite de modifier la stratégie créée à l'étape 2.
Les résultats possibles sont les suivants : “Erreur. Tentative de définition d'une propriété dynamique non valide.” Aucune stratégie n'a été affichée dans la liste par défaut. Si vous effectuez une recherche, les stratégies s'affichent, mais vous ne pouvez pas modifier ou supprimer les stratégies existantes, ni en créer une autre.
Solution : Avant de supprimer les attributs dynamiques du service de configuration des stratégies, supprimez les références à ces attributs dans les stratégies.
Lors du démarrage d'Access Manager 7 2005Q4, les erreurs de débogage sont renvoyées dans les fichiers de débogage amDelegation et amProfile :
amDelegation : impossible d'obtenir une instance de plug-in pour la délégation
amProfile : Exception de délégation
Solution : aucune. Vous pouvez ignorer ces messages.
Si vous déployez Access Manager en utilisant BEA WebLogic Server comme conteneur Web, Access Manager risque de ne pas être accessible.
Solution : Redémarrez WebLogic Server une deuxième fois pour qu'Access Manager devienne accessible.
Si vous exécutez Application Server 8.1 sous Red Hat Linux, la taille de la pile des threads créés par le système d'exploitation Red Hat pour Application Server est de 10 Mo, ce qui peut entraîner des problèmes de ressources JVM lorsque le nombre de sessions utilisateur Access Manager atteint 200.
Solution : Solution : Définissez la taille de la pile de fonctionnement du système d'exploitation Red Hat sur une valeur inférieure, telle que 2 048 ou même 256 Ko en exécutant la commande ulimit avant de démarrer Application Server. Exécutez la commande ulimit sur la même console que celle utilisée pour démarrer Application Server. Exemple :
# ulimit -s 256;
L'exécution de l'exemple de services Web renvoie le message Resource offering not found (6359900)
Échec de la fédération lors de l'utilisation du profil d'artéfact (6324056)
Les caractères spéciaux (&) des instructions SAML doivent être codés (6321128)
Une exception se produit lors de la tentative d'ajout du service de découverte à un rôle (6313437)
Une erreur de déconnexion se produit dans la fédération (6291744)
Lorsqu'Access Manager est configuré pour accéder aux échantillons de services Web dans le répertoire AccessManager-base/SUNWam/samples/phase2/wsc sous Solaris ou dans le répertoire AccessManager-base /identity/samples/phase2/wsc sous Linux, interroger le service de découverte ou modifier l'offre de ressources renvoie le message d'erreur suivant : 'Offre de ressources introuvable'.
AccessManager-base correspond au répertoire d'installation de base. Le répertoire d'installation de base par défaut est /opt sous Solaris et /opt/sun sous Linux.
Solution :
Accédez au répertoire d'exemples suivant : AccessManager-base /SUNWam/samples/phase2/wsc) sous Solaris ou AccessManager-base/identity/samples/phase2/wsc sous Linux
Dans le fichier index.jsp, recherchez la chaîne suivante :
com.sun.org.apache.xml.security.utils.XMLUtils.outputDOM
Immédiatement avant la ligne contenant la chaîne trouvée dans l'étape précédente, insérez la nouvelle ligne suivante :
com.sun.org.apache.xml.security.Init.init();
Exécutez de nouveau l'exemple. (Il n'est pas nécessaire de redémarrer Access Manager.)
Si vous configurez un fournisseur d'identités et un fournisseur de services, que vous modifiez le protocole de communication pour utiliser le profil d'artéfact du navigateur, puis que vous essayez de fédérer les utilisateurs entre les deux fournisseurs, la fédération échoue.
Solution : aucune.
Lorsque Access Manager fait office de site source et de site de destination et que la connexion unique est configurée, une erreur se produit dans le site de destination, car le caractère spécial ( &) n'est pas codé dans les instructions SAML et par conséquent, l'analyse de l'assertion échoue.
Solution : aucune. Ce problème est résolu dans le patch 1. Pour plus d'informations sur l'application du patch à votre plate-forme spécifique, reportez-vous à la section Access Manager 7 2005Q4 Patch 1.
Dans la console Access Manager, si vous essayez d'ajouter une offre de ressource au service de découverte, une exception inconnue se produit.
Solution : aucune.
Les attributs de contexte d'authentification ne peuvent pas être configurés tant que les autres attributs n'ont pas été configurés et enregistrés.
Solution : Configurez et enregistrez un profil de fournisseur avant de configurer les attributs de contexte d'authentification.
Si Directory Server dispose d'un suffixe racine contenant le caractère & et que vous essayez d'ajouter une offre de ressource du service de profil d'employé, une exception est générée.
Solution : aucune.
En mode Domaine, si vous fédérez des comptes utilisateur sur un fournisseur d'identités et un fournisseur de services, que vous arrêtez la fédération, puis que vous vous déconnectez, une erreur se produit : Erreur : Aucune sous-organisation n'a été trouvée.
Solution : aucune.
Certaines parties de la console d'administration d'Access Manager ne suivent pas les préférences linguistiques de l'utilisateur, mais utilisent celles définies dans le navigateur. Ce problème concerne les boutons Version et Déconnexion et ceux de l'aide en ligne, ainsi que le contenu auquel ils permettent d'accéder.
Solution : Modifiez les paramètres du navigateur de manière à définir les mêmes paramètres linguistiques que ceux définis dans les préférences de l'utilisateur.
Pour tous les paramètres linguistiques européens (espagnol, allemand et français), l'aide en ligne n'est pas disponible dans son intégralité lorsque Access Manager est déployé sur une instance IBM WebSphere Application Server. L'aide en ligne affiche un message indiquant une erreur d'application dans les cadres suivants :
le cadre supérieur, là où les boutons Aide et Fermer devraient apparaître ;
le cadre de gauche, là où les boutons Sommaire, Index et Rechercher devraient apparaître.
Solution : Choisissez l'anglais comme préférence linguistique dans le navigateur, puis actualisez la page pour accéder au cadre de gauche. Le cadre supérieur, cependant, continuera d'indiquer une erreur d'application.
Quelle que soit la préférence linguistique, si Access Manager est déployé sur une instance IBM WebSphere Application Server, la version du produit n'apparaît pas lorsque vous cliquez sur le bouton Version. Une page vide est affichée.
Solution : aucune.
La fonction Détection de client ne fonctionne pas correctement. Les modifications effectuées dans la console Access Manager 7 2005Q4 ne sont pas automatiquement appliquées dans le navigateur.
Solution : Vous avez deux possibilités :
Redémarrez le conteneur Web d'Access Manager, après avoir effectué une modification dans la section Détection de client.
eur
Suivez la procédure ci-dessous dans la console Access Manager :
Cliquez sur Détection de client sous l'onglet Configuration .
Cliquez sur le lien Modifier correspondant au client genericHTML.
Sous l'onglet HTML, cliquez sur le lien genericHTML.
Dans la liste des jeux de caractères, entrez la valeur suivante : UTF-8;q=0.5 (veillez à ce que le facteur UTF-8 q soit inférieur à celui des autres jeux de caractères de votre environnement linguistique).
Enregistrez l'opération, déconnectez-vous, puis reconnectez-vous.
Les messages multioctets des fichiers journaux du répertoire /var/opt/SUNWam/logs sont affichés sous forme de points d'interrogation (?). Les fichiers journaux utilisent le codage natif et pas toujours UTF-8. Lorsqu'une instance de conteneur Web démarre dans un environnement linguistique donné, les fichiers journaux utilisent le codage natif pour cet environnement. Si vous changez d'environnement linguistique et que vous redémarrez l'instance du conteneur Web, les messages ultérieurs utiliseront le codage natif correspondant aux paramètres linguistiques actifs, mais les messages antérieurs sont affichés avec des points d'interrogation.
Solution : Veillez à démarrer les instances du conteneur Web en utilisant toujours le même codage natif.
Access Manager ne peut pas rebasculer en mode Hérité à partir du mode Domaine (6508473)
Obtention de davantage d'informations sur la désactivation des recherches persistantes (6486927)
Documentation des privilèges d'Access Manager pris et non pris en charge (2143066)
Documentation du routage des demandes d'association basé sur des cookies (6476922)
Documentation de la configuration de Windows Desktop SSO pour Windows 2003 (6487361)
L'aide en ligne sur la création d'un nouveau nom de site demande plus d'informations (2144543)
Le paramètre de configuration du mot de passe administrateur estADMIN_PASSWD sous Windows (6470793)
Les notes de version ne résolvent pas un problème connu (6422907)
Document com.iplanet.am.session.protectedPropertiesList dans AMConfig.properties (6351192)
Documentation de la prise en charge des rôles et des rôles filtrés pour le plug-in LDAPv3 (6365196)
Documentation des propriétés non utilisées dans le fichier AMConfig.properties (6344530)
L'URL par défaut de connexion réussie est incorrecte dans l'aide en ligne de la console (6296751)
Documentation sur la façon d'activer le chiffrement XML (6275563)
Si vous installez Access Manager 7 2005Q4 en mode Domaine, vous ne pouvez pas rebasculer en mode Hérité.
Si vous installez Access Manager 7 2005Q4 en mode Hérité, vous pouvez basculer en mode Domaine à l'aide de la commande amadmin associée à l'option -M. Exemple :
amadmin -u cn=amAdmin,ou=People,dc=example,dc=com -w amadmin-password -M dc=example,dc=com
Access Manager utilise les recherches persistantes pour recevoir des informations sur la modification des entrées de Sun Java System Directory Server. Access Manager crée par défaut les connexions de recherche persistante suivantes pendant le démarrage du serveur :
aci - Modifications de l'attribut aci, la recherche utilisant le filtre LDAP (aci=*)
sm - Modifications de l'arborescence d'informations d'Access Manager (ou du nœud de gestion du service) qui comprend les objets appartenant à la classe d'objet marqueur sunService ou sunServiceComponent. Vous pouvez, par exemple, créer une stratégie visant à définir les privilèges d'accès à une ressource protégée ou modifier les règles, objets, conditions ou fournisseurs de réponse d'une stratégie existante.
um - Modifications dans le répertoire utilisateur (ou nœud de gestion des utilisateurs). Vous pouvez, par exemple, modifier le nom ou l'adresse de l'utilisateur.
Il n'est pas recommandé de désactiver les recherches persistantes de l'un de ces composants. De fait, lorsqu'une recherche persistante d'un composant est désactivée, ce dernier ne reçoit pas de notification de Directory Server. Par conséquent, les modifications apportées dans Directory Server pour ce composant particulier ne seront pas notifiées au cache du composant et le cache du composant sera bloqué.
Par exemple, si vous désactivez les recherches persistantes des modifications dans le répertoire utilisateur (um), le serveur Access Manager ne recevra plus les notifications de Directory Server. Par conséquent, un agent ne recevra pas les notifications d'Access Manager l'avertissant de mettre à jour son cache utilisateur local vers les nouvelles valeurs de l'attribut utilisateur. Si ensuite une application demande à l'agent de lui fournir les attributs utilisateur, elle recevra les anciennes valeurs.
N'utilisez cette propriété que dans des circonstances spéciales et lorsque cela est absolument nécessaire. Par exemple, si vous savez que les modifications de la configuration du service (en rapport avec la modification des valeurs de n'importe quel service comme le service de session ou les services d'authentification) ne seront pas mises en œuvre dans l'environnement de production, vous pouvez désactiver la recherche persistante sur le composant Service Management (sm). Cependant, en cas de modification d'un service quelconque, vous devrez redémarrer le serveur. La même condition s'applique aux recherches persistantes spécifiées par les valeurs aci et um.
Pour plus d'informations, consultez la section CR# 6363157 : la nouvelle propriété désactive les recherches persistantes si cela est absolument nécessaire.
Les privilèges définissent les droits d'accès dont bénéficient les administrateurs appartenant aux rôles ou groupes existant dans un domaine. Access Manager vous autorise à configurer les autorisations des types d'administrateurs suivants :
Les administrateurs de domaine peuvent exécuter toutes les tâches liées au domaine, y compris la définition des référentiels d'identité (magasins de données), la configuration de l'authentification et la définition des stratégies.
Les administrateurs de stratégie peuvent configurer des stratégies dans les domaines existants.
Les privilèges suivants sont pris en charge :
Accès en lecture et écriture à toutes les propriétés de stratégie et de domaine Définit les privilèges d'accès en lecture et écriture des administrateurs de domaine.
Accès en lecture et écriture aux propriétés de stratégie uniquement Définit les privilèges d'accès en lecture et écriture des administrateurs de stratégie.
Combinaison de privilèges pris en charge : Accès en lecture et écriture uniquement pour les propriétés de stratégie et accès en lecture seule aux magasins de données. Les autres combinaisons de privilèges ne sont pas prises en charge.
Lorsque les serveurs Access Manager sont déployés derrière un équilibreur de charge, le routage des demandes d'association basé sur les cookies empêche une requête cliente d'être acheminée vers un serveur Access Manager incorrect (c'est-à-dire vers un serveur n'hébergeant pas la session). Cette fonctionnalité a été implémentée dans Access Manager 7 2005Q4 patch 3.
Auparavant, en l'absence d'un tel routage, les requêtes des clients non basés sur un navigateur (comme les agents de stratégie et les clients utilisant le SDL client distant d'Access Manager) étaient souvent acheminées vers un serveur Access Manager sur lequel la session n'était pas hébergée. Pour envoyer la requête au serveur approprié, le serveur Access Manager devait alors valider la session au moyen d'une communication par canal retour, ce qui engendrait une dégradation des performances. Le routage des demandes d'association basé sur des cookies permet de ne pas recourir aux communications par canal retour et contribue donc à améliorer les performances d'Access Manager.
Pour mettre en œuvre le routage des demandes d'association basé sur des cookies, le déploiement d'Access Manager doit être configuré comme un site. Pour obtenir plus d'informations, reportez-vous à la section Configuring an Access Manager Deployment as a Site du Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.
Pour configurer le routage des demandes d'association basé sur des cookies :
Pour spécifier un nom de cookie, configurez la propriété com.iplanet.am.lbcookie.name dans le fichier AMConfig.properties. Access Manager génère ensuite le cookie d'équilibreur de charge à l'aide d'un ID de serveur à 2 octets (comme 01, 02 et 03). Si vous ne spécifiez pas de nom de cookie, Access Manager génère la valeur du cookie d'équilibreur de charge à l'aide du nom par défaut amlbcookie plus l'ID de serveur à 2 octets.
Si vous configurez le nom du cookie du serveur Access Manager, 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 Access Manager.
Remarque : Ne configurez pas la propriété com.iplanet.am.lbcookie.value car Access Manager définit la valeur du cookie à l'aide de l'ID de serveur à 2 octets.
Configurez l'équilibreur de charge avec le nom de cookie de l'étape 1. Vous pouvez utiliser un équilibreur de charge matériel ou logiciel avec votre déploiement Access Manager.
Si un basculement de session est implémenté, activez la propriété com.sun.identity.session.resetLBCookie pour l'agent de stratégie et le serveur Access Manager.
Pour un agent de stratégie, ajoutez la propriété au fichier AMAgent.properties et activez-la.
Pour un serveur Access Manager, ajoutez la propriété au fichier AMConfig.properties et activez-la.
Exemple :
com.sun.identity.session.resetLBCookie='true'
En cas de basculement, la session est acheminée vers un serveur Access Manager secondaire et la valeur du cookie d'équilibreur de charge est configurée sur l'ID de serveur du serveur Access Manager secondaire. Toute requête ultérieure de la session est acheminée vers le serveur Access Manager secondaire.
Pour configurer Windows Desktop SSO sous Windows 2003, comme indiqué dans la section Configuring Windows Desktop SSO du Sun Java System Access Manager 7 2005Q4 Administration Guide, utilisez la commande ktpass suivante :
ktpass /out filename /mapuser username /princ HTTP/hostname.domainname /crypto encryptiontype /rndpass /ptype principaltype /target domainname
Exemple :
ktpass /out demo.HTTP.keytab /mapuser http /princ HTTP/demo.identity.sun.com@IDENTITY.SUN.COM /crypto RC4-HMAC-NT /rndpass /ptype KRB5_NT_PRINCIPAL /target IDENTITY.SUN.COM
La syntaxe est décrite sur le site suivant :
La procédure suivante décrit comment configurer les mots de passe chiffrés d'un serveur d'interface utilisateur d'authentification distribuée communiquant avec un serveur Access Manager.
Pour configurer les mots de passe d'un serveur d'interface utilisateur d'authentification distribuée :
Sur le serveur Access Manager :
Chiffrez le mot de passe amadmin à l'aide de l'utilitaire ampassword -e. Par exemple, sur les systèmes Solaris :
# cd /opt/SUNWam/bin # ./ampassword -e amadmin-password AQIC0K3omEozd544XEJIg25GT2wi1D7UAQLX
Enregistrez la valeur chiffrée.
Copiez et enregistrez la valeur de la propriété am.encryption.pwd à partir du fichier AMConfig.properties du serveur Access Manager. Exemple :
am.encryption.pwd=ydV8JXhJF2J35vpxjZRiGt7SH/7mUr+Y
Sur le serveur d'interface utilisateur d'authentification distribuée, apportez les modifications suivantes au fichier AMConfig.properties :
Commentez la propriété com.iplanet.am.service.password.
Configurez la propriété com.iplanet.am.service.secret sur le mot de passe chiffré amadmin à l'étape 1a.
Ajoutez am.encryption.pwd et la valeur chiffrée que vous avez copiés à l'étape 1b. Exemple :
com.sun.identity.agents.app.username=username #com.iplanet.am.service.password=password com.iplanet.am.service.secret=AQIC0K3omEozd544XEJIg25GT2wi1D7UAQLX am.encryption.pwd=ydV8JXhJF2J35vpxjZRiGt7SH/7mUr+Y
Redémarrez le serveur d'interface utilisateur d'authentification distribuée.
Dans l'aide en ligne d'Access Manager Console, il manque l'état de sauvegarde de la procédure de création d'un nouveau nom de site sous Configuration>Propriétés du système>Plate-forme. Si vous ne cliquez pas sur Enregistrer après avoir ajouté un nouveau nom de site et que vous essayez ensuite d'ajouter un nom d'instance, la procédure échoue. Par conséquent, vous devez toujours cliquer sur Enregistrer après avoir ajouté le nom du site, puis ajouter le nom de l'instance.
Sous Solaris et Linux, le paramètre de configuration du mot de passe (amadmin ) administrateur d'Access Manager dans le fichier amsamplesilent est ADMINPASSWD. Sous Windows, le paramètre dans le fichier AMConfigurator.properties est ADMIN_PASSWD .
Si vous exécutez amconfig.bat sous Windows, définissez le mot de passe amadmin dans le fichier AMConfigurator.properties à l'aide du paramètre ADMIN_PASSWORD et non du paramètre ADMINPASSWD.
L'étape 3 de la procédure L'exécution de l'exemple de services Web renvoie le message Resource offering not found (6359900) n'est pas corrigée.
Le paramètre com.iplanet.am.session.protectedPropertiesList ne vous permet pas de protéger certaines propriétés essentielles ou de session interne contre des mises à jour à distance via la méthode SetProperty de Session Service. Le réglage de ce paramètre de sécurité clé “ masqué ” vous permet de personnaliser des attributs de session en vue d'une autorisation et dans le cadre d'autres fonctionnalités d'Access Manager. Pour utiliser ce paramètre :
À l'aide d'un éditeur de texte, ajoutez le paramètre au fichier AMConfig.properties .
Réglez le paramètre pour les propriétés de session que vous souhaitez protéger. Exemple :
com.iplanet.am.session.protectedPropertiesList = PropertyName1,PropertyName2,PropertyName3
Redémarrez le conteneur Web d'Access Manager pour appliquer les valeurs.
Après avoir appliqué le patch respectif, vous pouvez configurer les rôles et les rôles filtrés pour le plug-in LDAPv3, si les données sont stockées dans Sun Java System Directory Server (résout CR 6349959). Au niveau de la console d'administration Access Manager 7 2005Q4, dans la configuration LDAPv3, saisissez les valeurs suivantes pour le champ Types et opérations pris en charge du plug-in LDAPv3 :
role: read,edit,create,delete filteredrole: read,edit,create,delete
Vous pouvez saisir une ou plusieurs des entrées ci-dessus, en fonction des rôles et des rôles filtrés que vous prévoyez d'utiliser dans votre configuration LDAPv3.
Les propriétés suivantes du fichier AMConfig.properties ne sont pas utilisées :
com.iplanet.am.directory.host com.iplanet.am.directory.port
La propriété com.iplanet.am.session.client.polling.enable dans le fichier AMConfig.properties ne doit jamais être paramétrée sur true côté serveur.
Solution : Par défaut, cette propriété est paramétrée sur false. Elle ne doit jamais être paramétrée sur true.
L'URL par défaut de connexion réussie est incorrecte dans le fichier service.scserviceprofile.iplanetamauthservice.html de l'aide en ligne. Le champ URL par défaut de connexion réussie accepte une liste de valeurs multiples indiquant l'URL vers lequel les utilisateurs sont redirigés à l'issue d'une authentification réussie. Le format de cet attribut est clientType|URL, bien que vous puissiez ne spécifier que la valeur de l'URL, qui suppose un type HTML par défaut.
La valeur par défaut /amconsole est incorrecte.
Solution : La valeur par défaut appropriée est /amserver/console.
Pour activer le chiffrement XML pour Access Manager ou Federation Manager à l'aide du fichier JAR Bouncy Castle afin de générer une clé de transport, appliquez les étapes suivantes :
Si vous utilisez une version de JDK antérieure à la version 1.5, téléchargez le fournisseur JCE Bouncy Castle depuis le site Web de Bouncy Castle (http://www.bouncycastle.org/). Par exemple, pour JDK 1.4, téléchargez le fichier bcprov-jdk14-131.jar .
Si vous avez téléchargé un fichier JAR lors de l'étape précédente, copiez le fichier dans le répertoire jdk_root/jre/lib/ext.
Pour la version domestique de JDK, téléchargez les fichiers JCE Unlimited Strength Jurisdiction Policy correspondant à votre version de JDK depuis le site Web de Sun (http://java.sun.com). Pour IBM WebSphere, rendez-vous sur le site IBM correspondant pour télécharger les fichiers requis.
Copiez les fichiers US_export_policy.jar et local_policy.jar téléchargés dans le répertoire jdk_root/jre/lib/security .
Si vous utilisez une version de JDK inférieure à JDK 1.5, modifiez le fichier jdk_root/jre/lib/security/java.security et ajoutez Bouncy Castle en tant que fournisseur. Exemple :
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider
Définissez la propriété suivante du fichier AMConfig.properties sur true :
com.sun.identity.jss.donotInstallAtHighestPriority=true
Redémarrez le conteneur Web d'Access Manager.
Pour de plus amples informations, reportez-vous au problème ayant pour ID 5110285 (le chiffrement XML requiert un fichier JAR Bouncy Castle).