Protocole d'authentification pour la sécurité des EJB

Les serveurs WebSphere Application Server Version 9.0 prennent en charge uniquement le protocole d'authentification CSIv2.[AIX Solaris HP-UX Linux Windows][IBM i] SAS est pris en charge uniquement sur les serveurs version 6.0.x et version antérieure qui ont été fédérés dans une cellule Version 9.0. La possibilité de sélectionner SAS, CSIv2 ou les deux est disponible uniquement dans la console d'administration lorsqu'un serveur version 6.0.x ou antérieure a été fédéré dans une cellule Version 9.0. [z/OS]z/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 9.0. La possibilité de sélectionner z/SAS, CSIv2 ou les deux est disponible uniquement dans la console d'administration lorsqu'un serveur version 6.0.x ou version antérieure a été fédéré dans une cellule de version 6.1.

[AIX Solaris HP-UX Linux Windows][IBM i]SAS est le protocole d'authentification utilisé par toutes les versions précédentes de WebSphere Application Server et est conservé pour une compatibilité en amont. Le groupe OMG (Object Management Group) a défini le protocole d'authentification CSIv2 afin que les fournisseurs puissent travailler ensemble en toute sécurité. CSIv2 est implémenté dans WebSphere Application Server avec plus de fonctions que SAS et il est considéré comme étant le protocole stratégique.
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.
[z/OS]Le groupe OMG (Object Management Group) a défini le protocole d'authentification CSIv2 afin que les fournisseurs puissent travailler ensemble en toute sécurité. CSIv2 est implémenté dans WebSphere Application Server avec plus de fonctions que z/SAS et est considéré comme le protocole stratégique.
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.

L'appel des méthodes EJB (Enterprise Java™ Beans) dans un environnement WebSphere Application Server sécurisé requiert un protocole d'authentification afin de déterminer le niveau de sécurité et le type d'authentification entre un client donné et le serveur pour chaque demande. Lors de l'appel d'une méthode, le protocole d'authentification est chargé de fusionner les besoins d'authentification du serveur déterminés par l'identificateur IOR (Interoperable Object Reference) de l'objet avec les besoins d'authentification du client déterminés par la configuration du client, ce dernier étant associé à une règle d'authentification spécifique à cette paire client/serveur.

La stratégie d'authentification prend notamment les décisions suivantes, qui dépendent de la configuration du client et du serveur :
  • Quel type de connexion pouvez-vous établir avec ce serveur - Secure Sockets Layer (SSL) ou TCP/IP ?
  • Si vous avez choisi SSL, quel est le niveau de chiffrement des données ?
  • Si SSL est choisi, devez-vous authentifier le client à l'aide de certificats client ?
  • Devez-vous authentifier le client à l'aide d'un ID utilisateur et d'un mot de passe ? Existe-t-il un justificatif ?
  • Devez-vous déclarer l'identité du client aux serveurs en amont ?
  • Etant donné la configuration du client et du serveur, une requête sécurisée peut-elle être effectuée ?

[AIX Solaris HP-UX Linux Windows][IBM i]Vous pouvez configurer les deux protocoles (SAS et CSIv2) afin qu'ils fonctionnent simultanément. Si un serveur prend en charge les deux protocoles, il exporte une référence IOR contenant des composants marqués décrivant la configuration de SAS et CSIv2. Si un client prend en charge les deux protocoles, il lit les composants marqués pour CSIv2 et SAS. Si le client et le serveur prennent en charge ces deux protocoles, CSIv2 est utilisé. Toutefois, si le serveur prend en charge SAS (par exemple, s'il s'agit d'une édition précédente de WebSphere Application Server) et que le client prend en charge les deux protocoles, le client choisit SAS pour cette demande car c'est le protocole qu'ils ont tous deux en commun.

[z/OS]Vous pouvez configurer les deux protocoles (z/SAS et CSIv2) afin qu'ils fonctionnent simultanément. Si un serveur prend en charge les deux protocoles, il exporte une référence IOR contenant des composants marqués décrivant la configuration de z/SAS et CSIv2. Si un client prend en charge les deux protocoles, il lit les composants marqués pour CSIv2 et z/SAS. Si le client et le serveur prennent en charge ces deux protocoles, CSIv2 est utilisé. Toutefois, si le serveur prend en charge z/SAS (par exemple, s'il s'agit d'une édition précédente de WebSphere Application Server) et que le client prend en charge les deux protocoles, le client choisit z/SAS pour cette demande car c'est le protocole qu'ils ont tous deux en commun.

[z/OS]CSIv2 est considéré comme étant activé sur le client en raison de l'existence de la propriété Java com.ibm.CORBA.ConfigURL. Si cette propriété n'est pas indiquée ou si la propriété indiquée n'existe pas, CSIv2 n'est pas activé.

[AIX Solaris HP-UX Linux Windows][IBM i]Le choix du protocole est défini via la propriété com.ibm.CSI.protocol au niveau du client et configuré à l'aide de la console d'administration au niveau du serveur. Des informations plus détaillées sont disponibles dans les articles relatifs aux propriétés SAS et CSIv2.

CSIv2 (Common Secure Interoperability Specification, Version 2)

[AIX Solaris HP-UX Linux Windows][IBM i]La spécification CSIv2 (Common Secure Interoperability Specification, Version 2) définit le service SAS (Security Attribute Service) qui permet l'authentification interopérable, la délégation et les privilèges. Les protocoles CSIv2 SAS et SAS sont totalement différents. Le protocole CSIv2 SAS est un sous-composant de CSIv2 qui prend en charge SSL et l'interopérabilité avec la spécification EJB Specification, version 2.1.

[z/OS]La spécification CSIv2 (Common Secure Interoperability Specification, Version 2) définit le service SAS (Security Attribute Service) qui permet l'authentification interopérable et la délégation. Les protocoles CSIv2 et z/SAS sont totalement différents. Le protocole CSIv2 SAS est un sous-composant de CSIv2 qui prend en charge SSL et l'interopérabilité.

Service d'attribut de sécurité

Le protocole CSIv2 (Common Secure Interoperability Specification, Version 2) SAS (Security Attribute Service) est conçu pour échanger ses éléments de protocole dans le contexte de service d'une demande GIOP (General Inter-ORB Protocol) et pour répondre aux messages communiqués via un transport par connexion. Ce protocole est conçu pour utilisation dans des environnements où la sécurité de couche transport, telle que celle disponible via SSL (Secure Sockets Layer) et TLS (Transport Layer Security), permet de fournir une protection de message (c'est-à-dire, l'intégrité ou la confidentialité) et l'authentification serveur/client. Le protocole fournit une authentification client, la délégation et la fonctionnalité de privilège qui peut être appliquée afin de résoudre les déficiences correspondantes dans un transport sous-jacent. Le protocole CSIv2 SAS facilite l'interopérabilité en assurant un rôle de protocole de niveau élevé qui permet de regrouper les transports sécurisés.

Intercepteurs de connexion et de requête

Les protocoles d'authentification utilisés par WebSphere Application Server sont des services IIOP (Interoperable Inter-ORB Protocol) ajoutés. IIOP est un protocole de communications requête/réponse permettant d'envoyer des messages entre deux composants ORB (Object Request Broker). Pour chaque requête effectuée par un ORB du client à un ORB du serveur, il existe une réponse associée effectuée par l'ORB du serveur à l'ORB du client. Avant toute requête, une connexion entre l'ORB du client et l'ORB du serveur doit être établie via le transport TCP/IP (SSL est une version sécurisée de TCP/IP). L'ORB du client appelle l'intercepteur de connexions du client du protocole d'authentification qui permet de lire les composants balisés dans l'IOR de l'objet se trouvant sur le serveur. Comme indiqué précédemment, la règle d'authentification est établie à cet emplacement pour la demande. En fonction de la stratégie d'authentification (regroupement de la configuration du serveur à la configuration du client), la puissance de la connexion est renvoyée à l'ORB. L'ORB effectue la connexion appropriée, généralement via SSL.

Une fois que la connexion est établie, l'ORB du client appelle l'intercepteur de requêtes du client du protocole d'authentification qui permet d'envoyer des informations de sécurité autres que celles établies par le transport. Ces informations de sécurité incluent le jeton de l'ID utilisateur et du mot de passe authentifiés par le serveur, un jeton spécifique au mécanisme d'authentification validé par le serveur ou un jeton de vérification d'identité. Une vérification d'identité permet à un serveur de faire confiance à un serveur sans qu'il soit nécessaire d'authentifier ou de valider à nouveau le serveur d'origine. Toutefois, des opérations sont nécessaire pour que le serveur établisse une relation de confiance avec le serveur en amont. Ces informations de sécurité supplémentaires sont envoyées avec le message dans un contexte de service. Un contexte de service comporte un identificateur enregistré afin que l'ORB du serveur puisse identifier le protocole envoyant les informations.

[AIX Solaris HP-UX Linux Windows][IBM i]Le fait qu'un contexte de service contienne une identité unique constitue un autre moyen pour WebSphere Application Server de prendre en charge simultanément SAS et CSIv2 car les deux protocoles ont des ID de contexte de service différents. Une fois que l'intercepteur de requêtes du client a fini d'ajouter le contexte de service au message, le message est envoyé à l'ORB du serveur.

[z/OS]Le fait qu'un contexte de service contienne une identité unique constitue un autre moyen pour WebSphere Application Server de prendre en charge simultanément z/SAS et CSIv2 car les deux protocoles ont des ID de contexte de service différents. Une fois que l'intercepteur de requêtes du client a fini d'ajouter le contexte de service au message, le message est envoyé à l'ORB du serveur.

[AIX Solaris HP-UX Linux Windows][IBM i]Lorsque le message est reçu par l'ORB du serveur, l'ORB appelle l'intercepteur de requêtes du serveur du protocole d'authentification. Cet intercepteur recherche l'ID de contexte de service connu du protocole. Lorsque SAS et CSIv2 sont pris en charge par un serveur, deux intercepteurs de requêtes du serveur différents sont appelés et recherchent des ID de contexte de services différents.

[z/OS]Lorsque le message est reçu par l'ORB du serveur, l'ORB appelle l'intercepteur de requêtes du serveur du protocole d'authentification. Cet intercepteur recherche l'ID de contexte de service connu du protocole. Lorsque z/SAS et CSIv2 sont pris en charge par un serveur, deux intercepteurs de requêtes du serveur différents sont appelés et recherchent des ID de contexte de services différents.

Toutefois, un seul des deux intercepteurs trouve un service de contexte pour une requête donnée. Lorsque l'intercepteur de requêtes du serveur trouve un contexte de service, il lit les informations dans le contexte de service. Une méthode est appelée sur le serveur de sécurité afin d'authentifier ou de valider l'identité du client. Le serveur de sécurité rejette les informations ou renvoie un justificatif. Un justificatif contient des informations supplémentaires sur le client, extraites du registre d'utilisateurs afin que l'autorisation puisse prendre la décision appropriée. L'autorisation est le processus permettant de déterminer si l'utilisateur peut appeler la requête en fonction des rôles appliqués à la méthode et des rôles attribués à l'utilisateur.

Si aucun contexte de service n'est trouvé par l'intercepteur de requêtes du serveur CSIv2, l'intercepteur recherche la connexion de transport afin de déterminer si une chaîne de certificats client a été envoyée. Ce processus est exécuté lorsque l'authentification client SSL est configurée entre le client et le serveur.

[AIX Solaris HP-UX Linux Windows][IBM i]Si une chaîne de certificats client est trouvée, le nom distinctif est extrait du certificat et permet d'effectuer un mappage vers une identité dans le registre d'utilisateurs. Si le registre d'utilisateurs est de type LDAP (Lightweight Directory Access Protocol), les filtres de recherche définis dans la configuration du registre LDAP déterminent comment le certificat est mappé à une entrée du registre. Si le registre d'utilisateurs est le système d'exploitation local, le premier attribut du nom distinctif dans le certificat est mappé vers l'ID utilisateur du registre. Cet attribut correspond généralement au nom commun.

[z/OS]Si le registre d'utilisateurs est de type LDAP (Lightweight Directory Access Protocol), les filtres de recherche définis dans la configuration du registre LDAP déterminent comment le certificat est mappé à une entrée du registre. Si le registre d'utilisateurs est le système d'exploitation local, le certificat est mappé vers un ID utilisateur SAF (System Authorization Facility). Vous pouvez ensuite mapper l'ID utilisateur à l'aide du nom des émetteurs ou des sujets, à l'aide de la fonctionnalité de mappage des certificats SAF.

Si le certificat n'effectue pas de mappage, aucun justificatif n'est créé et la requête est rejetée. Lorsqu'aucune donnée de sécurité valide n'est fournie, la requête de la méthode est rejetée et une exception NO_PERMISSION est envoyée avec la réponse. Toutefois, lorsqu'aucune donnée de sécurité n'est fournie, un justificatif non authentifié est créé pour la requête et le moteur d'autorisation détermine si la méthode est appelée. Pour que les données d'identification appellent une méthode EJB (Enterprise JavaBeans), aucun rôle de sécurité ne doit être défini pour la méthode ou un rôle Everyone spécial doit être défini pour la méthode.

Lorsque l'appel de la méthode aboutit dans le conteneur d'EJB, l'intercepteur de requêtes du serveur est à nouveau appelé pour mener à terme l'authentification serveur et un nouveau contexte de service de réponse est créé pour informer l'intercepteur de requêtes du client du résultat. Ce processus permet généralement de créer une requête avec état. Lorsqu'une requête avec état est effectuée, l'envoi d'informations de sécurité est requis uniquement pour la première requête entre un client et un serveur. Toutes les requêtes de méthode suivantes n'ont qu'un ID de contexte à envoyer pour que le serveur puisse envoyer le justificatif stocké dans une table de sessions. L'ID de contexte est unique dans la connexion entre un client et un serveur.

Finalement, le cycle de requêtes de méthodes s'achève lorsque l'intercepteur de requêtes du client reçoit une réponse du serveur, associée à un contexte de service de réponse qui fournit les informations nécessaires à la confirmation et à la réutilisation de l'ID de contexte avec état côté client.

[AIX Solaris HP-UX Linux Windows][IBM i]La définition d'un client avec état est effectuée via la propriété com.ibm.CSI.performStateful (true/false). La définition d'un serveur avec état est effectuée via la configuration de la console d'administration.

[z/OS]Le client et le serveur prennent en charge à la fois les sessions avec état et sans état et ceci ne peut pas être configuré.

Flux du protocole d'authentificationFlux du protocole d'authentification

Stratégie d'authentification pour chaque requête

Cette stratégie détermine comment la sécurité entre un client et un serveur est préservée. Une configuration de protocole d'authentification client ou serveur peut décrire des fonctions requises, des fonctions prises en charge et des fonctions non prises en charge. Lorsqu'un client a besoin d'une fonction, il ne peut communiquer qu'avec les serveurs nécessitant ou prenant en charge cette fonction. Lorsqu'un serveur a besoin d'une fonction, il ne peut communiquer qu'avec les clients nécessitant ou prenant en charge cette fonction. Lorsqu'un client prend en charge une fonction, il peut communiquer avec un serveur ayant besoin ou prenant en charge cette fonction mais il peut également communiquer avec les serveurs ne prenant pas en charge cette fonction. Lorsqu'un serveur prend en charge une fonction, il peut communiquer avec un client ayant besoin ou prenant en charge cette fonction mais il peut également communiquer avec les clients qui ne prennent pas en charge cette fonction.

Par exemple, pour qu'un client prenne en charge l'authentification du certificat client, certaines opérations de configurations sont requises pour générer un certificat auto-signé ou obtenir un certificat d'une autorité de certification (CA). Pour éviter d'effectuer l'ensemble de ces opérations, vous pouvez configurer cette fonction en tant que fonction non prise en charge. S'il prend cette décision, le client ne peut pas établir de communication avec un serveur sécurisé nécessitant l'authentification du certificat client. A la place, ce client peut choisir d'utiliser un ID utilisateur et un mot de passe en tant que méthode d'authentification au serveur.

Généralement, la prise en charge d'une fonction constitue la manière la plus répandue de configurer des fonctions. Il s'agit également de la méthode la plus efficace lors de l'exécution car les erreurs sont tolérées. En fonction du mode de configuration des serveurs dans le domaine, vous pouvez choisir la combinaison correcte afin que le client puisse garantir le succès des appels de méthode et ainsi obtenir une sécurité optimale. Si vous savez que tous les serveurs prennent en charge le certificat client et l'authentification via un ID utilisateur et un mot de passe, vous pouvez exiger une méthode pour le client et ne pas prendre en charge l'autre. Si ces deux méthodes sont prises en charge sur le client et sur le serveur, elles sont utilisées toutes les deux, mais l'authentification via un ID utilisateur et un mot de passe est prioritaire au niveau du serveur. Cette action repose sur les exigences de la spécification 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_corba
Nom du fichier : csec_corba.html