[z/OS]

Remarques de sécurité relatives à WebSphere Application Server forz/OS

Fonctions prises en charge dans WebSphere Application Server for z/OS

WebSphere Application Server for z/OS prend en charge les fonctions ci-dessous.

Tableau 1. Fonctions prises en charge dans WebSphere Application Server for z/OS. Le tableau ci-dessous décrit les fonctions prises en charge dans WebSphere Application Server for z/OS.
Fonction Informations supplémentaires
EJB RunAs Pour plus d'informations, voir Délégations.
Fonction RunAs pour les servlets Pour plus d'informations, voir Délégations.
Protocoles IIOP fondés sur SAF Pour plus d'informations, voir Configuration du client CSIv2 (Common Secure Interoperability Version 2) et SAS (Security Authentication Service).
Fonctions du connecteur z/OS Pour plus d'informations, voir Resource Recovery Services (RRS).
Sécurité d'administration Pour plus d'informations, voir Sécurité administrative.
Sécurité applicative Pour plus d'informations, voir Sécurité applicative.
Sécurité Java 2 Pour plus d'informations, voir Sécurité Java 2.
Désactivez la sécurité. Pour plus d'informations, voir Désactivation de la sécurité globale.
Fichiers de clés SAF Pour plus d'informations, voir Utilisation des fichiers de clés SAF (System Authorization Facility) avec Java Secure Sockets Extension.
Fonctions d'authentification Exemples de fonction d'authentification : de base, certificats numériques SSL, connexion par formulaire, contraintes de sécurité, intercepteur de relations de confiance
Ressources de sécurité J2EE Pour plus d'informations, voir Tâches en cours : Sécurisation des ressources.
Authentification Web (LTPA) Pour plus d'informations, voir Configuration du mécanisme LPTA (Lightweight Third Party Authentication).
IIOP via LTPA Pour plus d'informations, voir LTPA (Lightweight Third Party Authentication).
Liaisons d'applications WebSphere Les mappages entre un utilisateur et un rôle peuvent être fournies par les liaisons d'application WebSphere.
Synchronisation avec l'unité d'exécution du système d'exploitation Pour plus d'informations, voir Identité d'unité d'exécution Java et identité d'unité d'exécution de système d'exploitation.
Registres SAF Pour plus d'informations, voir Sélection d'un registre ou d'un référentiel.
Vérification d'identité

Pour plus d'informations, voir Vérification d'identité.

Protocoles d'authentification Exemple : z/SAS, CSIV2

Pour plus d'informations, voir Prise en charge du protocole d'authentification.

Niveau de conformité CSIv2 "0" Pour plus d'informations, voir Présentation de la planification de la sécurité.
Extensions WebSphere du modèle de programmation JAAS Pour plus d'informations, voir Utilisation du modèle de programmation JAAS (Java Authentication and Authorization Service) pour l'authentification Web.
Mappage d'identité répartie à l'aide de SAF Pour plus d'informations, voir Mappage d'identité répartie à l'aide de SAF
Tous les WebSphere Application Servers de base fournissent les fonctions suivantes :
  • Utilisation de la fonction RunAs : RunAs permet de modifier l'identité d'un appelant, serveur ou rôle. Cette désignation fait maintenant partie de la spécification du servlet.
  • Prise en charge des protocoles d'authentification IIOP basés sur SAF : WebSphere Application Server, Network Deployment uutilise le mécanisme d'authentification SAS (Secure Authentication Service) pour (Internet Inter-ORB Protocol). z/OS possède sa propre version de SAS appelée z/SAS (z/OS Secure Authentication Services) qui est dotée de fonctions similaires mais utilise des mécanismes différents. Il traite des fonctions telles que la sécurité locale, l'autorisation via SSL (Secure Sockets Layer), les certificats numériques avec mappage SAF (System Authorization Facility) et la vérification d'identité SAF.
    Important : z/SAS est pris en charge uniquement sur les serveurs version 6.0.x et versions antérieures qui ont été fédérés dans une cellule version 6.1.
  • Autorisation fondée sur SAF et fonctionnalité RunAs : Utilisez les profils SAF (EJBROLE) pour les informations de sécurité relatives aux droits d'accès et à la délégation.
  • Prise en charge des fonctions de connecteur z/OS : Au lieu d'utiliser un alias dans lequel sont stockés un ID utilisateur et un mot de passe, la capacité de propager les identités de système d'exploitation local est prise en charge.
  • Prise en charge du fichier de clés SAF pour HTTP et IIOP : Utilisez SystemSSL pour prendre en charge le fichier de clés HTTP, IIOP et SAF. JSSE peut également être utilisé.
  • Fonctions d'authentification : Les mécanismes d'authentification Web, tels que l'authentification de base, les certificats numériques SSL, la connexion par formulaire, les contraintes de sécurité et l'intercepteur des relations de confiance offrent la même fonctionnalité dans la Version 9.0 que dans la version 5.
  • Autorisation pour les ressources J2EE : Le mécanisme d'autorisation des ressources J2EE (Java 2 Platform, Enterprise Edition) emploie des rôles similaires à ceux utilisés dans la version 4, ces derniers étant utilisés comme descripteurs.
  • Activation de la sécurité : La sécurité peut être activée ou désactivée de manière globale. Lorsque le serveur démarre, un certain niveau de sécurité est défini, mais la sécurité est désactivée tant que l'administrateur ne l'a pas activée.
  • Authentification Web via LTPA et SWAM : La connexion unique (SSO) via LTPA (Lightweight Third Party Authentication) ou le mécanisme SWAM (Simple WebSphere Authentication Mechanism) est pris en charge.
    Remarque : SWAM est obsolète dans WebSphere Application Server Version 9.0 et sera supprimée dans la prochaine version.
  • Authentification IIOP via LTPA : L'authentification IIOP via LTPA est prise en charge.
  • Liaisons d'application WebSphere pour l'autorisation : Les liaisons d'application WebSphere pour l'autorisation sont maintenant prises en charge.
  • Synchronisation avec l'unité d'exécution du système d'exploitation : La synchronisation de l'application avec l'unité d'exécution du système d'exploitation est prise en charge.
  • Sécurité de l'attribution de nom fondée sur un rôle J2EE : Les rôles J2EE permettent également de protéger l'accès à l'espace de nom. Les nouveaux rôles et tâches sont cosNamingRead, cosNamingWrite, cosNamingCreate et cosNamingDelete.
  • Sécurité administrative fondée sur le rôle : Les rôles qui délimitent la sécurité sont les suivants :
    • Moniteur (autorisation de niveau le moins élevé, en lecture seule)
    • Opérateur (pouvant effectuer des modifications d'exécution)
    • Configurateur (droits de moniteur et privilèges de configuration)
    • Administrateur (niveau d'autorisation le plus élevé)
    • Déployeur (utilisé par l'outil wsadmin pour les actions de configuration et les opérations d'exécution sur les applications)
    • Adminsecuritymanager (peut affecter des rôles d'administration aux utilisateurs et gérer des groupes d'autorisation)

    Pour plus d'informations sur les rôles d'administration, voir Rôles d'administration.

Comparaison de WebSphere Application Server for z/OS aux autres plateformes WebSphere Application Server

Une similitude clé :
  • Modèle de sécurité tiers : Le modèle de sécurité tiers peut être authentifié dans CSIv2 (Common Secure Interoperability Version 2) IIOP, l'authentification sécurisée Web, les connecteurs JMX (Java Management Extensions) ou le modèle de programmation JAAS (Java Authentication and Authorization Service). Vous devez :
    1. identifier le registre approprié et les mécanismes d'authentification (jeton) nécessaires ;
    2. déterminer si le registre est local ou éloigné et identifier les mécanismes d'autorisation Web à utiliser : les mécanismes d'autorisation Web incluent SWAM (Simple WebSphere Authentication Mechanism) et LTPA (Lightweight Third-Party Authentication)
      Remarque : La fonction SWAM est encore utilisée dans WebSphere Application Server Version 9.0 mais sera supprimée dans une future édition.
Les différences principales sont décrites ci-dessous.
  • Registres SAF : Les registres de système d'exploitation local fournissent des fonctionnalités de qualité supérieure sous z/OS car ce système s'étend sur un sysplex et non sur un serveur unique. z/OS fournit des fonctions de mappage entre un certificat et un utilisateur, d'autorisation et de délégation.
  • Vérification d'identité : Utilisez des serveurs sécurisés ou CBIND pour obtenir l'autorisation nécessaire au serveur chargé de la vérification. Sur une plateforme distribuée, un serveur doit être défini dans la liste des serveurs sécurisés. z/OS requiert un ID de serveur pour obtenir une autorisation CBIND spécifique. Les types de vérification sont ID utilisateur SAF, nom distinctif et certificat client SSL.
  • Protocoles d'authentification zSAS et SAS pour clients IIOP : z/SAS se différencie de SAS en prenant en charge les PassTickets RACF. Dans un environnement WebSphere distribué, la couche SAS utilise les intercepteurs portables CORBA (Common Object Request Broker Architecture) pour implémenter le service SAS (Secure Association Service) associé, contrairement à z/OS.
  • Fonctions CORBA : z/OS ne prend pas en charge les interfaces de sécurité CORBA, parmi lesquelles les modèles CORBA, LoginHelper, Credentials et ServerSideAuthenticator. Les fonctions CORBA ont été migrées vers JAAS.

    L'interface API (application programming interface) LoginHelp est obsolète dans WebSphere Application Server Version 9.0. Pour plus d'informations, voir Migration d'une connexion par programmation CORBA (Common Object Request Broker Architecture) vers JAAS (Java Authentication and Authorization Service).

  • Protocoles d'authentification : CSIv2 est une spécification OMG (Object Management Group) pour le serveur de sécurité z/OS. Elle est activée automatiquement lorsque la sécurité WebSphere elle-même est activée. Cette approche, composée de trois niveaux, met en oeuvre la sécurité SSL/TLS (Secure Sockets Layer Transport Layer Security) pour la protection des messages, la couche d'authentification client supplémentaire pour l'ID utilisateur et le mot de passe GSSUP (Generic Security Services Username Password) et la couche des attributs de sécurité utilisée par les serveurs intermédiaires (qui doivent être spécialement autorisés à accéder au serveur cible) pour la vérification d'identité.

Conformité à la spécification J2EE 1.3

Les conditions ci-dessous doivent être remplies.
  • Niveau de conformité CSIv2 "0" : Il s'agit d'une spécification OMG (Object Management Group), liée au serveur de sécurité z/OS, qui fait partie de la prise en charge CORBA. CSIv2 est activé automatiquement lorsque la sécurité est activée.
  • Utilisation de la sécurité Java 2 : Il existe deux options, "configurée pour la sécurité"et "configurée pour la sécurité Java 2",et par défaut, cette dernière est activée ("on"). Cela fournit un contrôle d'accès à granularité fine fondée sur le code, par opposition à l'autorisation fondée sur le sujet. Chaque classe appartient à un domaine particulier. Les droits d'accès protégés par la sécurité Java 2 incluent l'accès aux fichiers, l'accès au réseau, les sockets, la sortie de la machine virtuelle Java (JVM), l'administration des propriétés et les unités d'exécution. Le gestionnaire de sécurité est le mécanisme utilisé par Java 2 pour gérer la sécurité et mettre en oeuvre les protections requises. Les extensions de la sécurité Java 2 incluent l'utilisation de la règle dynamique (droits d'accès fondés sur le type de ressource plutôt que sur le code), des droits d'accès par défaut spécifiques définis pour les ressources dans les profils modèle et des fichiers de filtre pour désactiver la règle.
  • Utilisation de la programmation JAAS : La programmation JAAS inclut un ensemble standard d'interfaces API pour l'authentification. JAAS est le mécanisme d'autorisation et d'authentification stratégique. IBM® Developer Kit for Java Technology Edition, version 5 est livré avec WebSphere Version Version 9.0, mais certaines extensions sont fournies.
  • Utilisation de la fonction RunAs du servlet : WebSphere Application Server sur les plateformes réparties (et non pas la platefore z/OS) fait référence à cette fonction comme Règle de délégation. Vous pouvez modifier l'identité devant s'exécuter en tant que système, appelant ou rôle (utilisateur). Cette fonction fait maintenant partie de la spécification de servlet. L'authentification comprend l'utilisation d'un ID utilisateur et d'un mot de passe et le mappage de l'alias vers le fichier XML ou le profil EJBROLE approprié afin de rechercher l'ID utilisateur du rôle RunAs.

Compatibilité avec WebSphere Application Server, Network Deployment au niveau API/SPI

La conformité à WebSphere Application Server, Network Deployment au niveau de l'interface de programme d'application (API) ou de l'interface de programmation de fournisseur de service (SPI) facilite le déploiement des applications à partir de WebSphere Application Server, Network Deployment sous z/OS. Les fonctions améliorées ou obsolètes dans WebSphere Application Server, Network Deployment sont améliorées ou obsolètes dans z/OS. Cela ne signifie pas qu'il n'existe pas de migration pour les clients z/OS. La conformité à WebSphere WebSphere Application Server, Network Deployment au niveau de l'interface API/SPI inclut :
  • extensions WebSphere Application Server vers le modèle de programmation JAAS : Le modèle d'autorisation est une extension du modèle de sécurité Java 2 pour la programmation JAAS (qui fonctionne donc avec le modèle J2EE). L'autorisation fondée sur le sujet s'effectue à partir d'ID utilisateur authentifiés. Au lieu d'une simple connexion par le biais d'un ID utilisateur et d'un mot de passe, il existe maintenant un processus de connexion qui inclut la création d'un contexte de connexion, la transmission de gestionnaires de rappels pour la spécification de l'ID utilisateur et du mot de passe, et la connexion. WebSphere Application Server for z/OS fournit le module de connexion, le gestionnaire de rappels pour extraire les données nécessaires, les rappels, l'option WSSubject, getCallerSubject et getRunAsSubject.
  • Utilisation des API de sécurité WebSphere Application Server : z/OS prend en charge les API de sécurité WebSphere Application Server.
  • Utilisation des connecteurs JMX sécurisés : Les connecteurs JMX peuvent être utilisés avec les justificatifs d'ID utilisateur et de mot de passe. Les deux types de connecteur sont RMI et SOAP/HTTPS (et concernent l'administration). Le connecteur SOAP utilise les répertoires SSL JSSE. Le connecteur RMI est sujet aux mêmes avantages et restrictions que les mécanismes IIOP (tels que CSIv2).

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_oversecure
Nom du fichier : csec_oversecure.html