|
| |
| Sun Java Enterprise System 2005Q4 Guide de mise à niveau | |
Chapitre 11
Access ManagerCe chapitre décrit les procédures de mise à niveau du logiciel Access Manager de versions Java ES antérieures vers Java ES 2005Q4 (version 4) : Sun Java System Access Manager 7 2005Q4.
Ce chapitre propose une présentation générale des problèmes et procédures de mise à niveau de Access Manager pour les différentes méthodes de mise à niveau prises en charge par Java ES version 4. Il traite des mises à niveau sous les systèmes d’exploitation Solaris et Linux :
Présentation des mises à niveau d’Access ManagerCette section présente les aspects généraux d’Access Manager qui ont un impact sur la mise à niveau vers Java ES 2005Q4 (version 4) :
À propos d’Access Manager pour Java ES version 4
Access Manager pour Java ES version 4 a subi diverses améliorations. En arrière-plan, l’architecture du produit a été revue de sorte à prendre en charge plusieurs référentiels d’identité ou magasins de données utilisateur. Cette version d’Access Manager prend donc en charge non seulement l’annuaire LDAP, tel que Directory Server, mais également d’autres protocoles et formats de stockage de données. Access Manager pour la version 4 inclut de nouveaux services et interfaces afin de prendre en charge l’intégration de plusieurs référentiels d’identité.
Du côté de l’interface, une nouvelle console Access Manager permet de configurer les nouveaux services et référentiels d’identité d’Access Manager.
Les nouvelles fonctions et interfaces font d’Access Manager pour la version 4 une toute nouvelle version. Afin de proposer une compatibilité ascendante, la version 4 peut être exécutée en mode hérité, qui prend en charge les composants Java ES dépendant des services Access Manager pour la version 3 (pour plus d’informations, reportez-vous à la section Problèmes de compatibilité).
Présentation de la mise à niveau d’Access Manager
Le Tableau 11-1 répertorie les méthodes de mise à niveau d’Access Manager vers Java ES version 4 prises en charge. Il s’applique à la fois à Solaris et Linux.
Tableau 11-1 Méthodes de mise à niveau vers Java ES version 4 : Sun Java System Access Manager 7 2005Q4
Version de Java ES
Access Manager Version
Approche globale
Reconfiguration requise
Version 3
Sun Java System Access Manager
6.3 2005Q1Mise à niveau directe :
suppression de la version correspondant à la version 3, puis installation complète et reconfiguration de la version 4.Données de configuration
JSP personnalisées pour la console et l’interface d’authentification d’Access Manager
Schéma d’annuaire
Version 2
Sun Java System Identity Server
6.2 2004Q2
mais aussi 6.2 SP1Mise à niveau directe :
suppression de la version correspondant à la version 2, puis installation complète et reconfiguration de la version 4.Données de configuration
JSP personnalisées pour la console et l’interface d’authentification d’Access Manager
Schéma d’annuaire
Version 1
Sun ONE Identity Server 6.1
Pas de mise à niveau directe :
vous pouvez d’abord effectuer une mise à niveau vers la version 3 à l’aide des procédures fournies dans le Guide de migration et de mise à niveau de Sun Java Enterprise System 2005Q1
(http://docs.sun.com/doc/819-2234).Mettez ensuite la version 3 à niveau vers la version 4.
Données de configuration
JSP personnalisées pour la console et l’interface d’authentification d’Access Manager
Schéma d’annuaire
Versions antérieures à Java ES
Sun ONE Identity Server 6.0 ou 6.0 SP 1 ou
iPlanet Directory Server Access Management Edition (DSAME) 5.1
Pas de mise à niveau directe.
Données d’Access Manager
Access Manager, comme les autres composants Java ES, utilise divers types de données, qui, pour une mise à niveau particulière, peuvent requérir une migration vers une version mise à niveau. Le tableau suivant affiche le type de données susceptible d’être affecté par une mise à niveau du logiciel Access Manager.
Problèmes de compatibilité
Les nouvelles fonctionnalités d’Access Manager pour la version 4 incluent les nouvelles interfaces suivantes :
- plug-ins pour référentiels d’identité et d’arrière-plan multiples ;
- nouvelle structure d’arborescence des informations d’annuaire pour le stockage des informations de configuration du service de sorte que les propriétés d’authentification et les stratégies d’autorisation puissent être groupées dans des domaines de contrôle d’accès qui peuvent être associés à un utilisateur ou un groupe d’utilisateur ;
- nouvelle API pour les clients Access Manager ;
- nouvelle interface utilisateur de la console Access Manager.
Pour qu’Access Manager prenne en charge ces nouvelles interfaces, vous devez le configurer pour une exécution en mode amélioré (domaine). Toutefois, le mode domaine n’est pas compatible avec Access Manager pour Java ES version 3 ou version 2. Par exemple, les données d’annuaire doivent être migrées pour prendre en charge le mode domaine. La console Access Manager améliorée est requise pour la prise en charge des services Access Manager améliorés.
En outre, le mode domaine ne prend pas en charge les autres composants Java ES, tels que Portal Server, Communications Express, Messaging Server et d’autres.
Pour la prise en charge de la compatibilité ascendante, Access Manager pour la version 4 peut être configurée pour une exécution en mode hérité. Avec quelques petites exceptions (voir le manuel Notes de version de Sun Java System Access Manager 7 2005Q4 (http://docs.sun.com/doc/819-3478), le mode hérité est compatible de manière ascendante avec Access Manager pour la version 3.
Le mode hérité est indispensable à la prise en charge d’autres composants Java ES, ainsi que d’anciennes versions d’agents de modalité d’Access Manager, qui ne peuvent pas interagir avec Access Manager en mode domaine. Cette incompatibilité constitue un point important de la mise à niveau et signifie que, dans la plupart des déploiements de Java ES, Access Manager doit être mis à niveau vers la version 4 en mode hérité.
Toutefois, même lorsqu’il est configuré pour fonctionner en mode hérité, Access Manager pour la version 4 est incompatible avec Delegated Administrator pour la version 3. Si Access Manager est mis à niveau vers la version 4, Delegated Administrator doit l’être vers cette même version afin de pouvoir utiliser le provisioning utilisateur pour Messaging Server et Calendar Server. Cependant, Messaging Server et Calendar Server n’ont pas besoin, eux, d’être mis à niveau vers la version 4.
Dépendances d’Access Manager
Les dépendances d’Access Manager par rapport à d’autres composants Java ES peuvent avoir une influence sur la procédure de mise à niveau et de reconfiguration du logiciel Access Manager. Les modifications apportées aux interfaces ou fonctions d’Access Manager, par exemple peuvent demander une version mise à niveau des composants dont dépend Access Manager. Le besoin de mettre à jour ces composants dépend de la méthode de mise à niveau spécifique.
Access Manager présente des dépendances par rapport aux composants Java ES suivants :
- Composants partagés. Access Manager présente des dépendances par rapport à des composants partagés Java ES particuliers (voir le Tableau 1-6). Les mises à niveau d’Access Manager peuvent dépendre des versions mises à niveau de ces composants.
- Conteneur Web. Access Manager dépend des services de conteneur Web qui sont fournis par Java ES Web Server, Java ES Application Server ou par des conteneurs Web tiers (de Weblogic et WebSphere). Les mises à niveau d’Access Manager doivent donc être reconfigurées pour une instance de conteneur Web. De plus, toute JSP personnalisée pour la console Access Manager ou pour l’interface d’authentification doit être migrée vers l’environnement Access Manager mis à niveau.
- Directory Server. Access Manager stocke des données de configuration et accède aux données d’utilisateur stockées dans Directory Server. Ainsi, les mises à niveau de Access Manager peuvent requérir des extensions du schéma d’annuaire.
Mise à niveau d’Access Manager à partir de Java ES version 3Cette section fournit des informations sur la mise à niveau d’Access Manager à partir de Java ES 2005Q1 (version 3) vers Java ES 2005Q4 (version 4). Elle aborde les thèmes suivants :
Introduction
Lors de la mise à niveau d’Access Manager pour Java ES version 3 vers la version 4, tenez compte des aspects suivants du processus de mise à niveau :
- Approche générale de mise à niveau. La mise à niveau est effectuée par la suppression de versions précédentes et l’installation de la version 4. Le script ampre70upgrade est fourni pour la suppression de la version correspondant à la version 3 et le programme d’installation Java ES permet alors d’installer la version 4. Access Manager est ensuite reconfiguré à l’aide du script amconfig et le schéma d’annuaire est migré à l’aide du script amupgrade.
- Dépendances pour la mise à niveau. Étant donné qu’Access Manager présente des dépendances par rapport à un certain nombre de composants partagés Java ES (voir le Tableau 1-6), Access Manager pour la version 4 est compatible avec les versions de tous ces composants pour la version 3. La mise à niveau de ces composants est donc facultative par rapport à la mise à niveau d’Access Manager vers la version 4.
De plus, Access Manager pour la version 4 dépend de Directory Server et de Web Server (ou d’Application Server ou de conteneurs Web tiers), comme expliqué dans la section Dépendances d’Access Manager. Toutefois, il s’agit de dépendances souples de mise à niveau. La mise à niveau de ces composants est facultative dans le cadre de la mise à niveau d’Access Manager vers la version 4.
- Compatibilité ascendante. Access Manager pour la version 4 n’est pas compatible avec la version 3, en revanche, il prend en charge le mode hérité compatible (voir la section Problèmes de compatibilité).
- Annulation de la mise à niveau. Il n’existe aucun utilitaire d’annulation de la mise à niveau d’Access Manager. En réalité, le nombre de reconfigurations requises pour restaurer Access Manager à son état initial rend toute annulation peu pratique.
- Problèmes relatifs à la plate-forme. L’approche générale de la mise à niveau d’Access Manager est identique pour les systèmes d’exploitation Solaris et Linux. Les procédures suivantes indiquent les commandes spécifiques à la plate-forme ou l’emplacement des fichiers si nécessaire.
Mise à niveau complète d’Access Manager pour la version 3
Cette section explique comment effectuer une mise à niveau complète d’Access Manager pour Java ES version 3 vers Java ES version 4 :
Tâches à exécuter avant la mise à niveau
Avant de mettre à niveau Access Manager, réalisez les procédures décrites dans les sections ci-après.
Vérifier les informations sur la version actuelle
Vous pouvez vérifier la version actuelle de Access Manager à l’aide de la commande suivante :
Mettre à niveau les composants présentant des dépendances par rapport à Access Manager
Il est en général recommandé de mettre à niveau tous les composants Java ES installés sur un ordinateur (et dans son environnement) vers Java ES version 4. Toutefois, puisque Access Manager ne requiert pas la mise à niveau des composants Java ES version 3 dont il dépend, cette tâche est facultative.
En revanche, si vous choisissez de mettre à niveau tous les composants présentant des dépendances par rapport à Access Manager, vous devez le faire dans l’ordre suivant, et ce, avant de mettre à niveau Access Manager. Vous pouvez ignorer tout composant déjà mis à niveau.
- Composants partagés. Les instructions de mise à niveau des composants partagés Java ES vers la version 4 sont présentées dans la section Chapitre 2, « Mise à niveau des composants partagés Java ES ».
- Directory Server. Les instructions de mise à niveau de Directory Server vers la version 4 sont présentées dans le Chapitre 4, « Directory Server et Administration Server ».
- Logiciels de conteneur Web. Les instructions de mise à niveau de Web Server ou d’Application Server sont présentées respectivement dans le Chapitre 6, « Web Server » et le Chapitre 9, « Application Server ».
Si le conteneur Web n’est pas mis à niveau avant Access Manager, la procédure de mise à niveau (à l’aide du script amconfig) configurera et redéploiera Access Manager sur le conteneur Web existant.
Sauvegarder les données de Directory Server
Le processus de mise à niveau d’Access Manager utilise des scripts qui modifient le schéma de Directory Server. Par conséquent, avant de mettre à niveau Access Manager, sauvegardez vos données Directory Server à l’aide de la console Directory Server ou d’un utilitaire de ligne de commande, tel que db2bak.
Pour plus d’informations sur la sauvegarde de Directory Server, reportez-vous au manuel Sun Java System Directory Server Administration Guide (http://docs.sun.com/doc/817-7613).
Sauvegarder les informations de configuration de Access Manager pour la version 3
Étant donné que la reconfiguration du logiciel Access Manager pour la version 4 requiert la reconfiguration de la version 3, il est indispensable de sauvegarder les fichiers de configuration à un emplacement donné. Vous devez sauvegarder les fichiers suivants :
- Fichier AMConfig.properties
AccessManagerConfig-base/config/AMConfig.properties- Fichier serverconfig.xml
AccessManagerConfig-base/config/serverconfig.xml- Fichiers de configuration du conteneur Web :
- Pour Application Server : les fichiers server.policy et server.xml installés dans
WebServer-base/https-nom_hôte/config- Pour Application Server : les fichiers server.policy et domain.xml installés dans
AppServer7Config-base/domain/domain1/config- Pour les conteneurs Web tiers : les fichiers de configuration appropriés.
- Fichiers JAR pour l’authentification et les modules personnalisés.
Sauvegarder les fichiers personnalisés du conteneur Web
Si vous disposez de fichiers personnalisés de conteneur Web auxquels Access Manager fait référence, vous pouvez les sauvegarder. Ces personnalisations peuvent inclure les éléments suivants :
Sauvegarder les fichiers de débogage et journaux d’Access Manager pour la version 3
À des fins d’analyse des informations sur l’état du système, il est conseillé de sauvegarder les fichiers de débogage et les fichiers journaux. Ces fichiers se trouvent aux emplacements suivants :
Obtenir les mots de passe et informations de configuration requis
Pour mettre à niveau Access Manager, vous devez fournir des informations de configuration particulières, notamment :
Mise à niveau de la version 3 Access Manager
La mise à niveau du logiciel Access Manager vers Java ES version 4 inclut les procédures de reconfiguration d’Access Manager et de migration de ses données.
Résumé de la mise à niveau
La procédure de mise à niveau d’Access Manager se compose des étapes suivantes :
- Supprimez la version d’Access Manager pour Java ES version 3. Utilisez le script ampre70upgrade.
- Installez la version d’Access Manager pour Java ES version 4. Utilisez le programme d’installation Java ES version 4 avec l’option Configurer ultérieurement.
- Annulez le déploiement d’Access Manager, reconfigurez-le et redéployez-le dans un conteneur Web. Utilisez le script amconfig.
- Mettez à jour la structure et le schéma d’annuaire. Utilisez le script amupgrade.
Toutes ces étapes sont détaillées dans les procédures ci-après.
Procédures de mise à niveau
- Supprimez la version d’Access Manager pour Java ES version 3.
- Connectez-vous en tant qu’utilisateur root sur l’ordinateur qui héberge Access Manager pour la version 3 ou devenez superutilisateur.
su -
- Modifiez le répertoire en répertoire plate-forme/Product/identity_svr/Tools dans la distribution Java ES version 4.
- Récupérez les valeurs des paramètres suivants requis par le script ampre70upgrade :
Tableau 11-4 Paramètres de configuration d’Access Manager : ampre70upgrade
Paramètre
Valeur
Hôte de Directory Server
Définissez le nom complet : nom_hôte.domaine
Port de Directory Server
Indiquez un numéro de port non SSL1
Par défaut : 389Nom distinctif de l’administrateur de niveau supérieur
Par défaut : uid=amadmin,ou=People,dc=iplanet,dc=com
Mot de passe de l’administrateur de niveau supérieur
1Le processus précédant la mise à niveau ne s’effectue pas correctement si vous indiquez un port SSL Directory Server, tel que la valeur SSL par défaut 636.
- Assurez-vous que Directory Server est en cours d’exécution, sinon démarrez-le.
- Exécutez le script ampre70upgrade.
./ampre70upgrade
Le script sauvegarde les fichiers de configuration d’Access Manager et supprime les packages de base de la version 3 (les packages localisés doivent être supprimés manuellement en exécutant l’étape f).
- Supprimez manuellement de votre ordinateur les packages localisés d’Access Manager.
Le script ampre70upgrade ne supprime pas les packages localisés d’Access Manager. Ils doivent être supprimés manuellement pour effectuer une mise à niveau localisée correctement.
- Installez la version d’Access Manager pour Java ES version 4.
- Exécutez le programme d’installation Java ES sur l’ordinateur qui héberge Access Manager pour la version 3.
- Sélectionnez Access Manager dans le panneau de sélection.
Si le message « Conflit » apparaît à l’écran, cela signifie que le programme d’installation a trouvé les informations de configuration d’Access Manager de la version précédente, ce qui est attendu. La reconfiguration sera effectuée comme décrit ci-dessous. Vous pouvez donc ignorer ce message et continuer.
- Spécifiez le même répertoire d’installation que celui dans lequel la version 3 est installée.
- Sélectionnez l’option Configurer ultérieurement.
- Lorsque l’installation est terminée, quittez le programme d’installation de Java ES.
- Mettez à niveau le logiciel d’accès mobile.
Le logiciel d’accès mobile d’Access Manager doit être mis à niveau par l’ajout d’un patch pour la version 3. Le tableau suivant répertorie les patchs nécessaires :
Tableau 11-5 Patchs1 de mise à niveau de du logiciel d’accès mobile d’Access Manager
Description
ID patch Solaris
ID patch Linux
Logiciel d’accès mobile
119530-01 (SPARC)
119531-01 (x86)
119532-01
1Les numéros de révision des patchs sont les numéros minimum requis pour la mise à niveau vers Java ES version 4. S’il existe des versions plus récentes, utilisez-les à la place de celles indiquées dans ce tableau.
- Notez les numéros des patchs requis à l’aide du Tableau 11-5.
Vous pouvez télécharger les patchs dans /tmp à partir de l’adresse : http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Connectez-vous en tant qu’utilisateur root ou superutilisateur.
su -
- Appliquez les patchs répertoriés dans le Tableau 11-5.
Sous Solaris :
patchadd ID_patch
Sous Linux :
rpm -Fvh sun-identity-mobileaccess-6.2-25.i386.rpm
rpm -Fvh sun-identity-mobileaccess-config-6.2-25.i386.rpm- Personnalisez de nouveau les JSP d’Access Manager.
Appliquez de nouveau la personnalisation de la version 3 aux pages JSP de la console Access Manager et de l’interface d’authentification que vous avez enregistrées dans la section Sauvegarder les fichiers personnalisés du conteneur Web.
Copiez ensuite les fichiers JSP personnalisés dans les répertoires appropriés. Par exemple, sur les systèmes Solaris :
- Console : AccessManager-base/web-src/applications/console
- Interface d’authentification : AccessManager-base/web-src/services/config/auth/default ou AccessManager-base/web-src/services/config/auth/default_langue (où langue est un indicateur d’environnement linguistique tel que ja).
Pour plus d’informations, reportez-vous au manuel Sun Java System Access Manager Developer’s Guide (http://docs.sun.com/doc/819-2139).
- Annulez le déploiement d’Access Manager, reconfigurez-le et redéployez-le dans un conteneur Web.
Exécutez le script amconfig pour configurer Access Manager pour votre conteneur Web. Le script amconfig et le fichier d’entrée modèle amsamplesilent se trouvent dans le répertoire suivant :
AccessManager-base/lib
Pour plus d’informations sur le script amconfig et le fichier modèle amsamplesilent, reportez-vous au manuel Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647).
Procédez comme suit pour reconfigurer Access Manager et le redéployer sur le conteneur Web :
- Si vous décidez de mettre à jour le logiciel du conteneur Web, comme décrit dans la section Mettre à niveau les composants présentant des dépendances par rapport à Access Manager, assurez-vous que la mise à niveau est complète.
- Vérifiez que Directory Server et le conteneur Web approprié sont en cours d’exécution.
- Créez un fichier d’entrée amconfig à partir du fichier d’entrée modèle amsamplesilent :
cp amsamplesilent fichier-config
- Définissez les paramètres de configuration dans fichier-config.
Ils doivent tous être définis correctement. Certaines valeurs peuvent être migrées du fichier AMConfig.properties et d’autres sont plus spécifiques à la procédure de mise à niveau, comme indiqué dans le tableau ci-dessous.
Pour les autres paramètres, reprenez les mêmes valeurs que celles utilisées dans la configuration de la version 3 que vous mettez à niveau, sauf si vous changez de conteneur Web ou de mots de passe.
- Exécutez amconfig pour annuler le déploiement d’Access Manager.
Paramétrez la valeur de DEPLOY_LEVEL dans fichier-config sur 26.
cd /AccessManager-base/bin
./amconfig -s AccessManager-base/bin/fichier-config- Exécutez amconfig pour reconfigurer Access Manager et le déployer dans le conteneur Web.
Paramétrez la valeur de DEPLOY_LEVEL dans fichier-config sur 1.
cd /AccessManager-base/bin
./amconfig -s AccessManager-base/bin/fichier-config- Mettez à jour la structure et le schéma d’annuaire.
Access Manager pour la version 4 coexiste avec la structure d’annuaire de la version 3, mais cette structure doit être modifiée pour prendre en charge les fonctionnalités de la version 4. Mettez à jour la structure et le schéma d’annuaire d’Access Manager vers la version 4 en exécutant le script amupgrade qui se trouve dans le répertoire suivant :
- Solaris :
AccessManager-base/upgrade/scripts- Linux :
AccessManager_base/identity/upgrade/scripts- Récupérez les valeurs des paramètres suivants requis par le script amupgrade :
Tableau 11-7 Paramètres de configuration d’Access Manager : amupgrade
Paramètre
Valeur
Hôte de Directory Server
Définissez le nom complet : nom_hôte.domaine
Port de Directory Server
Indiquez un numéro de port non SSL1
Par défaut : 389DN du gestionnaire d’annuaires
Par défaut : cn=Gestionnaire d’annuaires
Mot de passe du gestionnaire d’annuaires
Nom distinctif de l’administrateur supérieur
Par défaut : uid=amadmin,ou=People,dc=iplanet,dc=com
Mot de passe de l’administrateur de niveau supérieur :
Activer mode domaine
O/N : Oui signifie que le mode domaine est activé et que les données de services sont migrées vers la nouvelle arborescence Domaine. Non (valeur par défaut) signifie que les données des services restent en mode hérité.
1Le processus de mise à niveau ne s’effectue pas correctement si vous indiquez un port SSL Directory Server tel que la valeur SSL par défaut 636.
- Exécutez le script amupgrade.
cd AccessManager-base/upgrade/scripts
./amupgradeSi la mise à niveau est réussie, le script affiche « Upgrade completed ».
- Vérifiez les informations d’extension du schéma d’annuaire dans le fichier journal de mise à niveau suivant :
Solaris :
/var/sadm/install/logs/
Sun_Java_System_Access_Manager_upgrade_dit_log.mmddhhmmLinux :
/var/log/Sun_Java_System_Access_Manager_upgrade_dit_log.mmddhhmm- Démarrez Access Manager.
Redémarrez le conteneur Web sur lequel Access Manager est déployé.
Vérification de la mise à niveau d’Access Manager
Une fois la mise à niveau terminée, vérifiez qu’elle a été correctement effectuée, comme suit :
- Accédez à la console Access Manager avec le nom amadmin à l’aide de l’URL suivant :
http://nom_hôte.domaine:port/amconsole
où nom_hôte.domaine:port est le nom d’hôte complet et le numéro de port du conteneur Web hébergeant Access Manager.
Vérifiez que les nouveaux services de la version 4 référencés dans la section À propos d’Access Manager pour Java ES version 4 sont accessibles dans l’onglet Configuration des services.
- Vérifiez l’état de la mise à niveau en consultant les fichiers journaux de mise à niveau suivants dans le répertoire /var/sadm/install/logs :
Sun Programme d’installation de Java Enterprise System :
- Vérifiez les fichiers de dépannage d’Access Manager pour déceler toute erreur.
Ces fichiers se trouvent dans /var/opt/SUNWam/debug.
Tâches à exécuter après la mise à niveau
Si vous utilisez le service SAML (Security Assertion Markup Language), vous devez ajouter et activer le module d’authentification SAML à l’aide de la console Access Manager. Pour plus d’informations sur la création d’une instance de module d’authentification SAML, reportez-vous au manuel Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647).
Annulation de la mise à niveau
Aucun script n’est fourni pour la restauration d’Access Manager à son état antérieur à la mise à niveau. Ce processus doit être réalisé manuellement à l’aide des données d’Access Manager qui ont été sauvegardées au cours des tâches antérieures à la mise à niveau (voir la section Sauvegarder les fichiers de débogage et journaux d’Access Manager pour la version 3). L’annulation est trop difficile pour être pratique.
Mise à niveau de plusieurs instances : Coexistence de la version 3 et de la version 4
Dans certaines architectures, Access Manager est déployé sur plusieurs systèmes afin de permettre l’évolutivité et une haute disponibilité. Les instances d’Access Manager accèdent au même serveur Directory Server. Il est souvent souhaitable de mettre à niveau les instances d’Access Manager les unes après les autres afin de ne pas interrompre le service. Cette section traite de la procédure d’exécution des mises à niveau progressives.
La procédure de mise à niveau d’Access Manager pour la version 3 inclut une étape de migration du schéma d’annuaire pour la prise en charge de la version 4. Access Manager pour la version 3 ne prend pas en charge le schéma d’annuaire de la version 4, toutefois Access Manager pour la version 4 prend en charge le schéma d’annuaire de la version 3.
Les instances d’Access Manager pour Java ES version 4 et version 3 peuvent coexister et être exécutées simultanément sur le même serveur Directory Server uniquement si vous n’avez pas encore migré le schéma d’annuaire vers la version 4. Lors de mises à niveau progressives, le schéma d’annuaire ne doit pas être migré vers la version 4 tant que toutes les instances d’Access Manager ne sont pas mises à niveau vers la version 4.
Pour la réalisation de mises à niveau progressives, mettez à niveau chaque instance d’Access Manager comme décrit dans la section Mise à niveau de la version 3 Access Manager, excepté pour l’étape Mettez à jour la structure et le schéma d’annuaire. à la (more...) . Une fois toutes les instances mises à niveau, vous pouvez effectuer cette étape.
Mise à niveau uniquement du kit SDK d’Access Manager pour la version 3
Dans certaines architectures de déploiement, le composant SDK d’Access Manager est installé sur un ou plusieurs ordinateurs sans que d’autres composants d’Access Manager soient installés sur ces ordinateurs. Le kit SDK d’Access Manager sert d’interface distance vers Access Manager et doit être reconfiguré dans le même mode de fonctionnement qu’Access Manager : hérité ou domaine. En tant qu’interface distante vers Access Manager, il est inutile de configurer le kit SDK pour accéder à Directory Server.
Si le kit SDK d’Access Manager sert à prendre en charge un composant Web (tel que Portal Server ou Communications Express) qui dépend des services de conteneur Web, il doit être configuré pour le conteneur Web correspondant. En revanche, le kit SDK d’Access Manager peut aussi prendre en charge des composants non Web, auquel cas aucun conteneur Web n’est nécessaire.
La procédure de mise à niveau du kit SDK d’Access Manager représente une partie de la procédure de la mise à niveau complète d’Access Manager, en fonction des caractéristiques ci-dessus.
Cette section explique comment effectuer la mise à niveau d’un kit SDK d’Access Manager de Java ES version 3 vers Java ES version 4 :
Tâches à exécuter avant la mise à niveau
Les tâches antérieures à la mise à niveau du kit SDK d’Access Manager sont identiques à celles antérieures à la mise à niveau complète d’Access Manager, mais excluent les étapes de personnalisation des outils d’administration et de Directory Server. Les tâches à exécuter avant la mise à niveau du kit SDK d’Access Manager sont les suivantes :
Mise à niveau du kit SDK d’Access Manager pour la version 3
Les procédures de mise à niveau du kit SDK d’Access Manager sont identiques à celles de la mise à niveau complète d’Access Manager, mais excluent les étapes de personnalisation des outils d’administration et de migration du schéma d’annuaire.
- Supprimez la version du SDK d’Access Manager correspondant à Java ES version 3.
Suivez les instructions décrites dans la section Supprimez la version d’Access Manager pour Java ES version 3., mais ne supprimez que le kit SDK d’Access Manager.
- Installez la version du SDK d’Access Manager correspondant à Java ES version 4.
Suivez les instructions décrites dans la section Installez la version d’Access Manager pour Java ES version 4., mais n’installez que le kit SDK d’Access Manager.
- Reconfigurez le kit SDK d’Access Manager.
Suivez les instructions décrites dans la section Annulez le déploiement d’Access Manager, reconfigurez-le et redéployez-le dans un conteneur Web., mais définissez DIRECTORY_MODE=5 et le paramètre DEPLOY_LEVEL comme suit :
Vérification de la mise à niveau du kit SDK d’Access Manager
Il existe trois méthodes pour savoir si la mise à niveau du kit SDK d’Access Manager est réussie :
- Exécutez Portal Server, Communications Express ou tout autre composant utilisant le kit SDK d’Access Manager comme interface avec Access Manager, et vérifiez que l’authentification fonctionne.
- Exécutez les exemples du kit SDK d’Access Manager qui se trouvent à l’emplacement suivant :
/AccessManager-base/samples/sdk
- Vérifiez la valeur de la propriété com.iplanet.am.version qui se trouve dans le fichier AMConfig.properties :
AccessManagerConfig-base/config/AMConfig.properties
Annulation de la mise à niveau
Aucun script n’est fourni pour la restauration d’Access Manager à son état antérieur à la mise à niveau. Ce processus doit être réalisé manuellement à l’aide des données d’Access Manager qui ont été sauvegardées au cours des tâches antérieures à la mise à niveau (voir la section Sauvegarder les fichiers de débogage et journaux d’Access Manager pour la version 3). L’annulation est trop difficile pour être pratique.
Mise à niveau d’Access Manager à partir de Java ES version 2La procédure de mise à niveau d’Access Manager pour Java ES 2004Q2 (version 2) vers la version 4 est identique à celle de mise à niveau d’Access Manager pour la version 3 vers la version 4, avec quelques exceptions détaillées ci-dessous.
Tâches à exécuter avant la mise à niveau
Avant de mettre à niveau Access Manager, effectuez les étapes décrites dans la section Tâches à exécuter avant la mise à niveau, mais remplacez la section Mettre à niveau les composants présentant des dépendances par rapport à Access Manager par la section suivante et ajoutez la section Mise à niveau du schéma d’annuaire ci-après.
Mise à niveau des composants présentant des dépendances par rapport à Access Manager
Comparées à la mise à niveau à partir de la version 3, les tâches à exécuter avant la mise à niveau de la version 2 vers la version 4 doivent comprendre la mise à niveau vers la version 4 de tous les composants partagés (voir le Tableau 1-6) et de tous les composants locaux dont dépend Access Manager.
La mise à niveau des composants dépendant d’Access Manager doit être effectuée dans l’ordre suivant, avant la mise à niveau d’Access Manager. Vous pouvez ignorer tout composant déjà mis à niveau.
- Composants partagés. Les instructions de mise à niveau des composants partagés Java ES vers la version 4 sont présentées dans le Chapitre 2, « Mise à niveau des composants partagés Java ES ».
- Directory Server. Directory Server se trouve rarement sur le même ordinateur que Access Manager. Vous trouverez tout de même les instructions de mise à niveau de Directory Server vers la version 4 dans le Mise à niveau de Directory Server et d’Administration Server à partir de Java ES version 2.
- Logiciels de conteneur Web. Les instructions de mise à niveau de Web Server ou d’Application Server sont présentées respectivement dans le Mise à niveau de Web Server à partir de Java ESversion 2 et le Mise à niveau d’Application Server à partir de Java ES version 2.
Mise à niveau du schéma d’annuaire
Si Directory Server a été configuré à l’aide de Directory Preparation Tool (comm_dssetup.pl) pour prendre en charge Messaging Server, Calendar Server ou tout autre composant de communication, vous devez tout d’abord mettre à niveau le schéma d’annuaire à l’aide de la version de Directory Preparation Tool pour la version 4 avant de mettre à niveau Access Manager. Effectuez cette tâche antérieure à la mise à niveau une fois que vous avez mis à niveau les composants dépendant d’Access Manager. La procédure de mise à niveau de Directory Preparation Tool est décrite dans la section Mise à niveau de Directory Preparation Tool à partir de Java ES version 2.
Mise à niveau d’Access Manager pour la version 2
La procédure de mise à niveau d’Access Manager à partir de la version 2 vers la version 4 dépend du conteneur Web dans lequel vous déployez le logiciel Access Manager.
Mise à niveau d’Access Manager pour la version 2 : conteneur Web Web Server
Pour mettre à niveau Access Manager pour la version 2 vers la version 4, lors d’un déploiement dans un conteneur Web Server, suivez les instructions décrites dans la section Mise à niveau de la version 3 Access Manager, en remplaçant chaque occurrence de version 3 par version 2.
Mise à niveau d’Access Manager pour la version 2 : conteneur Web Application Server
Pour mettre à niveau Access Manager pour la version 2 vers la version 4, lors du déploiement dans un conteneur Web Application Server, il existe deux cas possibles :
- Application Server pour la version 4 vient d’être installé. Dans ce cas, pour mettre à niveau Access Manager pour la version 2 vers la version 4, suivez les instructions décrites dans la section Mise à niveau de la version 3 Access Manager, en remplaçant chaque occurrence de version 3 par version 2.
- Application Server pour la version 2 a été mis à niveau vers la version 4. Dans ce cas, pour mettre à niveau Access Manager pour la version 2 vers la version 4, suivez les instructions ci-dessous.
Pour mettre à niveau Access Manager lorsqu’il est déployé dans un conteneur Web Application Server mis à niveau, effectuez l’étape 1 à l’étape 4, en remplaçant chaque occurrence de version 3 par version 2.
Pour résumer, les étape 1 à étape 4 sont les suivantes :
- Supprimez la version d’Access Manager correspondant à la version 2.
Utilisez le script ampre70upgrade. Suivez les instructions de la section Supprimez la version d’Access Manager pour Java ES version 3..
- Installez la version d’Access Manager pour Java ES version 4. Utilisez le programme d’installation Java ES version 4 avec l’option Configurer ultérieurement.
L’instance d’Application Server pour la version 2 dans laquelle Access Manager a été initialement déployé (nomInstance), lors de sa mise à niveau vers la version 4, a été migrée sous un agent du nud créé par le processus de mise à niveau. La mise à niveau d’Access Manager dans cette instance mise à niveau d’Application Server demande l’exécution des étapes supplémentaires suivantes :
- Assurez-vous que les composants suivants qui prennent en charge Access Manager sont en cours d’exécution.
- Assurez-vous que Directory Server est actif.
- Démarrez le serveur d’administration de domaine si ce n’est déjà fait.
AppServer8-base/bin/asadmin start-domain --user ID_admin
--password mot_de_passe nomDomaine- Démarrez l’instance mise à niveau d’Application Server sur laquelle Access Manager est déployé (nomInstance), si elle ne l’est pas.
Pour ce faire, démarrez l’agent du nud sous lequel l’instance mise à niveau d’Application Server a été migrée :
AppServer8-base/bin/asadmin start-node-agent --user ID_Admin
--password mot_de_passe NomAgentNudDans les commandes ci-dessus et dans les étapes suivantes les conventions suivantes sont utilisées :
- nomAgentNud est sous la formenomHôte_nomDomaine.
- La valeur par défaut de nomDomaine est domain1
- La valeur par défaut de nomInstance est server1
- Annulez le déploiement d’Access Manager, reconfigurez-le, puis redéployez-le sur l’instance d’Application Server. Utilisez le script amconfig.
- Créez un fichier d’entrée amconfig à partir du fichier d’entrée modèle amsamplesilent :
cp amsamplesilent fichier-config
- Définissez les paramètres de configuration dans fichier-config.
Ils doivent tous être définis correctement. Certaines valeurs peuvent être migrées du fichier AMConfig.properties et d’autres sont plus spécifiques à la procédure de mise à niveau, comme indiqué dans le tableau ci-dessous.
Pour les autres paramètres, reprenez les mêmes valeurs que celles utilisées dans la configuration de la version 2 que vous mettez à niveau, sauf si vous changez de conteneur Web ou de mots de passe.
- Exécutez amconfig pour annuler le déploiement d’Access Manager.
Paramétrez la valeur de DEPLOY_LEVEL dans fichier-config sur 26.
cd /AccessManager-base/bin
./amconfig -s AccessManager-base/bin/fichier-config- Exécutez amconfig pour reconfigurer Access Manager et le déployer dans le conteneur Web.
Paramétrez la valeur de DEPLOY_LEVEL dans fichier-config sur 1.
cd /AccessManager-base/bin
./amconfig -s AccessManager-base/bin/fichier-config- Copiez le fichier server.policy à partir du répertoire suivant :
AppServer8Config-base/domains/nomDomaine/config
dans le répertoire suivant :
AppServer8Config-base/nodeagents/nomAgentNud/
nomInstance/config- Modifiez le fichier domain.xml d’Application Server pour la version 4.
- Copiez les informations de classpath-suffix et server-classpath d’Access Manager dans le fichier server.xml de l’instance Application Server pour la version 2 sur laquelle Access Manager a été initialement déployé :
AppServer7Config-base/domains/nomDomaine/nomInstance/config/server.xml
- Ajoutez les informations classpath copiées respectivement dans les entrées classpath-suffix et server-classpath du fichier domain.xml de l’instance d’Application Server mise à niveau sur laquelle Access Manager est déployé :
AppServer8Config-base/nodeagents/nomAgentNud/nomInstance/
config/domain.xmlLes informations classpath doivent être ajoutées au bloc nomInstance-config du fichier domain.xml d’Application Server pour la version 4. Ce bloc commence par la ligne suivante :
<config dynamic-reconfiguration-enabled="true" name="nomInstance-config">
Lorsque vous ajoutez un élément à une entrée classpath, veillez à inclure deux points (« : »), ou tout séparateur de chemin utilisé dans les entrées classpath, entre les anciennes et les nouvelles informations. Vous pouvez également supprimer toutes les entrées avec le chemin AppServer7-base (attention à ne pas introduire d’erreur).
- Redémarrez le serveur d’administration de domaine :
AppServer8-base/bin/asadmin stop-domain --user ID_admin
--password mot_de_passe nomDomaineAppServer8-base/bin/asadmin start-domain --user ID_admin
--password mot_de_passe nomDomaine- Redémarrez l’instance de serveur sur laquelle Access Manager est déployé.
AppServer8-base/bin/asadmin stop-node-agent --user ID_admin
--password mot_de_passe NomAgentNudAppServer8-base/bin/asadmin start-node-agent --user ID_Admin
--password mot_de_passe NomAgentNud- Mettez à jour la structure et le schéma d’annuaire comme indiqué à l’étape 6.
Vérification de la mise à niveau d’Access Manager
Une fois la mise à niveau terminée, vérifiez qu’elle a été correctement effectuée, comme indiqué dans la section Vérification de la mise à niveau d’Access Manager.
Tâches à exécuter après la mise à niveau
Si vous utilisez le service SAML (Security Assertion Markup Language), vous devez ajouter et activer le module d’authentification SAML à l’aide de la console Access Manager. Pour plus d’informations sur la création d’une instance de module d’authentification SAML, reportez-vous au manuel Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647).
Annulation de la mise à niveau
Aucun script n’est fourni pour la restauration d’Access Manager à son état antérieur à la mise à niveau. Ce processus doit être réalisé manuellement à l’aide des données d’Access Manager qui ont été sauvegardées au cours des tâches antérieures à la mise à niveau (voir la section Sauvegarder les fichiers de débogage et journaux d’Access Manager pour la version 3). L’annulation est trop difficile pour être pratique.