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

Nouveautés de cette version

La liste des nouvelles fonctionnalités des différentes versions de patch d'Access Manager sont disponibles dans les Versions de patchs Access Manager 7 2005Q4. La version initiale d'Access Manager 7 2005Q4 intégrait les nouvelles fonctionnalités suivantes :

Modes d'Access Manager

Access Manager 7 2005Q4 propose les modes Domaine et Hérité. Ces deux modes prennent en charge :

les nouvelles fonctionnalités d'Access Manager 7 2005Q4 ;
les fonctions d'Access Manager 6 2005Q1, à l'exception des points suivants :
- Lors de la création de domaines, les organisations correspondantes ne sont pas créées dans Sun Java System Directory Server.
- La nouvelle console Access Manager 7 2005Q4 ne peut pas définir la priorité d'un modèle de classe de service. Voir le bogue La nouvelle console Access Manager ne permet pas de définir les priorités du modèle CoS (6309262).
les référentiels d'identité dans Sun Java System Directory Server et d'autres magasins de données.

Le mode hérité est requis pour :

Sun Java System Portal Server ;
les serveurs Sun Java System Communications Services, notamment Messaging Server, Calendar Server, Instant Messaging ou Delegated Administrator ;
les déploiements avec coexistence lorsque Access Manager 6 2005Q1 et Access Manager 7 2005Q4 accèdent au même serveur Directory Server.

Nouvelle console Access Manager

La console Access Manager a été repensée de manière à être adaptée à cette version. Cependant, si Access Manager est déployé avec Portal Server, Messaging Server, Calendar Server, Instant Messaging ou Delegated Administrator, vous devez installer Access Manager en mode hérité et utiliser la console Access Manager 6 2005Q1 :

Pour de plus amples informations, reportez-vous à la section Problèmes de compatibilité.

Référentiel d'identité

Les référentiels d'identité d'Access Manager contiennent des informations pertinentes sur les identités, notamment celles des utilisateurs, des groupes et des rôles. Vous pouvez créer et mettre à jour un référentiel d'identité via Access Manager ou un autre produit de provisioning, tel que Sun Java System Identity Manager.

Dans la version actuelle, un référentiel d'identité peut résider dans Sun Java System Directory Server ou dans Microsoft Active Directory. Access Manager peut accéder à un référentiel d'identité en mode lecture/écriture ou en mode lecture seule.

Arborescence d'informations d'Access Manager

L'arborescence d'informations d'Access Manager contient des informations pertinentes en termes d'accès au système. Chaque instance d'Access Manager crée et met à jour une arborescence distincte dans Sun Java System Directory Server. Vous pouvez lui attribuer n'importe quel nom (suffixe). Elle est constituée de domaines (et de sous-domaines, si nécessaire), comme décrit dans la section suivante.

Domaines d'Access Manager

Les domaines, et sous-domaines le cas échéant, sont des éléments de l'arborescence d'informations d'Access Manager. Ils peuvent contenir des informations de configuration qui définissent un ensemble d'utilisateurs et/ou de groupes, le type d'authentification des utilisateurs, les ressources auxquelles les utilisateurs peuvent accéder et les informations disponibles pour les applications, une fois les utilisateurs autorisés à accéder aux ressources. Les domaines et sous-domaines peuvent également contenir d'autres informations de configuration, notamment sur la configuration de globalisation, la configuration de la réinitialisation de mot de passe, la configuration de session, la configuration de console et les préférences utilisateur. Un domaine ou sous-domaine peut également être vide.

Vous pouvez créer un domaine à l'aide de la console Access Manager ou de l'utilitaire CLI amadmin. Pour plus d'informations, reportez-vous à l'aide en ligne de la console ou au Chapitre 14, The amadmin Command Line Tool du Sun Java System Access Manager 7 2005Q4 Administration Guide.

Modifications liées au basculement de session

Access Manager permet l'implémentation d'un basculement de session indépendant du conteneur Web en utilisant Sun Java System Message Queue (Message Queue) comme courtier de communications et Berkeley DB (de Sleepycat Software, Inc.) comme base de données de stockage des sessions. Avec Access Manager 7 2005Q4, l'une des nouveautés repose sur la prise en charge du script amsfoconfig pour configurer l'environnement de basculement de session et du script amsfo pour démarrer et arrêter le courtier Message Queue et le client Berkeley DB.

Pour obtenir plus d'informations, reportez-vous à la section Implementing Access Manager Session Failover du Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.

Notification de modification d'une propriété de session

Avec la fonction de notification de modification de propriété de session, Access Manager peut envoyer une notification à des listeners spécifiques lorsqu'une modification est apportée à une propriété de session spécifique. Cette fonction prend effet lorsque l'attribut Activer les notifications de modification de propriété est activé dans la console d'administration d'Access Manager. Par exemple, dans un environnement de connexion unique, une session Access Manager peut être partagée par plusieurs applications. Lors de la modification d'une propriété de session spécifique définie dans la liste Propriétés de notification, Access Manager envoie une notification à tous les listeners enregistrés.

Pour obtenir plus d'informations, reportez-vous à la section Enabling Session Property Change Notifications du Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.

Contraintes relatives aux quotas de session

La fonction de contraintes de quota de session permet à l'administrateur d'Access Manager (amadmin) de définir l'attribut Sessions utilisateur actives de manière à limiter le nombre de sessions utilisées simultanément par un même utilisateur. L'administrateur peut définir une contrainte de quota de session au niveau global pour tous les utilisateurs ou pour une entité, par exemple une organisation, un domaine, un rôle ou un utilisateur qui s'applique à un ou plusieurs utilisateurs spécifiques.

Par défaut, ces contraintes sont désactivées, mais l'administrateur peut les activer en paramétrant l'attribut Activer les contraintes liées aux quotas dans la console d'administration d'Access Manager.

L'administrateur peut également configurer le comportement adopté si un utilisateur épuise le quota de sessions en paramétrant l'attribut Comportement observé en cas d'épuisement du quota de sessions :

DENY_ACCESS. Access Manager rejette la demande de connexion pour une nouvelle session.
DESTROY_OLD_SESSION. Access Manager détruit la prochaine session arrivant à expiration pour l'utilisateur donné et accepte la nouvelle demande de connexion.

L'attribut Exempter les administrateurs de niveau supérieur de la vérification des contraintes détermine si les quotas s'appliquent également aux administrateurs de niveau supérieur.

Pour plus d'informations, reportez-vous à la section Setting Session Quota Constraints du Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide

Authentification distribuée

Access Manager 7 2005Q4 comprend l'interface utilisateur d'authentification distribuée, un composant d'interface utilisateur d'authentification à distance offrant une authentification distribuée et sécurisée sur deux pare-feu dans un déploiement. Sans le composant d'interface utilisateur d'authentification distribuée, les URL de service Access Manager peuvent se trouver exposées aux utilisateurs finaux. Cette exposition peut être évitée par l'utilisation d'un serveur proxy ; toutefois, un serveur proxy n'est pas nécessairement une solution acceptable pour un grand nombre de déploiements.

Le composant d'interface utilisateur d'authentification distribuée est installé sur un ou plusieurs serveurs dans la couche (DMZ) non sécurisée d'un déploiement Access Manager. Un serveur d'interface utilisateur d'authentification distribuée n'exécute pas Access Manager ; il n'existe que pour fournir l'interface d'authentification aux utilisateurs finaux par le biais d'un navigateur Web.

L'utilisateur final envoie une requête HTTP à l'interface utilisateur d'authentification distribuée, qui présente à son tour une page de connexion à l'utilisateur. Le composant d'authentification distribuée envoie ensuite la requête de l'utilisateur par le biais du second pare-feu vers un serveur Access Manager, ce qui permet d'éviter d'ouvrir des trous dans les pare-feu entre les utilisateurs finaux et le serveur Access Manager.

Pour plus d'informations, reportez-vous au manuel Technical Note: Using Access Manager Distributed Authentication .

Prise en charge de plusieurs instances du module d'authentification

Tous les modules d'authentification ont été étendus de manière à prendre en charge le sous-schéma avec l'interface utilisateur de la console. Il est possible de créer plusieurs instances de module d'authentification pour chaque type de module (classe de module chargée). Par exemple, s'il existe deux instances appelées ldap1 et ldap2 pour un type de module LDAP, chacune des instances peut désigner un serveur d'annuaire LDAP différent. Les instances dotées du même nom que leur type de module sont prises en charge à des fins de compatibilité ascendante. L'appel requis est le suivant :

server_deploy_uri/UI/Login?module=module-instance-name

Espace de noms sous forme d'enchaînement ou de configuration nommée, associé à l'authentification

Un espace de noms séparé est créé sous une organisation/un domaine, qui correspond à une chaîne d'instances de module d'authentification. La même chaîne peut être réutilisée et assignée à une organisation/un domaine, un rôle ou un utilisateur. L'instance du service d'authentification correspond à la chaîne d'authentification. L'appel requis est le suivant :

server_deploy_uri/UI/Login?service=authentication-chain-name

Améliorations du module de stratégie

Attributs de personnalisation

Outre les règles, les objets et les conditions, les stratégies disposent désormais d'attributs de personnalisation (IDResponseProvider). La décision de stratégie envoyée au client à partir de l'évaluation de stratégie comporte désormais des attributs de personnalisation de réponse basés sur la stratégie. Deux types d'attributs de personnalisation sont pris en charge :

Les attributs statiques. Vous définissez le nom et la valeur de l'attribut dans la stratégie.
Les attributs dynamiques. Vous répertoriez les noms des attributs dans les stratégies, et les valeurs sont récupérées dans les magasins de données du référentiel d'identité au moment de l'évaluation de la stratégie.

Les points d'application de stratégie (agents) transfèrent généralement ces valeurs d'attribut à l'application protégée, sous forme d'en-tête HTTP, de cookies ou d'attributs de requête.

Access Manager 7 2005Q4 ne prend pas en charge les implémentations personnalisées de l'interface du fournisseur de réponse, effectuées par les utilisateurs.

Condition de propriété de session

L'implémentation d'une condition de propriété de session (SessionPropertyCondition ) permet de déterminer si une stratégie s'applique à une requête, en fonction de la valeur des propriétés définies dans la session Access Manager d'un utilisateur. Au moment de l'évaluation de la stratégie, la condition renvoie la valeur “true” uniquement si la session Access Manager de l'utilisateur comporte toutes les valeurs de propriété définies dans la condition. Lorsque les propriétés sont définies avec plusieurs valeurs dans la condition, il suffit que la session de l'utilisateur dispose d'au moins une des valeurs répertoriées pour la propriété dans la condition.

Objet de stratégie

L'implémentation d'un objet de stratégie (objet d'identité Access Manager) vous permet d'utiliser, comme valeurs d'objet, des entrées du référentiel d'identité configuré.

Exportation de stratégie

Vous pouvez exporter des stratégies au format XML à l'aide de la commande amadmin. Cette fonction est prise en charge par les nouveaux éléments GetPolices et RealmGetPolicies du fichier amAdmin.dtd.

État de la stratégie

Les stratégies disposent désormais d'un attribut d'état, indiquant si elles sont actives ou inactives. Les stratégies inactives sont ignorées durant la phase d'évaluation de stratégie.

Configuration du site

Access Manager 7 2005Q4 introduit le concept de “site” qui implique une gestion centralisée de la configuration associée au déploiement d'Access Manager. Lorsque Access Manager est configuré en tant que site, les requêtes des clients transitent toujours par l'équilibreur de charge, ce qui simplifie le déploiement et permet de résoudre certains problèmes, notamment lors de la présence d'un pare-feu entre le client et les serveurs d'arrière-plan Access Manager.

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.

Fédération en bloc

Access Manager 7 2005Q4 propose une fonction de fédération en bloc des comptes d'utilisateur pour les applications externalisées auprès de partenaires commerciaux. Auparavant, pour fédérer des comptes entre un fournisseur de services et un fournisseur d'identités, chaque utilisateur devait accéder aux sites respectifs des deux fournisseurs, créer des comptes le cas échéant et fédérer les deux comptes via un lien Web. Ce processus prenait un certain temps et n'était pas toujours approprié, notamment lorsqu'il s'agissait d'effectuer le déploiement avec des comptes existants ou lorsque le site intervenait lui-même en tant que fournisseur d'identités ou qu'il utilisait l'un de ses partenaires comme fournisseur d'authentification.

Pour plus d'informations, reportez-vous au manuel Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide.

Améliorations en termes de journalisation

Access Manager 7 2005Q4 intègre plusieurs améliorations en termes de journalisation :

Nouveaux champs (ou colonnes) : le champ MessageID contient l'identificateur de message de l'événement consigné. Le champ ContextID contient l'identificateur de contexte, qui est semblable à un identificateur de session et qui s'applique à tous les événements de la session d'un utilisateur particulier. Dans le cadre d'une session spécifique d'un utilisateur, la valeur ContextID sera la même pour tous les événements consignés dans les fichiers journaux.
API de journalisation : l'API comporte des nouveautés relatives à la lecture des enregistrements de journal, notamment à partir d'une base de données, lorsque la fonction de journalisation dans la base de données est configurée. Reportez-vous à l'élément LogReaderSample.java du répertoire /opt/SUNWam/samples/logging, qui présente la récupération des enregistrements de journal à partir d'un fichier plat ou d'un référentiel de table de base de données.

Attention –

Les tables de base de données ont tendance à être plus volumineuses que les journaux de fichiers plats. Par conséquent, dans une requête donnée, évitez de récupérer tous les enregistrements d'une table de base de données, car une telle quantité de données risquerait d'utiliser toutes les ressources du serveur Access Manager.