Serveur et sécurité administrative

Le terme sécurité administrative fait référence à la fourniture d'authentification des utilisateurs qui se servent des fonctions d'administration de WebSphere, à l'utilisation du protocole SSL (Secure Sockets Layer) et au choix du référentiel de comptes utilisateur.

[z/OS]Lorsque vous configurez un registre d'utilisateurs de système d'exploitation local, ce dernier utilise la fonction RACF (Resource Access Control Facility) ou la base de données utilisateur compatible SAF (System Authorization Facility). La sélection d'un registre de ce type en tant que registre actif permet de tirer directement parti des fonctions SAF de z/OS en utilisant les principaux WebSphere Application Server :
  • Partage d'identités avec plusieurs autres services connecteur z/OS
  • Utilisation de la délégation SAF qui réduit la nécessité de stocker les ID utilisateur et les mots de passe à des emplacements distincts dans la configuration
  • Utilisation de fonctions d'audit supplémentaires
Ces fonctions sont disponibles avec d'autres registres, mais dans ce cas, le mappage d'identité doit être effectué en modifiant la configuration de connexion du système WebSphere Application Server et les modules de connexion JAAS (Java™ Authentication and Authorization Service). Pour plus d'informations, voir la documentation Mise à jour de configurations de connexion du système pour effectuer un mappage d'identité utilisateur SAF (System Authorization Facility).

[AIX Solaris HP-UX Linux Windows][IBM i]Dans certains cas, le domaine peut correspondre au nom d'une machine d'un registre d'utilisateurs local. Tous les serveurs d'applications doivent alors résider sur la même machine physique. Dans d'autres cas, le domaine peut correspondre au nom d'une machine d'un registre d'utilisateurs LDAP (Lightweight Directory Access Protocol). Sachant que LDAP constitue un registre réparti, il est possible d'avoir une configuration de plusieurs noeuds dans un environnement WebSphere Application Server, Network Deployment. Le principe d'un domaine sécurité présuppose que l'ID accès renvoyé par le registre d'un serveur est identique à celui retourné par le registre d'un autre serveur du même domaine. L'ID d'accès est l'identificateur unique d'un utilisateur et permet de savoir si l'accès à la ressource est autorisé.

La configuration de la sécurité administrative pour un domaine de sécurité consiste à configurer le registre d'utilisateurs commun, le mécanisme d'authentification et d'autres informations de sécurité définissant le comportement d'un domaine de sécurité. Les autres informations de sécurité configurées incluent les composants suivants :
  • gestionnaire de sécurité Java 2 ;
  • service JAAS (Java Authentication and Authorization Service) ;
  • données d'authentification J2C (Java 2 Connector) ;
  • [AIX Solaris HP-UX Linux Windows][IBM i]Protocole d'authentification CSIv2 et SAS (sécurité RMI/IIOP)
  • [z/OS]CSIv2 (Common Secure Interoperability Version 2) et le protocole d'authentification z/OS Secure Authentication Service (z/SAS) (sécurité RMI/IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol))
  • Autres attributs divers.

[AIX Solaris HP-UX Linux Windows][IBM i]Vous pouvez remplacer certaines parties de la configuration au niveau du serveur.

[AIX Solaris HP-UX Linux Windows][IBM i]Lorsque plusieurs noeuds et serveurs peuvent être mis en oeuvre dans un noeud, vous pouvez configurer certains attributs au niveau du serveur. Ces derniers incluent l'activation de la sécurité pour le serveur, l'activation du gestionnaire de sécurité Java2 et le protocole d'authentification CSIv2/SAS (sécurité RMI/IIOP). Vous pouvez désactiver la sécurité au niveau des serveurs d'applications individuels lorsque la sécurité administrative est activée. Toutefois, vous ne pouvez pas activer la sécurité au niveau d'un serveur d'applications individuel si la sécurité administrative est désactivée.

[z/OS]Lorsque plusieurs noeuds et serveurs peuvent être mis en oeuvre dans un noeud, vous pouvez configurer certains attributs au niveau du serveur. Ces derniers incluent l'activation de la sécurité pour le serveur, l'activation du gestionnaire de sécurité Java 2 et le protocole d'authentification CSIv2 et z/SAS (sécurité RMI/IIOP). Vous pouvez désactiver la sécurité au niveau des serveurs d'applications individuels lorsque la sécurité administrative est activée. Toutefois, vous ne pouvez pas activer la sécurité au niveau d'un serveur d'applications individuel si la sécurité administrative est désactivée.

Lorsque la sécurité du serveur d'applications est désactivée pour les demandes utilisateurs, la sécurité d'attribution de nom et d'administration est toujours activée pour le serveur d'applications afin que l'infrastructure d'attribution de nom et d'administration reste sécurisée. Si la sécurité de la cellule est activée, mais que la sécurité au niveau des serveurs individuels ne l'est pas, les applications Java Platform, Enterprise Edition ne sont ni authentifiées ni autorisées. En revanche, la sécurité d'attribution de nom et d'administration sont appliquées. Par conséquent, les services d'attribution de nom pouvant être appelés à partir d'applications utilisateur, accordez l'accès Tous les utilisateurs aux fonctions d'attribution de nom requises de sorte qu'elles acceptent les demandes non authentifiées. Le code utilisateur n'accède pas directement à la sécurité d'administration sauf via les outils de scriptage pris en charge.

[z/OS]Si vous utilisez l'autorisation SAF (System Authorization Facility), vous devez vous assurer que la zone UACC du profil EJBROLE de CosNamingRead a pour valeur READ et que l'ID non authentifié possède un accès READ (en lecture) à ce profil.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_globalserver
Nom du fichier : csec_globalserver.html