Sécurité

Les informations ci-dessous présentent la sécurité dans WebSphere Application Server.

IBM® WebSphere Application Server fournit une infrastructure et des mécanismes de sécurité pour protéger les ressources Java™ 2 Platform, Enterprise Edition (J2EE) et les ressources d'administration sensibles. Cela concerne également les exigences de sécurité d'entreprise de bout en bout :
  • Authentification
  • Contrôle d'accès des ressources
  • Intégrité des données
  • Confidentialité
  • Confidentialité des données
  • Interopérabilité sécurisée
La sécurité d'IBM WebSphere Application Server repose sur les normes du secteur et comporte une architecture ouverte qui garantit une connectivité et une interopérabilité sécurisées avec les systèmes EIS (Enterprise Information Systems), y compris :
  • Database 2 (DB2)
  • CICS
  • [AIX Solaris HP-UX Linux Windows][z/OS]Information Management System (IMS)
  • MQ Series
  • Lotus Domino
  • IBM Directory
WebSphere Application Server prend également en charge d'autres fournisseurs de sécurité, tels que :
  • [z/OS]Les serveurs de sécurité compatibles SAF (System Authorization Facility), y compris le serveur de sécurité IBM z/OS Resource Access Control Facility (RACF)
  • Les serveurs proxy inversés sécurisés, y compris WebSEAL

[z/OS]Gestion de l'identification :

[z/OS]Pour WebSphere Application Server Version 7.x et éditions antérieures :

[z/OS]Pour tirer parti des dispositifs de sécurité SAF, les utilisateurs doivent s'identifier à l'aide d'un ID utilisateur z/OS. Vous pouvez utiliser des modules de mappage de principal pour mettre en correspondance une identité J2EE avec votre ID utilisateur de plateforme (ici un ID utilisateur RACF). Un mappage de principal doit être créé entre l'ID utilisateur LDAP et l'ID utilisateur RACF pour que les vérifications SAF EJBROLE s'effectuent. Un module de connexion au mappage doit donc être disponible pour dériver un ID utilisateur z/OS à partir de l'utilisateur configuré dans le registre LDAP. Vous pouvez utiliser le contrôle SMF (compatible SAF) pour effectuer un suivi de ces modifications.

[z/OS]Nouveau pour WebSphere Application Server versions 8.0 et ultérieures :

[z/OS]Pour le mappage d'identité répartie, deux options sont désormais disponibles :
  • Utilisez le module de mappage JAAS pour mapper l'identité J2EE vers une identité SAF.
  • Utilisez la fonction de mappage d'identité répartie dans SAF, qui nécessite une certaine version de SAF. Aucun module de mappage JAAS ne doit être configuré dans WebSphere. Dans ce cas, les utilisateurs s'identifient avec leur identité utilisateur répartie (par exemple, l'identité utilisateur figurant dans le registre LDAP). Le mappage est traité par l'administrateur de la sécurité z/OS à l'aide des profils RACMAP SAF. Cette option améliore la fonction d'audit SMF par la consignation dans l'enregistrement d'audit. Pour plus d'informations, lire l'article sur le mappage d'identité répartie à l'aide de la fonction SAF.

Intégration des normes informatiques actuelles

IBM WebSphere Application Server offre un modèle unifié qui repose sur des stratégies et des autorisations pour sécuriser les ressources Web, les noeuds finaux de service Web et les beans EJB (Enterprise JavaBeans) conformément aux spécifications J2EE. Notamment, WebSphere Application Server est conforme à la spécification Java EE 6 et a subi avec succès la suite de tests de compatibilité J2EE.

La sécurité WebSphere Application Server repose sur une architecture multicouche basée sur une plateforme de système d'exploitation, sur une machine virtuelle Java et sur la sécurité Java 2. Ce modèle de sécurité utilise un jeu de technologies de sécurité riche, avec notamment :
  • Le modèle de sécurité Java 2 qui fournit un contrôle d'accès d'une grande précision aux ressources système, fondé sur les stratégies et les autorisations.
  • Le protocole de sécurité CSIv2 (Common Secure Interoperability) version 2, associé au protocole de sécurité SAS (Secure Authentication Services). Ces deux protocoles sont pris en charge par les éditions précédentes de WebSphere Application Server. Le protocole CSIv2 fait partie intégrante de la spécification J2EE 1.4 et est indispensable pour l'interopérabilité entre les serveurs d'applications des différents fournisseurs et avec les services d'entreprise CORBA.
    [AIX Solaris HP-UX Linux Windows][IBM i][z/OS]Important : SAS est pris en charge uniquement sur les serveurs version 6.0.x et antérieure qui ont été fédérés dans une cellule version 6.1.
  • Le modèle de programmation JAAS (Java Authentication and Authorization Service) pour les applications Java, les servlets et les beans enterprise.
  • L'architecture JCA (J2EE Connector Architecture) pour connecter des adaptateurs de ressources assurant l'accès aux systèmes d'information d'entreprise.

Les modèles de sécurité standard et les interfaces prenant en charge les communications sécurisées par socket, le chiffrement des messages et celui des données s'appellent JSSE (Java Secure Socket Extension) et JCE (Java Cryptographic Extension).

Concept de l'architecture ouverte

Un serveur d'applications joue un rôle déterminant dans un environnement informatique d'entreprise comportant plusieurs niveaux. IBM WebSphere Application Server s'appuie sur le concept d'architecture ouverte et fournit de nombreux points de connexion pour intégrer les composants logiciels d'entreprise. Les points de connexion reposent sur les spécifications J2EE.

Open architecture paradigm

L'arrière-plan ombré bleu foncé indique la limite entre WebSphere Application ServerVersion 9.0 et d'autres composants d'applications métier.

[AIX Solaris HP-UX Linux Windows][IBM i]WebSphere Application Server offre les mécanismes d'authentification SWAM (Simple WebSphere Authentication Mechanism), LTPA (Lightweight Third Party Authentication et Kerberos. Une seule implémentation du registre d'utilisateurs peut être configurée comme registre d'utilisateurs actif du domaine de sécurité WebSphere Application Server. WebSphere Application Server fournit les implémentations suivantes du registre d'utilisateurs :UNIX, Windows, et IBM i local OS et Lightweight Directory Access Protocol (LDAP). Il offre également des implémentations de référence pour les registres d'utilisateurs basés sur des fichiers et sur JDBC (Java database connectivity). Le serveur prend en charge une combinaison variable de mécanismes d'authentification et de registres d'utilisateurs. SWAM est facile à configurer et s'avère utile dans un environnement de serveur d'applications. Il est possible d'utiliser le mécanisme SWAM dans un environnement réparti si la vérification d'identité est activée. La fonction de vérification de l'identité est disponible uniquement avec le protocole de sécurité CSIv2.
Remarque : SWAM était obsolète dans une édition antérieure de WebSphere Application Server, et sera supprimé dans la prochaine version.

[AIX Solaris HP-UX Linux Windows][IBM i]Le mécanisme d'authentification LTPA est conçu pour toute sécurité de plateforme. Les serveurs en aval peuvent valider le jeton de sécurité. Il prend également en charge la configuration des relations de confiance avec les serveurs proxy inversés sécurisés et la signature unique (SSO, Single Sign-On), sujet qui sera abordé ultérieurement. Outre la combinaison des protocoles LTPA et LDAP ou une interface de registre d'utilisateurs personnalisée, les versions 6.x ou ultérieures prennent également en charge le protocole LTPA associé à une interface de registre d'utilisateurs du système d'exploitation local. La nouvelle configuration s'avère notamment utile pour un noeud comportant plusieurs serveurs d'applications. Elle peut fonctionner dans un environnement réparti si l'implémentation du registre d'utilisateurs du système d'exploitation local implique un registre centralisé, tel que le contrôleur de domaines Windows, ou peut rester dans un état cohérent sur plusieurs noeuds.

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]WebSphere Application Server pend en charge l'architecture J2EE Connector et permet une authentification gérée par conteneur. Il fournit un module de mappage de principal et de justificatif par défaut J2C (Java 2 Connector). Ce module associe le justificatif d'un utilisateur authentifié à un justificatif de mot de passe pour le domaine de sécurité EIS (Enterprise Information System) spécifié. Le module de mappage est un module de connexion JAAS spécial, conçu de manière conforme aux spécifications Java 2 Connector et JAAS. Vous pouvez ajouter d'autres modules de connexion de mappage.

[z/OS]

Registre des utilisateurs et contrôle des accès

Les informations relatives aux utilisateurs et groupes sont conservées dans un registre d'utilisateurs. Dans WebSphere Application Server, un registre d'utilisateurs authentifie un utilisateur et extrait les informations sur des utilisateurs et des groupes afin d'exécuter toutes les fonctions de sécurité, notamment l'authentification et l'autorisation.

WebSphere Application Server fournit les implémentations de registre d'utilisateurs suivantes :
  • Système d'exploitation local (fondé sur SAF)
  • LDAP
  • Référentiels fédérés

Outre les registres des systèmes d'exploitation locaux, référentiel fédéré et LDAP, WebSphere Application Server fournit un plug-in pour prendre en charge tous les registres à l'aide de la fonction Registre personnalisé appelée également Registre d'utilisateurs personnalisé.

Lorsque vous choisissez l'implémentation du registre du système d'exploitation local de WebSphere Application Server, vous pouvez intégrer les fonctionnalités de serveur de sécurité z/OS Security Server, par exemple, h RACF (Resource Access Control Facility) directement dans l'environnement WebSphere. Si vous configurez un registre autre que le système d'exploitation local, vous tirez parti des fonctions de serveur de sécurité z/OS avec deux options. Vous pouvez configurer un module de mappage JAAS (suivi d'un serveur d'applications WebSphere pour le module de connexion JAAS fourni par z/OS) dans les configurations de connexion de système appropriées. Dans WebSphere Application Server Version 8.5, vous pouvez utiliser la fonction de mappage d'identité répartie.

Pour plus d'informations, voir Sélection d'un registre ou d'un référentiel.

Configurations WebSphere Application Server : avec WebSphere Application ServerVersion 9.0 pour z/OS, vous pouvez intégrer des applications non z/OS existantes à des fonctions spécifiques de z/OS, telles que AF (System Authorization Facility) et RACF. Cette possibilité vous permet d'unifier les registres de WebSphere Application Server for z/OS et des plateformes non-z/OS. Exemple :

Tableau 1. Exemple de configurations de registre WebSphere Application Server.

Le tableau ci-après présente un exemple de configurations de registre WebSphere Application Server

Configuration du serveur d'applications Type de registre Méthode d'autorisation Avantage
WebSphere Application Server LDAP Liaisons WebSphere et fournisseurs de sécurité externes, tels que Tivoli Access Manager Registres partagés (sur une plateforme hétérogène)
WebSphere Application Server for z/OS RACF Liaisons WebSphere et rôles RACF EJBROLE Accès centralisé et possibilité de contrôle (y compris les serveurs en version 4.0)
environnement mixte WebSphere Application Server LDAP ou personnalisé Liaisons WebSphere, fournisseurs de sécurité externes et rôlesRACF EJBROLE Registres partagés, accès centralisé et possibilité de contrôle
Les images ci-après illustrent les descriptions figurant dans le tableau précédent.
  • WebSphere Application Server Configuration de registre réseau Configuration de registre réseau
  • Configuration de registre réseau WebSphere Application Server pour z/OS :Configuration de registre réseau z/OS
  • Registre réseau WebSphere Application Server avec extensions de sécurité z/OS registre réseau avec extensions de sécurité z/OS

Mécanismes d'authentification

Dans WebSphere Application Server, les mécanismes d'authentification suivants sont pris en charge :
  • Lightweight Third Party Authentication

    LTPA génère un jeton de sécurité pour les utilisateurs authentifiés qui peut représenter ces derniers lors d'appels ultérieurs aux mêmes serveurs ou à des serveurs différents d'un domaine de connexion unique (SSO).

  • Kerberos

    Le support de sécurité pour Kerberos en tant que mécanisme d'authentification a été ajoutée pour cette édition de WebSphere Application Server. Kerberos est un protocole d'authentification réseau mûr, souple, ouvert et très sécurisé. Kerberos inclut l'authentification, l'authentification mutuelle, l'intégrité et la confidentialité des messages ainsi que des fonctions de délégation.

  • SWAM (Simple WebSphere Authentication Mechanism)
    SWAM est facile à configurer et d'une grande utilité dans un environnement de serveur d'applications mais il force l'authentification par ID utilisateur et mot de passe lors de chaque demande.
    Remarque : SWAM était obsolète dans une édition antérieure de WebSphere Application Server, et sera supprimé dans la prochaine version.

Protocoles d'authentification IIOP

Le terme de protocole d'authentification IIOP désigne les mécanismes utilisés pour authentifier les demandes d'un client Java sur un WebSphere Application Server for z/OS ou entre des serveurs d'applications J2EE. Le protocole CSIv2 (Common Secure Interoperability) version 2 est implémenté dans WebSphere Application Server for z/OS Version 6.x ou version ultérieure et il est considéré comme le protocole stratégique.

[z/OS]

Sécurité WebSphere Application Server for z/OS Connector

WebSphere Application Server pend en charge l'architecture J2EE Connector et permet une authentification gérée par conteneur. Il fournit un module de mappage de principal et justificatif J2C qui mappe le justificatif d'un utilisateur authentifié à un justificatif de mot de passe pour le domaine de sécurité EIS (Enterprise Information System) spécifié. Les connecteurs z/OS sont également pris en charge lorsque le système EIS se trouve dans le même domaine de sécurité que WebSphere Application Server. Dans ce cas, aucun mot de passe n'est requis car les justificatifs authentifiés utilisés pour les demandes J2EE peuvent être utilisés comme justificatifs EIS.

Sécurité des Services Web

WebSphere Application Server permet de sécuriser les services Web en utilisant la spécification OASIS (Organization for the Advancement of Structured Information Standards) de sécurité des Services Web (version 1.1). Ces normes permettent d'assurer la protection des messages échangés dans un environnement de services Web. Cette spécification définit les fonctions principales de protection de l'intégrité et de la confidentialité d'un message et fournit des mécanismes permettant d'associer au message les réclamations liées à la sécurité.

Relations de confiance

La relation de confiance permet d'intégrer les serveurs de sécurité tiers à la sécurité IBM WebSphere Application Server. Plus précisément, elles permettent à un serveur proxy inverse d'agir comme serveur d'authentification frontal lorsque WebSphere Application Server applique sa stratégie d'authentification aux justificatifs transmis par le serveur proxy. Le serveur proxy inverse applique ses stratégies d'authentification à chaque demande Web envoyée à WebSphere Application Server. Les produits implémentant des intercepteurs d'association de confiance (TAI pour trust association interceptors) sont :
  • IBM Tivoli Access Manager for e-business
  • WebSEAL
  • Caching Proxy
Pour plus d'informations sur l'utilisation des relations de confiance, voir Relations de confiance.

Propagation des attributs de sécurité

La propagation des attributs de sécurité permet à WebSphere Application Server de transmettre des attributs de sécurité d'un serveur à un autre de votre configuration. Les attributs de sécurité sont les contenus de sujet authentifié et les informations de contexte de sécurité. WebSphere Application Server peut obtenir ces attributs de sécurité depuis l'une des sources suivantes :
  • Un registre d'utilisateurs d'entreprise qui interroge les attributs statiques
  • Un module de connexion personnalisé capable d'interroger les attributs statiques ou dynamiques
La propagation des attributs de sécurité fournit des services de propagation à l'aide de la sérialisation Java pour tous les objets contenus dans le sujet. Pour plus d'informations sur la propagation d'attributs de sécurité, voir Propagation des attributs de sécurité.

Mode d'interopérabilité de connexion unique

Dans WebSphere Application Server, l'option de mode d'interopérabilité permet l'interopérabilité des connexions uniques (SSO) entre WebSphere Application Server version 6.1 et les versions suivantes pour interopérer avec les versions précédentes du serveur d'applications. Lorsque vous sélectionnez cette option, WebSphere Application Server insère l'ancien type jeton LtpaToken dans la réponse afin qu'il puisse être envoyé aux serveurs qui utilisent uniquement ce type de jeton. Cette option s'applique uniquement lorsque l'option de propagation des attributs de sécurité des communications Web entrantes est activée. Pour plus d'informations sur la connexion unique (SSO) voir Implémentation d'une connexion unique pour réduire les authentifications d'utilisateur Web

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]

Sécurité des ressources J2EE à l'aide de conteneurs Web et de conteneurs EJB

Chacun d'eux offre deux types de sécurité, à savoir déclarative et par programmation. Dans le premier cas, la structure de sécurité d'une application, incluant l'intégrité et la confidentialité des données, les conditions d'authentification, les rôles de sécurité et le contrôle d'accès, est exprimé sous une forme externe à l'application. Notamment, le descripteur de déploiement est le vecteur principal d'une sécurité déclarative pour la plateforme J2EE. WebSphere Application Server gère une règle de sécurité J2EE, y compris les informations provenant du descripteur de déploiement et indiquées par des déployeurs et des administrateurs dans un ensemble de fichiers XML. Au moment de l'exécution, le conteneur utilise les règles de sécurité définies dans les fichiers XML pour appliquer des contraintes de données et un contrôle d'accès. Lorsque la sécurité déclarative s'avère insuffisante pour exprimer le modèle de sécurité d'une application, celle par programmation peut être utilisée par le code pour prendre des décisions d'accès. L'API destinée à la sécurité par programmation comporte deux méthodes de l'interface Enterprise JavaBeans (isCallerInRole et getCallerPrincipal) et trois méthodes de l'interface HttpServletrequest de servlet (isUserInRole, getUserPrincipal et getRemoteUser).

[AIX Solaris HP-UX Linux Windows][z/OS]

Sécurité Java 2

WebSphere Application Server prend en charge le modèle de sécurité Java 2. Les codes système tels que le sous-système administratif, le conteneur Web et le conteneur EJB, sont exécutés dans le domaine de sécurité WebSphere Application Server, qui, dans la présente implémentation, reçoivent l'autorisation AllPermission et peuvent accéder à toutes les ressources système. Le code d'application exécuté dans le domaine de sécurité des applications, qui reçoit par défaut les droits d'accès conformément aux spécifications J2EE, ne peut accéder qu'à un ensemble restreint de ressources système. Les classes d'exécution de WebSphere Application Server sont protégées par le chargeur de classe WebSphere Application Server et demeurent invisibles pour le code de l'application.

[AIX Solaris HP-UX Linux Windows][z/OS]

Sécurité du connecteur Java 2 Platform, Enterprise Edition

WebSphere Application Server pend en charge l'architecture J2EE Connector et permet une authentification gérée par conteneur. Il fournit un module de mappage de principal et justificatif J2C qui mappe le justificatif d'un utilisateur authentifié à un justificatif de mot de passe pour le domaine de sécurité EIS (Enterprise Information System) spécifié.

[z/OS]Les connecteurs z/OS sont également pris en charge lorsque le système EIS se trouve dans le même domaine de sécurité que WebSphere Application Server. Dans ce cas, aucun mot de passe n'est requis car les justificatifs authentifiés utilisés pour les demandes J2EE peuvent être utilisés comme justificatifs EIS.

[z/OS]Pour plus d'informations, voir Identité d'unité d'exécution de connexion.

[z/OS]Processus de WebSphere Application Server

Tous les processus du serveur d'applications partagent par défaut une configuration de sécurité définie dans un document de sécurité XML au niveau de la cellule. La configuration de sécurité définit l'activation ou la désactivation de la sécurité de WebSphere Application Server et de la sécurité Java 2, le mécanisme d'authentification et la configuration du registre d'utilisateurs, ainsi que les configurations des protocoles de sécurité, de la connexion JAAS et de la couche SSL (Secure Sockets Layer). Chaque application peut imposer des conditions de sécurité propres. Chaque processus de serveur d'applications peut générer une configuration de sécurité spécifique pour répondre aux conditions qui lui correspondent ou être associé à un domaine de sécurité WebSphere. Les configurations de sécurité ne sont pas toutes modifiables au niveau du serveur d'applications. Certaines configurations de sécurité modifiables au niveau du serveur d'applications déterminent si la sécurité de l'application et de Java 2 doit être mise en oeuvre, et définissent aussi les configurations des protocoles de sécurité. Les domaines de sécurité WebSphere autorisent un meilleur contrôle par rapport à la configuration de la sécurité ; ils peuvent être mappés à des serveurs individuels. Pour plus d'informations, lisez la rubrique relative aux multiples domaines de sécurité.

[z/OS]Pour des informations plus générales, voir Etats de sécurité avec prise en charge de l'identité d'unité d'exécution.

La configuration de sécurité du sous-système administratif est toujours fonction du document de sécurité au niveau des cellules. La configuration de la sécurité du conteneur Web et du conteneur EJB est défini par le document facultatif de sécurité au niveau du serveur, qui est prioritaire par rapport au document de sécurité au niveau des cellules.

La configuration de la sécurité, au niveau de la cellule et du serveur d'applications, est gérée par la console d'administration Web ou l'applications de scriptage appropriée.

[z/OS]Remarque : Vous ne pouvez pas modifier les mécanismes d'authentification au niveau du serveur.

Sécurité Web

Lorsqu'une stratégie de sécurité est définie pour une ressource Web et que la sécurité IBM WebSphere Application Server est activée, le conteneur Web contrôle les accès si un client Web demande à accéder à la ressource. Le conteneur Web interroge le client sur ses données d'authentification (lorsque celles-ci ne sont pas définies selon la méthode d'authentification spécifiée), vérifie que les contraintes relatives aux données sont respectées et détermine si l'utilisateur authentifié possède le rôle de sécurité requis. WebSphere Application Server prend en charge les méthodes de connexion suivantes :
  • Authentification HTTP de base
  • Authentification client HTTPS
  • Connexion par formulaire
  • Jeton SPNEGO (Simple and Protected GSS-API Negotiation)
Le mappage d'un certificat client à un droit d'accès de sécurité WebSphere Application Server utilise l'implémentation du registre d'utilisateurs.

[AIX Solaris HP-UX Linux Windows][IBM i]Sur WebSphere Application Server, le registre d'utilisateurs du système d'exploitation local ne prend pas en charge la fonction de mappage.

[AIX Solaris HP-UX Linux Windows][IBM i]Lorsque le mécanisme d'authentification LTPA est configuré et que la connexion unique (SSO) est activée, un client authentifié reçoit un cookie de sécurité, qui peut représenter l'utilisateur dans le domaine de sécurité indiqué.

Il est conseillé d'utiliser SSL (Secure Sockets Layer) pour empêcher que le cookie de sécurité ne soit intercepté et réexécuté et protéger les données d'authentification de base. Si une relation de confiance est configurée, WebSphere Application Server peut mapper l'identité d'un client authentifié à un droit d'accès de sécurité en fonction des relations de confiance établies avec le serveur proxy inverse sécurisé.

sécurité Web

Remarques relatives aux collaborateurs de sécurité Web et aux collaborateurs de sécurité EJB :
  1. Le collaborateur de sécurité Web assure le contrôle d'accès basé sur les rôles à l'aide de l'implémentation du gestionnaire d'accès. Ce dernier prend des décisions d'autorisation en fonction des règles de sécurité issues du descripteur de déploiement. Un principal d'utilisateur authentifié peut accéder au servlet ou au fichier JSP demandé s'il possède l'un des rôles de sécurité requis. Les servlets et les fichiers JSP peuvent utiliser les méthodes isUserInRole, getUserPrincipal et getRemoteUser. Par exemple, la console d'administration utilise la méthode isUserInRole pour déterminer les fonctionnalités d'administration à présenter au principal d'un utilisateur.
  2. Le collaborateur de sécurité EJB assure le contrôle d'accès basé sur les rôles à l'aide de l'implémentation du gestionnaire d'accès. Ce dernier prend des décisions d'autorisation en fonction des règles de sécurité issues du descripteur de déploiement. Un principal de l'utilisateur authentifié est autorisé à accéder à la méthode d'EJB demandée s'il possède l'un des rôles de sécurité requis. Le code EJB peut utiliser les méthodes EJBContext isCallerInRole et getCallerPrincipal. Le code EJB peut également utiliser le modèle de programmation JAAS pour effectuer la connexion JAAS et les méthodes WSSubject doAs et doAsPrivileged. Le code du bloc doAs et doAsPrivileged PrivilegedAction est exécuté sous l'identité du sujet. Sinon, la méthode d'EJB est exécutée sous l'identité RunAs ou l'identité du demandeur, en fonction de la configuration RunAs.

Sécurité EJB

Lorsque la sécurité est activée, le conteneur d'EJB effectue un contrôle d'accès sur l'appel de la méthode d'EJB. L'authentification est effectuée, que les droits d'accès soient définis ou non pour la méthode d'EJB concernée.

Un client Java peut fournir ses données d'authentification de différentes manières. A l'aide du fichier sas.client.props, un client Java peut indiquer si l'authentification doit être effectuée avec son ID utilisateur et son mot de passe ou avec un certificat client SSL. Le certificat est stocké dans un fichier clé ou dans la carte de cryptographie, comme déterminé dans un fichier sas.client.props. l'ID et le mot de passe de l'utilisateur peuvent éventuellement être définis dans le fichier as.client.props.

Au moment de l'exécution, le client Java peut réaliser une connexion par programmation ou une authentification plus passive.

Dans le cas de l'authentification "passive", la première fois que le client Java accède à un bean enterprise protégé, l'environnement d'exécution de la sécurité tente d'obtenir les données d'authentification requises. Selon les paramètres de configuration définis dans le fichier sas.client.props, l'environnement d'exécution de la sécurité recherche des données d'authentification dans ce fichier ou les demande à l'utilisateur. Par ailleurs, un client Java peut effectuer une connexion par programmation. WebSphere Application Server prend en charge le modèle de programmation JAAS et la connexion JAAS (LoginContext) est la méthode recommandée développement de modules de connexion de programmation pour Java. La fonction login_helper request_login est obsolète dans la version 6.x et Version 9.0. Les clients Java programmés pour le langage APT login_helper peuvent s'exécuter dans cette version.

Le collaborateur de sécurité EJB assure le contrôle d'accès basé sur les rôles à l'aide de l'implémentation du gestionnaire d'accès.

Ce dernier prend des décisions d'autorisation en fonction des règles de sécurité issues du descripteur de déploiement. Un principal de l'utilisateur authentifié est autorisé à accéder à la méthode d'EJB demandée s'il possède l'un des rôles de sécurité requis. Le code EJB peut utiliser les méthodes isCallerInRole et getCallerPrincipal du contexte EJB. Le code EJB peut également utiliser le modèle de programmation JAAS pour effectuer la connexion JAAS et les méthodes WSSubject doAs et doAsPrivileged. Le code de ces méthodes est exécuté sous l'identité du sujet. Sinon, la méthode d'EJB est exécutée sous l'identité d'exécution ou sous celle de l'appelant, selon la configuration d'exécution. La spécification d'exécution J2EE se trouve au niveau des beans enterprise. Lorsque l'identité d'exécution est précisée, elle s'applique à toutes les méthodes de beans. L'extension d'exécution IBM RunAs valable au niveau de la méthode et instaurée dans la version 4.0 est également prise en charge dans cette version.

[z/OS]Remarque : Une fois l'autorisation accordée, l'identité RunAs est utilisée en aval. Il s'agit en général de l'identité de l'appelant mais une identité déléguée est admise.

Approuvé FIPS (Federal Information Processing Standards)

FIPS (Federal Information Processing Standards) est un ensemble de normes et d'instructions élaborées par l'organisme NIST (National Institute of Standards and Technology) pour les systèmes informatiques fédéraux. Les normes FIPS sont élaborées pour répondre à des exigences de l'administration en matières de normes, telles que des normes de sécurité et d'interopérabilité, lorsqu'il n'existe pas de normes ou de solutions acceptables dans l'industrie.

WebSphere Application Server intègre des modules de chiffrement, dont JSSE (Java Secure Socket Extension) et JCE (Java Cryptography Extension), soumis à la certification FIPS 140-2.

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]Pour plus d'informations, voir Configuration de fichiers JSSE (Java Secure Socket Extension) conformes à la norme FIPS.

Le module IBMJCEFIPS prend en charge les séries de chiffrement symétriques suivantes :
  • AES (FIPS 197)
  • TripleDES (FIPS 46-3)
  • Algorithme SHA1 Message Digest (FIPS 180-1)
Le module IBMJCEFIPS prend en charge les algorithmes suivants :
  • Algorithmes de signature numérique DSA et RSA (FIPS 186-2)
  • ANSI X 9.31 (FIPS 186-2)
  • IBM Random Number Generator

Le module de chiffrement IBMJCEFIPS ne contient que les algorithmes approuvés par FIPS, qui représentent un sous-ensemble approprié des algorithmes des modules IBM JCE.


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=welc_security
Nom du fichier : welc_security.html