Rôles de nommage
Le concept d'autorisation fondé sur les rôles J2EE (Java™ 2 Platform, Enterprise Edition) est étendu pour protéger le service CosNaming.
La sécurité CosNaming propose une granularité développée du contrôle de sécurité sur les fonctions CosNaming. Les fonctions CosNaming sont disponibles sur les serveurs CosNaming, tel que WebSphere Application Server. Elles affectent le contenu de l'espace de nom. Il existe généralement deux situations dans lesquelles les programmes client provoquent des appels CosNaming : D'abord par les méthodes JNDI (Java Naming and Directory Interface) Dans le deuxième cas, les clients CORBA appellent les méthodes CosNaming directement.
- CosNamingRead. Les utilisateurs disposant du rôle CosNamingRead peuvent
interroger l'espace de nom, par exemple, via la méthode de recherche JNDI.
Le sujet
spécial Everyone est la stratégie par défaut de ce rôle.
Tableau 1. Méthodes d'interface et packages du rôle CosNamingRead. Le tableau suivant répertorie les méthodes d'interface et les packages du rôle CosNamingRead : Package Méthodes d'interface javax.naming - Context.list
- Context.listBindings
- Context.lookup
- NamingEnumeration.hasMore
- NamingEnumeration.next
org.omg.CosNaming - NamingContext.list
- NamingContext.resolve
- BindingIterator.next_one
- BindingIterator.next_n
- BindingIterator.destroy
- CosNamingWrite. Les utilisateurs disposant du rôle
CosNamingWrite peuvent effectuer des opérations d'écriture JNDI, telles que
bind, rebind ou unbind, ainsi que des opérations CosNamingRead. Comme règles par défaut, Subjects ne dispose pas de ce rôle.
Tableau 2. Méthodes d'interface et packages du rôle CosNamingWrite. Le tableau suivant répertorie les méthodes d'interface et les packages du rôle CosNamingWrite : Package Méthodes d'interface javax.naming - Context.bind
- Context.rebind
- Context.rename
- Context.unbind
org.omg.CosNaming - NamingContext.bind
- NamingContext.bind_context
- NamingContext.rebind
- NamingContext.rebind_context
- NamingContext.unbind
- CosNamingCreate. Les utilisateurs disposant du rôle CosNamingCreate
sont autorisés à créer des objets dans l'espace de nom via des opérations
createSubcontext JNDI, ainsi que des opérations CosNamingWrite. Ce rôle ne peut pas être affecté aux sujets car ces derniers constituent des règles par défaut.
Tableau 3. Méthodes d'interface et packages du rôle CosNamingCreate. Le tableau suivant répertorie les méthodes d'interface et les packages du rôle CosNamingCreate : Package Méthodes d'interface javax.naming Context.createSubcontext org.omg.CosNaming NamingContext.bind_new_context - CosNamingDelete. Les utilisateurs possédant le rôle CosNamingDelete peuvent
supprimer des objets dans l'espace de nom, par exemple à l'aide de la méthode JNDI
destroySubcontext et des opérations CosNamingCreate. La règle par défaut n'affecte pas de sujet à ce rôle.
Tableau 4. Méthodes d'interface et packages du rôle CosNamingDelete. Le tableau suivant répertorie les méthodes d'interface et les packages du rôle CosNamingDelete : Package Méthodes d'interface javax.naming Context.destroySubcontext org.omg.CosNaming NamingContext.destroy
- javax.naming
- Ce package génère l'exception javax.naming.NoPermissionException, qui mappe NO_PERMISSION de l'appel de méthode CosNaming vers NoPermissionException.
- org.omg.CosNaming
- Ce package génère l'exception org.omg.CORBA.NO_PERMISSION.
Les utilisateurs, les groupes ou les sujets spéciaux AllAuthenticated et Everyone peuvent être ajoutés aux rôles de nommage ou en être supprimés à partir de la console d'administration WebSphere Application Server à tout moment. Vous devez toutefois redémarrer le serveur pour que les modifications soient prises en compte. La meilleure méthode consiste à mapper des groupes ou un des sujets spéciaux et non plusieurs utilisateurs, vers des rôles de nommage car l'administration est simple à long terme. En mappant un groupe vers un rôle de nommage, l'ajout d'utilisateurs dans le groupe ou leur suppression du groupe se produit hors de WebSphere Application Server et il n'est pas nécessaire de redémarrer le serveur pour que la modification prenne effet.
Si un rôle de nommage particulier est attribué à un utilisateur et que cet utilisateur est membre d'un groupe auquel un rôle de nommage différent a été attribué, l'utilisateur dispose d'un accès très étendu entre le rôle qui lui est attribué et le rôle attribué à son groupe. Supposons que le rôle CosNamingRead est attribué à l'utilisateur MonUtilisateur et que le rôle CosNamingCreate est attribué au groupe MonGroupe. Si l'utilisateur MonUtilisateur appartient au groupe MonGroupe, il reçoit le rôle CosNamingCreate car l'utilisateur appartient au groupe MonGroupe. Si l'utilisateur MonUtilisateur n'appartient pas au groupe MonGroupe, il reçoit le rôle CosNamingRead.
Les règles d'autorisation CosNaming ne sont appliquées que lorsque sécurité administrative est activé. Lorsquesécurité administrative est activé, les tentatives d'effectuer des opérations CosNaming sans l'attribution du rôle correct provoquent une exception org.omg.CORBA.NO_PERMISSION à partir du serveur CosNaming.
Dans WebSphere Application Server, chaque fonction CosNaming n'est attribuée qu'à un seul rôle. C'est pourquoi, les utilisateurs qui disposent du rôle CosNamingCreate ne peuvent pas interroger l'espace de nom sauf si le rôle CosNamingRead leur est également attribué. Dans la plupart des cas, un créateur doit disposer de trois rôles : CosNamingRead, CosNamingWrite et CosNamingCreate. L'attribution de rôles CosNamingRead et CosNamingWrite pour l'exemple de créateur a été incluse dans le rôle CosNamingCreate. Dans la plupart des cas, les administrateurs WebSphere Application Server n'ont pas besoin de modifier les attributions de rôle pour chaque utilisateur ou groupe lorsqu'ils passent d'une version précédente à cette version.
Bien qu'il soit possible de réduire de manière considérable l'accès à l'espace de nom en modifiant la règle par défaut, cette opération peut entraîner des exceptions org.omg.CORBA.NO_PERMISSION inattendues lors de l'exécution. Généralement, les applications J2EE accèdent à l'espace de nom et l'identité est celle de l'utilisateur authentifié par WebSphere Application Server lors de l'accès à l'application J2EE. Sauf si le fournisseur d'applications J2EE communique clairement les rôles de nommage attendus, soyez vigilant lors de la modification des règles d'autorisation de nommage par défaut.