Tutoriel sur la sécurité Java SE - Etape 5

Après avoir authentifié un client, comme dans l'étape précédente, vous pouvez attribuer des privilèges de sécurité par le biais des mécanismes d'autorisation eXtreme Scale.

Avant de commencer

Assurez-vous d'avoir terminé l'étape Tutoriel sur la sécurité Java SE - Etape 4 avant de commencer cette tâche.

Pourquoi et quand exécuter cette tâche

Au cours de l'étape précédente, vous avez appris à activer l'authentification dans une grille eXtreme Scale. Par conséquent, aucun client non authentifié ne peut se connecter à votre serveur ni soumettre des requêtes à votre système. Toutefois, tous les clients authentifiés possèdent les mêmes permissions ou privilèges liés au serveur, tels que la lecture, l'écriture ou la suppression des données stockées dans les mappes ObjectGrid. Les clients peuvent également soumettre tout type de requête. Cette section explique comment utiliser l'autorisation eXtreme Scale pour attribuer différents privilèges aux utilisateurs authentifiés.

A l'instar de nombreux autres systèmes, eXtreme Scale adopte un mécanisme d'autorisation basé sur les permissions. WebSphere eXtreme Scale permet d'utiliser plusieurs catégories de permission, chacune étant représentée par une classe distincte. Cette rubrique décrit MapPermission. Pour la liste des catégories d'autorisations, voir Programmation d'autorisations client.

Dans WebSphere eXtreme Scale, la classe com.ibm.websphere.objectgrid.security.MapPermission représente les permissions liées aux ressources eXtreme Scale, notamment les méthodes des interfaces ObjectMap ou JavaMap. WebSphere eXtreme Scale définit les chaînes de permission suivantes pour accéder aux méthodes des interfaces ObjectMap et JavaMap :
  • read : accorde la permission de lire les données de la mappe.
  • write : accorde la permission de mettre à jour les données de la mappe.
  • insert : accorde la permission d'insérer les données dans la mappe.
  • remove : accorde la permission de supprimer les données de la mappe.
  • invalidate : accorde la permission d'invalider les données de la mappe.
  • all : accorde les permissions de lire, d'écrire, d'insérer, de supprimer et d'invalider.

L'autorisation est accordée lorsque le client invoque une méthode de l'interface ObjectMap ou JavaMap. Le moteur d'exécution eXtreme Scale vérifie différentes permissions de mappe pour différentes méthodes. Si les permissions nécessaires ne sont pas accordées au client, une AccessControlException se produit.

Ce tutoriel montre comment utiliser l'autorisation JAAS (Java Authentication and Authorization Service) afin d'autoriser plusieurs utilisateurs à accéder à la mappe.

Procédure

  1. Activation de l'autorisation eXtreme Scale. Pour activer l'autorisation sur l'ObjectGrid, vous devez définir l'attribut securityEnabled sur true pour cet ObjectGrid spécifique dans le fichier XML. L'activation de la sécurité sur cet ObjectGrid revient à activer l'autorisation. Utilisez les commandes suivantes pour créer un fichier XML ObjectGrid en activant la sécurité.
    1. Accédez au répertoire xml.
      cd objectgridRoot/xml
    2. Copiez le fichier SimpleApp.xml dans le fichier SecureSimpleApp.xml.
      cp SimpleApp.xml SecureSimpleApp.xml
    3. Ouvrez le fichier SecureSimpleApp.xml et ajoutez securityEnabled="true" au niveau de l'ObjectGrid comme indiqué dans la syntaxe XML ci-dessous :
      <?xml version="1.0" encoding="UTF-8"?>
      <objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   
          xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd" 
      		 xmlns="http://ibm.com/ws/objectgrid/config">
          <objectGrids>
              <objectGrid name="accounting" securityEnabled="true">
                  <backingMap name="customer" readOnly="false" copyKey="true"/>
              </objectGrid>
          </objectGrids>
      </objectGridConfig>
  2. Définition de la politique d'autorisation.
    Dans la section d'authentification pré-client, vous avez créé trois utilisateurs dans le fichier de clés : cashier (caissier), manager (gestionnaire) et administrator (administrateur). Dans cet exemple, l'utilisateur "cashier" dispose uniquement de la permission de lecture sur toutes les mappes. L'utilisateur "manager", quant à lui, dispose de toutes les permissions. L'autorisation JAAS est utilisée dans cet exemple. L'autorisation JAAS utilise le fichier de politique d'autorisation pour accorder les permissions aux principaux. Le fichier og_auth.policy est défini dans le répertoire de sécurité :
    og_auth.policy
    grant codebase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction"
        principal javax.security.auth.x500.X500Principal "CN=cashier,O=acme,OU=OGSample" {
        permission com.ibm.websphere.objectgrid.security.MapPermission "accounting.*", "read ";
    };
    
    grant codebase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction"
        principal javax.security.auth.x500.X500Principal "CN=manager,O=acme,OU=OGSample" {
        permission com.ibm.websphere.objectgrid.security.MapPermission "accounting.*", "all";
    };
    Remarque :
    • La base de code "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction" est une URL réservée spécifiquement à l'ObjectGrid. Toutes les permissions ObjectGrid accordées aux principaux utilisent cette base de code spécifique.
    • La première déclaration d'attribution accorde la permission de lecture ("read") de mappe à l'utilisateur principal "CN=cashier,O=acme,OU=OGSample", de sorte que le caissier dispose uniquement de la permission de lecture sur toutes les mappes de l'ObjectGrid accounting.
    • La deuxième déclaration d'attribution accorde toutes ("all") les permissions à l'utilisateur principal "CN=manager,O=acme,OU=OGSample", de sorte que le gestionnaire dispose de toutes les permissions sur toutes les mappes de l'ObjectGrid accounting.
    Vous pouvez désormais démarrer un serveur avec une politique d'autorisation. Le fichier de politique d'autorisation JAAS peut être défini à l'aide de la propriété -D standard : -Djava.security.auth.policy=../security/og_auth.policy
  3. Exécutez l'application.

    Après avoir créé les fichiers mentionnés ci-dessus, vous pouvez exécuter l'application.

    Démarrez le serveur de catalogue à l'aide des commandes suivantes. Pour plus d'informations sur le démarrage du service de catalogue, voir Démarrage d'un service de catalogue autonome.

    1. Accédez au répertoire bin : cd objectgridRoot/bin
    2. Démarrez le serveur de catalogue.
      • [Unix][Linux] startOgServer.sh catalogServer -clusterSecurityFile ../security/security.xml -serverProps ../security/server.properties -jvmArgs -Djava.security.auth.login.config="../security/og_jaas.config"
      • [Windows] startOgServer.bat catalogServer -clusterSecurityFile ../security/security.xml -serverProps ../security/server.properties -jvmArgs -Djava.security.auth.login.config="../security/og_jaas.config"

      Vous avez créé les fichiers security.xml et server.properties au cours de l'étape précédente de ce tutoriel.

      T

    3. Vous pouvez démarrer un serveur de conteneur sécurisé à l'aide du script suivant. Exécutez le script suivant à partir du répertoire bin :
      • [Unix][Linux] # startOgServer.sh c0 -objectGridFile ../xml/SecureSimpleApp.xml -deploymentPolicyFile ../xml/SimpleDP.xml -catalogServiceEndPoints localhost:2809 -serverProps ../security/server.properties -jvmArgs -Djava.security.auth.login.config="../security/og_jaas.config" -Djava.security.auth.policy="../security/og_auth.policy"
      • [Windows] startOgServer.bat c0 -objectGridFile ../xml/SecureSimpleApp.xml -deploymentPolicyFile ../xml/SimpleDP.xml -catalogServiceEndPoints localhost:2809 -serverProps ../security/server.properties -jvmArgs -Djava.security.auth.login.config="../security/og_jaas.config" -Djava.security.auth.policy="../security/og_auth.policy"
    Veuillez noter les différences suivantes concernant la commande de démarrage de serveur de conteneur précédente :
    • Utilisez le fichier SecureSimpleApp.xml au lieu du fichier SimpleApp.xml.
    • Ajoutez un autre argument -Djava.security.auth.policy pour définir le fichier de police d'autorisation JAAS sur le processus de serveur de conteneur.
    Utilisez la même commande que dans l'étape précédente du tutoriel :
    1. Accédez au répertoire bin.
    2. java -classpath ../lib/objectgrid.jar;../applib/sec_sample.jar com.ibm.websphere.objectgrid.security.sample.guide.SecureSimpleApp ../security/client.properties manager manager1

      L'application s'exécute correctement car l'utilisateur "manager" dispose de toutes les permissions sur les mappes de l'ObjectGrid accounting.

      Désormais, utilisez l'utilisateur "cashier" et non "manager" pour lancer l'application client.

    3. Accédez au répertoire bin.
    4. java -classpath ../lib/objectgrid.jar;../applib/sec_sample.jar com.ibm.ws.objectgrid.security.sample.guide.SecureSimpleApp ../security/client.properties cashier cashier1

    Vous obtenez l'exception suivante :

    Exception in thread "P=387313:O=0:CT" com.ibm.websphere.objectgrid.TransactionException: 
    rolling back transaction, see caused by exception
    	at com.ibm.ws.objectgrid.SessionImpl.rollbackPMapChanges(SessionImpl.java:1422)
     	at com.ibm.ws.objectgrid.SessionImpl.commit(SessionImpl.java:1149)
     	at com.ibm.ws.objectgrid.SessionImpl.mapPostInvoke(SessionImpl.java:2260)
     	at com.ibm.ws.objectgrid.ObjectMapImpl.update(ObjectMapImpl.java:1062)
     	at com.ibm.ws.objectgrid.security.sample.guide.SimpleApp.run(SimpleApp.java:42)
    	at com.ibm.ws.objectgrid.security.sample.guide.SecureSimpleApp.main(SecureSimpleApp.java:27)
    Caused by: com.ibm.websphere.objectgrid.ClientServerTransactionCallbackException: 
       Client Services - received exception from remote server:
         com.ibm.websphere.objectgrid.TransactionException: transaction rolled back, 
    			see caused by Throwable
            at com.ibm.ws.objectgrid.client.RemoteTransactionCallbackImpl.processReadWriteResponse(
                RemoteTransactionCallbackImpl.java:1399)
            at com.ibm.ws.objectgrid.client.RemoteTransactionCallbackImpl.processReadWriteRequestAndResponse(
                RemoteTransactionCallbackImpl.java:2333)
            at com.ibm.ws.objectgrid.client.RemoteTransactionCallbackImpl.commit(RemoteTransactionCallbackImpl.java:557)
            at com.ibm.ws.objectgrid.SessionImpl.commit(SessionImpl.java:1079)
            ... 4 more
    Caused by: com.ibm.websphere.objectgrid.TransactionException: transaction rolled back, see caused by Throwable
            at com.ibm.ws.objectgrid.ServerCoreEventProcessor.processLogSequence(ServerCoreEventProcessor.java:1133)
            at com.ibm.ws.objectgrid.ServerCoreEventProcessor.processReadWriteTransactionRequest
    					(ServerCoreEventProcessor.java:910)
            at com.ibm.ws.objectgrid.ServerCoreEventProcessor.processClientServerRequest(ServerCoreEventProcessor.java:1285)
    
            at com.ibm.ws.objectgrid.ShardImpl.processMessage(ShardImpl.java:515)
            at com.ibm.ws.objectgrid.partition.IDLShardPOA._invoke(IDLShardPOA.java:154)
            at com.ibm.CORBA.poa.POAServerDelegate.dispatchToServant(POAServerDelegate.java:396)
            at com.ibm.CORBA.poa.POAServerDelegate.internalDispatch(POAServerDelegate.java:331)
            at com.ibm.CORBA.poa.POAServerDelegate.dispatch(POAServerDelegate.java:253)
            at com.ibm.rmi.iiop.ORB.process(ORB.java:503)
            at com.ibm.CORBA.iiop.ORB.process(ORB.java:1553)
            at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2680)
            at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2554)
            at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:62)
            at com.ibm.rmi.iiop.WorkerThread.run(ThreadPoolImpl.java:202)
            at java.lang.Thread.run(Thread.java:803)
    Caused by: java.security.AccessControlException: Access denied (
       com.ibm.websphere.objectgrid.security.MapPermission accounting.customer write)
            at java.security.AccessControlContext.checkPermission(AccessControlContext.java:155)
            at com.ibm.ws.objectgrid.security.MapPermissionCheckAction.run(MapPermissionCheckAction.java:141)
            at java.security.AccessController.doPrivileged(AccessController.java:275)
            at javax.security.auth.Subject.doAsPrivileged(Subject.java:727)
            at com.ibm.ws.objectgrid.security.MapAuthorizer$1.run(MapAuthorizer.java:76)
            at java.security.AccessController.doPrivileged(AccessController.java:242)
            at com.ibm.ws.objectgrid.security.MapAuthorizer.check(MapAuthorizer.java:66)
            at com.ibm.ws.objectgrid.security.SecuredObjectMapImpl.checkMapAuthorization(SecuredObjectMapImpl.java:429)
            at com.ibm.ws.objectgrid.security.SecuredObjectMapImpl.update(SecuredObjectMapImpl.java:490)
            at com.ibm.ws.objectgrid.SessionImpl.processLogSequence(SessionImpl.java:1913)
            at com.ibm.ws.objectgrid.SessionImpl.processLogSequence(SessionImpl.java:1805)
            at com.ibm.ws.objectgrid.ServerCoreEventProcessor.processLogSequence(ServerCoreEventProcessor.java:1011)
            ... 14 more

    Cette exception se produit car l'utilisateur "cashier" ne dispose pas de permission d'écriture et ne peut donc mettre à jour le client de mappe.

    Votre système prend désormais en charge l'autorisation. Vous pouvez définir des politiques d'autorisation pour accorder différentes permissions à différents utilisateurs. Pour plus d'informations sur l'autorisation, voir Autorisation du client d'application.

Que faire ensuite

Effectuez l'étape suivante du tutoriel. Voir Tutoriel sur la sécurité Java SE - Etape 6.