Sun OpenSSO Enterprise - 8.0 - notes de version

Problèmes d'OpenSSO Enterprise 8.0

Pour plus d'informations sur OpenSSO Enterprise, veuillez vous reporter à :

https://opensso.dev.java.net/servlets/ProjectIssues

Conteneur Web et problèmes de serveur

4077 : la configuration d'OpenSSO Enterprise sur WebLogic Server nécessite un nouveau ldapjdk.jar

La configuration d'OpenSSO Enterprise sur le serveur WebLogic a échoué car weblogic.jar met en paquet un fichier ldapjdk.jar plus ancien.

Sun fournit un nouveau fichier ldapjdk.jar qui inclut des correctifs connexes à la sécurité et à la performance. Vous devez fournir la solution suivante pour à la fois WebLogic Server 9.2 et WebLogic Server 10.

Solution de contournement. Mettez le ldapjdk.jar de Sun avant weblogic.jar dans le CLASSPATH, comme suit :

  1. Extrayez ldapjdk.jar depuis opensso.war dans un répertoire temporaire en utilisant la commande suivante :

    jar xvf opensso.war WEB-INF/lib/ldapjdk.jar

  2. Copiez le ldapjdk.jar ci-dessus extrait vers le répertoire de WebLogic lib.

    Par exemple, pour WebLogic Server 10 sur des systèmes Solaris ou Linux : BEA_HOME/weblogic_10.0/server/lib

    Ou, pour WebLogic Server 9.2 sur Windows : BEA_HOME\weblogic92\server\lib

  3. Préfixez le chemin vers ldapjdk.jarvers le chemin existant. en éditant le script de démarrage utilisé pour démarrer WebLogic Server. Dans les exemples suivants, BEA_HOME est l'endroit où est installé WebLogic Server.

    Pour WebLogic Server 9.2 sur Windows, éditez :

    BEA_HOME\weblogic92\samples\domains\wl_server\bin\startWebLogic.cmd

    Modifiez set CLASSPATH=%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH% en :

    set CLASSPATH=BEA_HOME\weblogic92\server\lib\ldapjdk.jar;%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH%
    

    Pour WebLogic 10 sur Windows, éditez :

    BEA_HOME\wlserver_10.0\samples\domains\wl_server\bin\startWebLogic.cmd

    Modifiez set CLASSPATH=%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH% en :

    set CLASSPATH=
    BEA_HOME\wlserver_10.0\server\lib\ldapjdk.jar;%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH%
    

    Pour WebLogic 9.2 MP2 sur Solaris ou Linux, éditez :

    /bea/weblogic92/samples/domains/wl_server_bin/ startWebLogic.sh

    ou

    /usr/local/bea/user_projects/domains/base_domain/bin/startWebLogic.sh

    Modifiez CLASSPATH="${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" en :


    CLASSPATH=
    "BEA_HOME/weblogic92/server/lib/ldapjdk.jar${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}"
    

    Pour WebLogic 10 sur Solaris ou Linux, éditez :

    /bea/wlserverc_10.0/samples/domains/wl_server/bin/startWebLogic.sh

    ou

    /bea/user_projects/domains/wl10_domain/bin/startWebLogic.sh

    Modifiez CLASSPATH="${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" en

    CLASSPATH=
    "BEA_HOME/wlserver_10.0/server/lib/ldapjdk.jar${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}"
    
  4. Redémarrez le serveur.

  5. Configurez OpenSSOEnterprise.

La valeur StuckThreadMaxTime de WebLogic Server est dépassée durant la configuration

Si vous configurez WebLogic Server 9.2 MP2 ou utilisez le configurateur et qu'il vous prend plus de 600 secondes pour finir la configuration, l'erreur suivante est retournée au terminal et au domaine WebLogic Server et aux journaux du serveur :

<Error> <WebLogicServer> <BEA-000337> <[STUCK] Exe 
cuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy 
for "681" seconds working on the request "Http Request: /opensso/setup/setSetup 
Progress", which is more than the configured time (StuckThreadMaxTime) of "600" 
seconds. Stack trace: ... 

Cette erreur apparaît car le serveur WebLogic a dépassé sa valeur par défaut “Stuck Thread Max Time” de 600 secondes.

Solution de contournement. Si le configurateur ne répond pas, redémarrez-le. Définissez une nouvelle valeur “Stuck Thread Max Time“ de WebLogic Server en changeant les 600 secondes par défaut pour une valeur plus élevée telle que 1200 secondes. Utilisez la console WebLogic pour modifier cette valeur ( base_domain > Environment > Servers > Admin Server > Configuration > Tuning ).

4099 : l'échantillon ID-WSF avec JDK 1.4 WAR a retourné une exception

Sur WebLogic Server 8.1, opensso-client-jdk14.war configuré pour ID-WSF a retourné une erreur en cherchant un service.

Solution de contournement. Ajoutez les fichiers JAR suivants sous weblogic-home/jdk142_08/jre/lib/ : jax-qname.jar, namespace.jar, relaxngDatatype.jar, xalan.jar et xsdlib.jar.

Le fichier xalan.jar est dans le répertoire WEB-INF/lib dans opensso.war. Les autres fichiers sont dans le répertoire WEB-INF/lib dans opensso-client-jdk14.war.

4094 : l'installation du multiserveur échoue quand le mot de passe anadmin et celui du gestionnaire de répertoire pour la configuration du magasin de données ne correspondent pas.

Ce problème arrive dans les conditions suivantes :

Solution de contournement. Il y a deux parties dans cette solution de contournement :

  1. Assurez-vous que votre mot de passe dn de liaison de serveur d'annuaire de configuration est le même que le mot de passe amadmin.

  2. Configurez le second serveur et les serveurs supplémentaires OpenSSO Enterprise. Pour réaliser l'installation du second serveur et pointer vers l'annuaire de configuration du serveur OpenSSO Enterprise, accédez simplement à la page du configurateur du second serveur OpenSSO Enterprise et saisissez le mot de passe amadmin, le domaine de cookies et d'autres détails pour l'étape 1 et l'étape 2.

    Pour l'étape 3, ne sélectionnez pas Ajouter au déploiement existant. Au contraire, sélectionnez l'option de première instance et fournissez le même nom d'annuaire de serveur, port, mot de passe et clé de chiffrement de votre premier serveur. Puis, procédez avec la configuration comme d'habitude.

4055 : erreur apparue après avoir ajouté une propriété avancée dans la console

L'ajout d'une propriété avancée dans la console a entraîné le serveur OpenSSO Enterprise à retourner une erreur. Ce problème peut apparaître après avoir ajouté une propriété de configuration avancée quelle qu'elle soit.

Solution de contournement. Si vous changez la configuration de serveur par défaut dans la console, vous devez redémarrer le conteneur de serveur Web OpenSSO Enterprise.

3387 : échec de la configuration sur Oracle Application Server 10g

Avec la version 10.1.3.1 d'Oracle Application Server 10g comme conteneur Web, la configuration d'OpenSSO Express a échoué avec une erreur d'exception.

Solution de contournement. Avant de configurer OpenSSO, ajoutez l'option JVM suivante à “Propriétés serveur” pour l'instance de serveur Oracle Application Server 10g cible.

-Doc4j.jmx.security.proxy.off=true

2222 : réinitialisation du mot de passe et les services de verrouillage de compte rapportent des erreurs de notification

OpenSSO Enterprise soumet des notifications e-mail en utilisant un nom d'expéditeur non qualifié, Identity-Server, qui retourne des entrées d'erreur dans les journaux.

Solution de contournement. Modifiez le nom d'expéditeur d'Identity-Server à Identity-Server@hostname.domainname dans les fichiers suivants :

Problèmes de magasins de données

4102 : la TTL pour la configuration de la gestion de service ne fonctionne pas.

La durée de vie (Time To Live, TTL) pour la configuration de la gestion de service ne fonctionne pas car la propriété TTL n'a pas été initialisée.

4085 : OpenSSO Enterprise ne peut stocker la CRL dans le répertoire LDAP

Après avoir obtenu la liste de révocation de certificat (Certificate Revocation List, CRL) dans l'extension du point de distribution CRL, OpenSSO Enterprise ne stocke pas le CRL dans le répertoire LDAP.

3287 : la configuration de réplication dépend d'une seconde instance de Glassfish

Dans ce scénario, OpenSSO Enterprise est déployé sur deux instances Glassfish (ou Application Server 9.1) sur le serveur Windows Vista. Durant la configuration de la seconde instance d'OpenSSO Enterprise, la réplication de la configuration utilisant l'option “Add to Existing Deployment” est en attente.

Solution de contournement. Ce problème existe toujours sous les systèmes Windows Vista. Pour les systèmes Windows autres que Vista, ajoutez l'option JVM de GlassFish (ou Application Server 9.1) suivante :

-Dcom.sun.enterprise.server.ss.ASQuickStartup=false

3350, 2867 : LDAP Follows Referral doit être désactivé pour Active Directory Data Store

Un magasin de données d'Active Directory dépend parfois du système. Ce problème peut aussi apparaître quand vous créez un nouveau magasin de données Active Directory.

Solution de contournement. Dans la console d'administration d'OpenSSO Enterprise, désactivez LDAP Follows Referral pour le magasin de données d'Active Directory.

  1. Cliquez sur Access Control, top-level-realm, Data Stores, ActiveDirectory-data-store-name.

  2. Désélectionnez Activé pour leLDAP Follows Referral.

  3. Enregistrez vos modifications.

Le basculement n'apparaît pas pour le plug-in Access Manager SDK (AMSDK)

Si OpenSSO Enterprise est configuré avec le plug-in AMSDK et que le serveur d'annuaire est paramétré pour MMR, le basculement n'arrive pas si une instance de serveur d'annuaire descend.

Problèmes d'authentification

4103 : le module d'authentification SSO de Windows Desktop retourne l'erreur “Pas de configuration trouvée”

Si vous configurez un module d'authentification SSO de Windows Desktop pour réaliser une authentification Kerberos depuis Internet Explorer 6.0 sur Windows Server 2003, l'erreur “Pas de configuration trouvée” est retournée.

4100 : échec de l'authentification de certificat avec vérification de CRL

Si vous configurez une authentification de certificat et activez Faire correspondre certificat à la CRL, il y a échec de l'authentification. Veuillez vous reporter aussi au problème 4085 : OpenSSO Enterprise ne peut stocker la CRL dans le répertoire LDAP.

4054 : échec de l'authentification amadmin avec le paramètre URL org

Si l'administrateur de OpenSSO Enterprise (amadmin) crée un nouveau domaine (tel que myorg) et essaie plus tard de s'y connecter de la façon suivante :

http://host:port/opensso/UI/Login?org=myorg

OpenSSO Enterprise retourne une erreur d'échec d'authentification.

Solution de contournement. En tant qu'amadmin, vous pouvez vous connecter seulement au domaine root (et seulement aux modules de magasin de données ou d'application)

1781 : échec de la connexion amadmin pour l'authentification de ce qui n'est pas le magasin de données

Si vous modifiez le module d'authentification pour le domaine root en quelque chose d'autre que magasin de données, amadmin ne pourra pas se connecter dans la console.

Solution de contournement. Connectez-vous en utilisant http://host.domain/deployurl/UI/Login?module=DataStore

Problèmes liés aux stratégies

3952 : des échantillons de serveur ne trouvent pas le lien d'échantillons de stratégie.

L'index.html sous host : port/

1. Authentication Samples
2. ID-FF Sample
3. SAMLv2 Sample
4. Multi-Federation Protocols Sample

Cependant, le lien suivant vers les échantillons de stratégie manque dans index.html : host : port/ uri/samples/policy/policy-

Solution de contournement : ouvrir le fichier host : port/uri/samples/policy/policy-plugins.html dans votre navigateur.

3949 : la vérification OSCP a besoin d'une permission ajoutée au fichier de stratégie du serveur.

Pour permettre la vérification OCSP pour un conteneur Web OpenSSO qui a activé Java Security Manager, ajoutez la permission suivante au fichier (ou équivalent) de stratégie de serveur.

permission.java.security.SecurityPermission "getProperty.ocsp.*";

3796 : échec de création d'un Fedlet dans un déploiement pour console seulement.

Si vous générez un déploiement pour console seule, la création d'un Fedlet en utilisant les tâches communes de console a échoué avec un message d'erreur spécifiant qu'il n'y avait pas de fichier ni de répertoire pour sp-extended.xml. La propriété com.iplanet.services.configpath n'a pas été définie par le configurateur pour console seulement.

Solution de contournement. Éditez le fichier AMConfig.properties et définissez la propriété com.iplanet.services.configpath dans l'annuaire de configuration. Par exemple :

com.iplanet.services.configpath=/consoleonly

2381 : le sujet de stratégie des rôles d'Access Manager est pris en compte seulement avec le magasin de données du répertoire d'Access Manager

Le sujet de stratégie d'Access Manager Roles est pris en compte seulement avec le magasin de données du répertoire d'Access Manager. Par défaut, ce sujet est désactivé dans la configuration de stratégie. Il faut donc activer le sujet de stratégie d'Access Manager Roles seulement si le type de magasin de données est configuré pour utiliser le plug-in AMSDK.

Pour plus d'informations, veuillez vous reporter au Chapitre 14, Enabling the Access Manager SDK (AMSDK) Identity Repository Plug-in du Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

Problèmes de session

3910 : échec de setup.bat de ssoSessionTools.zip pour installer les outils

Après le décompression du fichier ssoSessionTools.zip, échec de l'exécution du script setup.bat à installer les scripts de session et retourne l'erreur suivante :

Impossible de localiser la spécification de satisfaction des besoins de JRE "1.4+"

Solution de contournement. Dans le script setup.bat, supprimez -version : "1.4+" de la commande java.exe et ré-exécutez le script.

2827 : la configuration d'un site n'ajoute pas le second serveur au site

La configuration de basculement de session n'ajoute pas la seconde instance OpenSSO Enterprise à la liste de serveurs assignés.

Solution de contournement. Utilisez la console OpenSSO Enterprise ou l'utilitaire ssoadm pour ajouter manuellement l'instance du second serveur à la liste de serveurs.

Problèmes liés aux utilitaires de ligne de commande

4079 : échec de la commande ssoadm import-svc-cfg lors de l'utilisation de Directory Server comme magasin de données de configuration

Parfois la sous-commande import-svc-cfg échoue car OpenSSO Enterprise ne peut supprimer des nœuds dans le magasin de données du gestionnaire de service. Les scénarios suivants peuvent causer ce problème :

  1. configurer OpenSSO Enterprise en utilisant Sun Java System Directory Server à distance comme magasin de données de configuration.

  2. exporter le fichier XML en utilisant la commande ssoadm export-svc-cfg.

  3. Ré-importer les données de service XML obtenues à l'étape 2 en utilisant la commande ssoadm import-svc-cfg.

  4. Quand il vous est demandé de supprimer les données existantes, choisissez oui.

    Le message d'erreur suivant est retourné : exception LDAP inattendue.

Solution. Ré-exécutez la commande ssoadm import-svc-cfg jusqu'à ce qu'elle réussisse.

3955 : impossible d'exécuter la commande ssoadm

Vous ne pouvez pas exécuter la commande ssoadm avec la commande get-realm à cause de cette exception.

Logging configuration class "com.sun.identity.log.s1is.LogConfigReader" failed
com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction:
FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
       com.sun.identity.agents.app.username
       com.iplanet.am.service.password
Logging configuration class "com.sun.identity.log.s1is.LogConfigReader" failed
com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction:
FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
       com.sun.identity.agents.app.username
       com.iplanet.am.service.password
AdminTokenAction:  FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
       com.sun.identity.agents.app.username
       com.iplanet.am.service.password

Vérifiez si le mot de passe amadmin est différent de celui du gestionnaire d'annuaire pour le magasin de données de gestion de service. Si oui, appliquez la solution de contournement suivante.

Solution de contournement. Modifiez le XML de configuration de serveur comme suit :

  1. Connectez-vous à la console d'administration OpenSSO en tant qu'amadmin.

  2. Utilisez ssoadm.jsp get-svrcfg-xml pour obtenir le XML de configuration de serveur.

  3. Utilisez encode.jsp pour coder le mot de passe amadmin.

  4. Définissez le mot de passe à deux endroits représentés par amadmin-password dans le XML. Par exemple :

    <User name="User1" type="proxy">
                <DirDN>
                    cn=puser,ou=DSAME Users,dc=opensso,dc=java,dc=net
                </DirDN>
                <DirPassword>
                   amadmin-password
                </DirPassword>
            </User>
            <User name="User2" type="admin">
                <DirDN>
                    cn=dsameuser,ou=DSAME Users,dc=opensso,dc=java,dc=net
                </DirDN>
                <DirPassword>
                   amadmin-password
                </DirPassword>
            </User>
            <BaseDN>
                dc=opensso,dc=java,dc=net
            </BaseDN>
        </ServerGroup>
  5. Utilisez ssoadm.jsp get-svrcfg-xml pour obtenir le XML de configuration de serveur modifiée.

2905 : l'entrée jss4.jar manque dans le chemin ssoadm

Après avoir exécuté le script setuppour l'utilitaire ssoadmin, l'essai d'exécution de ssoadm retourne une erreur NoClassDefFoundError. Ce problème apparaît pour une instance d'OpenSSO Enterprise mise à niveau.

Solution de contournement. Pour utiliser JSS, ajoutez jss4.jar au chemin de classe (classpath) et définissez la variable d'environnement LD_LIBRARY_PATH. (Si vous utilisez le JCE par défaut, jss4.jar n'a pas besoin d'être dans le chemin de classe.)

Problèmes de client SDK

4081 : le cache SMS est désactivé par défaut sur le client SDK

Pour une installation de client SDK, le cache du service de gestion de service (Service Management Service, SMS) est désactivé par défaut.

Solution de contournement : pour des applications de sécurité de services Web (Web Services Security, WSS), définissez com.sun.identity.sm.cache.enabled=false dans le fichier AMConfig properties ; sinon le correctif pour le problème 3171 ne fonctionnera pas.

Pour toutes les autres applications client SDK, définissez com.sun.identity.cache.enabled=true dans le fichier AMConfig properties pour permettre la mise en cache de SMS, ce qui peut éviter des problèmes de performance.

4080 : le configurateur client SDK a mis le mauvais secret partagé dans le fichier de propriétés AMConfig

Le configurateur de fichier SDK WAR de client SDK a mis le mauvais secret partagé dans le fichier de propriétés AMConfig.

Solution de contournement. Copiez la valeur secrète partagée et la clé de chiffrement du serveur OpenSSO Enterprise vers le fichier de client SDK AMConfig.properties dans le répertoire $HOME/OpenSSOCLient.

Problèmes liés à SAML et aux fédérations

3923 : échec sur Oracle Application Server de la création d'une entité (IDP ou SP) dans la page des tâches communes de console

Avec OpenSSO Enterprise déployé sur Oracle Application Server, la création d'une entité (IDP ou SP) dans la page de tâches communes de console a entraîné une exception.

Solution de contournement. Quand opensso.war est déployé sur Oracle Application Server, désactivez l'option d'importation pour le fichier oracle.xml dans l'affichage du plan de déploiement (Deploy: Deployment Settings > Configure Class Loading > oracle.xml).

3065 : le même ID contextuel est utilisé pour tous les utilisateurs dans des enregistrements de journal ID-FF

Tous les enregistrements de journal ID-FF ont le même ID contextuel (ou login), même s'ils concernent différents utilisateurs.

2661 : logout.jsp n'a pas compilé sur WebSphere Application Server 6.1

Le fichier logout.jsp nécessite JDK 1.5, mais le niveau de source JDK pour les fichiers JSP est défini à JDK 1.3 sur IBM Websphere Application Server 6.1.

Solution de contournement. Veuillez vous reporter à 1977 : échec des fichiers configure.jsp de l'échantillon SAMLv2 sur WebSphere Application Server 6.1.

1977 : échec des fichiers configure.jsp de l'échantillon SAMLv2 sur WebSphere Application Server 6.1

Sur une instance de WebSphere Application Server 6.1, échec de compilation des fichiers /sample/saml2/sp/configure.jsp et /sample/saml2/idp.configure.jsp. Les fichiers configure.jsp nécessitent JDK 1.5, mais le niveau de source JDK pour les fichiers JSP est défini à JDK 1.3 sur IBM Websphere Application Server 6.1.

Solution de contournement : éditez les paramètres de configuration du moteur JSP pour définir le niveau de source JDK à 1.5  :

  1. Ouvrez le fichier WEB-INF/ibm-web-ext.xmi.

    Les paramètres de configuration du moteur JSP sont stockés dans un répertoire de configuration d'un module Web ou dans un répertoire de binaires d'un module Web dans le fichier WEB-INF/ibm-web-ext.xmi :

    Annuaire de configuration Par exemple :

    {WAS_ROOT}/profiles/profilename/config/cells/cellname/applications/
    enterpriseappname/deployments/deployedname/webmodulename/

    Le répertoire des binaires, si une application était déployée dans WebSphere Application Server avec l'indicateur “Utiliser la configuration binaire” mis à vrai. Par exemple :

    {WAS_ROOT}/profiles/profilename/installedApps/nodename/
    enterpriseappname/webmodulename/
  2. Supprimez le paramètre compileWithAssert en supprimant l'instruction du fichier ou en entourant l'instruction avec des balises de commentaire (<!— et –>).

  3. Ajoutez le paramètre jdkSourceLevel avec la valeur de 15. Par exemple :

    <jspAttributes xmi:id="JSPAttribute_1" name="jdkSourceLevel" value="15"/>

    Remarque : le nombre entier (_1) dans JSPAttribute_1 doit être unique dans le fichier.

  4. Enregistrez le fichier ibm-web-ext.xmi.

  5. Redémarrer l'application.

Pour plus d'informations sur le paramètre jdkSourceLevel et aussi sur d'autres paramètres de configuration du moteur JSP, veuillez vous reporter à :

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/rweb_jspengine.html

Problèmes de services de sécurité Web (Web Services Security, WSS)

4057 : la configuration de fournisseur de service dynamique avec un point d'extrémité ne prend pas effet

Il y a échec si vous paramétrez le cas d'utilisation de proxy de type échantillon de prêt pour la sécurité des services Web (WSS) et que vous créez deux fournisseurs de service (WSP) avec des noms de profil autres que wsp.

Solution de contournement. Pour les services Web de type application JAX-WS/web, utilisez la fin de point statique comme nom WSP pour prendre en charge de nombreux services Web. Pour des services Web de type EJB, utilisez la configuration WSP par défaut.

Problèmes de mises à niveau, de compatibilité et de coexistence

4108 : utilisation d'une clé de chiffrement incorrecte après avoir configuré OpenSSO Enterprise par rapport au schéma existant (DIT)

Après la configuration d'OpenSSO Enterprise par rapport au schéma existant (DIT), vous ne pouvez vous connecter à la console, car la clé de chiffrement saisie durant la configuration (celle de l'ancienne instance d'Access Manager ou de Federation Manager) n'est pas utilisée. Au contraire, une nouvelle clé de chiffrement est générée, ce qui crée un fichier incorrect serverconfig.xml.

Solution de contournement.

  1. Passez au répertoire de config OpenSSO Enterprise

  2. Modifiez la clé de chiffrement dans le fichier AMConfig.properties avec la valeur correcte.

  3. Copiez le répertoire de sauvegarde de serverconfig.xml de l'instance précédente d'Access Manager ou de Federation Manager.

  4. Redémarrez le serveur OpenSSO Enterprise

3962 : URL de console incorrecte retournée après authentification pour utilisateur non admin.

Si OpenSSO est configuré avec un schéma de Directory Server (DIT) Access Manager 7.1 en mode coexistence et qu'un utilisateur non admin se connecte dans la console OpenSSO, l'utilisateur est mené à une URL invalide. Par exemple :

http://ssohost.example.com:8080/amserver/..amserver/base/AMAdminFrame

Solution de contournement. Saisissez l'URL comme suit :

protocole://hostdomain:port/deploy_uri/idm/EndUser

Par exemple :

http://ssohost.example.com:8080/amserver/idm/EndUser

3961 : amadmin ne peut se connecter à la console OpenSSO en mode coexistence

Si OpenSSO est configuré avec un Directory Server schema (DIT) Access Manager 7.1 en mode coexistence, l'essai de connexion en tant qu'amadmin à la console en utilisant l'authentification LDAP échoue.

Solution de contournement. Pour se connecter en tant qu'amadmin à la console OpenSSO en mode coexistence, ajoutez le paramètre de requête module=DataStore. Par exemple :

protocol://host.domain:port/deploy_uri/UI/Login/?module=DataStore

Par exemple :

http://ssohost.example.com:8080/amserver/UI/Login/?module=DataStore

2348 : expliquez dans la documentation la prise en charge de serveur d'interface utilisateur d'authentification distribuée

Le composant de serveur d'interface utilisateur d'authentification distribuée d'OpenSSO Enterprise fonctionne seulement avec OpenSSO Enterprise. Les scénarios suivants ne sont pas pris en charge :

830 : les métadonnées de schéma ID-FF n'ont pas de compatibilité ascendante

Si vous faites une mise à niveau depuis une version précédente d'Access Manager ou de Federation Manager vers OpenSSO Enterprise 8.0, les profils ID-FF ne fonctionnent pas sauf si vous faites une mise à niveau du schéma Access Manager ou Federation Manager.

Solution de contournement. Avant d'essayer les profils ID-FF, faites une mise à niveau du schéma d'Access Manager ou de Federation Manager. Pour plus d'informations sur les mises à niveau de schémas, veuillez vous reporter au Sun OpenSSO Enterprise 8.0 Upgrade Guide .

Problèmes d'internationalisation

4090 : les droits qui ne sont pas en anglais ne sont pas compréhensibles.

Solution de contournement : pour afficher les droits localisés, qui sont fournis en format .txt, utilisez un navigateur avec le codage spécifié pour chaque langue dans le navigateur comme suit :

4051 : le nom du partenaire de confiance multioctect est illisible dans la console.

Dans la console OpenSSO, si vous allez dans Federation > SAML1.x Configuration, puis créez un nouveau partenaire de confiance avec un nom multioctet dans la section paramètres communs, celui-ci est illisible.

3993 : la page d'utilisateur final affiche des points d'interrogation pour les langues CCK et JA.

Sur le conteneur Web Geronimo dans les langues CCK et JA, si vous vous connectez en tant qu'utilisateur autre qu'amadmin, les pages Contrôle d'accès, Domaine, Général, Utilisateur final (http://host:port/deployuri/idm/EndUser) affichent des points d'interrogation.

3076 : l'aide en ligne “Astuces pour la recherche” affiche une erreur 404 dans toute langue autre que l'anglais

Si vous vous connectez sur la console OpenSSO dans une langue qui n'est pas l'anglais, telle que le français, cliquez sur Aide, puis sur “Astuces pour la recherche”, le volet d'aide de droite affiche une erreur 404.

Solution de contournement. Pour afficher “Astuces sur la recherche? en anglais, définissez les langues du navigateur en anglais, puis actualiser la fenêtre d'aide en ligne.

3763 : certains caractères non-ASCII sont incompréhensibles quand le conteneur Web est en langue C

Si vous démarrez le conteneur Web dans la langue C et que vous définissez la langue de votre navigateur en une langue telle que le français, après la connexion à la console d'administration, certains caractères sont illisibles.

3713 : la page de réinitialisation du mot de passe n'est pas localisée pour les langues CCJK

Pour les langues CCJK, la page de réinitialisation du mot de passe (http://host :port/deployuri/password) n'est pas localisée.

3590 : modifiez l'emplacement pour les fichiers dounix_msgs.po

Les fichiers dounix_msgs.po pour le module d'authentification Unix n'ont pas été traduits car le module d'authentification Unix ne sera pas inclus dans la future version d'OpenSSO Enterprise. Veuillez consulter Notifications et annonces de désapprobation

1793 : échec d'authentification avec un caractère multioctet pour org ou pour un module dans le paramètre de requête.

SI vous essayez de vous connecter dans la console OpenSSO en utilisant le paramètre org ou module avec des caractères qui ne sont pas UTF-8, la connexion échoue. Par exemple : http://host:port/ deplyuri/UI/Login?module=Japanese-string&gx_charset=UTF-8

Solution de contournement. Utilisez des caractères d'encodage d'URL UTF-8 tels que %E3%81%A6 au lieu de caractères natifs.

Problèmes de localisation

4017 : dans la langue espagnole, “2.2 Agents" est traduit seulement comme Agentes dans la console

Si la console OpenSSO est en espagnol, le 2.2 manque à la traduction de “2.2 Agents".

3994 : en espagnol, impossible d'accéder à Certificate for Configuration > Authentification

Si la console OpenSSO est en espagnol, cliquez sur Configuration, Authentification et puis Certificate returns an error.

3971 : en chinoise (zh_CN), l'aide en ligne est en anglais

Dans la langue chinoise (zh_CN). le texte de l'aide en ligne de la console est affiché en anglais plutôt qu'en chinois. Si vous définissez la langue préférée dans votre navigateur à zh_CN, seul le texte de l'aide en ligne dans l'arborescence à gauche sera en anglais. Si vous définissez la langue préférée dans votre navigateur à zh, tout le texte de l'aide en ligne sera en anglais.

Solution de contournement. Copiez le contenu d'aide en ligne zh_CN vers un nouveau répertoire zh dans le répertoire webapps du conteneur Web et redémarrez le conteneur Web.

Par exemple pour Apache Tomcat, copiez : /Tomcat6.0.18/webapps/opensso/html/zh_CN/* vers un nouveau répertoire nommé /Tomcat6.0.18/webapps/opensso/html/zh/. Puis redémarrez le conteneur Tomcat.

3802 : problèmes dans la partie française de la mention de copyright

Dans la partie française de la mention de copyright, dans “Etats-Unis? il manque un accent et un espace manque après la virgule dans “armes nucléaires,des missiles? et des espaces ne doivent pas être mis dans “Etats - Unis?.