Autorisation du client d'application

L'autorisation du client d'application consiste en des classes d'autorisation ObjectGrid, des mécanismes d'autorisation, une période de vérification des droits et une autorisation "accès réservé au créateur".

Pour eXtreme Scale, l'autorisation est accordée en fonction de l'objet et des droits du sujet. Le produit prend en charge deux sortes de mécanismes d'autorisation : le service JAAS (Java Authentication and Authorization Service) et l'autorisation personnalisée.

Classes d'autorisation ObjectGrid

L'autorisation est accordée en fonction des droits. Il existe quatre types de classes d'autorisation :
  • La classe MapPermission représente les autorisations d'accès aux données dans les mappes ObjectGrid.
  • La classe ObjectGridPermission représente les autorisations d'accès à ObjectGrid.
  • La classe ServerMapPermission représente les autorisations d'accès aux mappes ObjectGrid sur le serveur à partir d'un client.
  • La classe AgentPermission représente les autorisations de démarrage d'un agent sur le serveur.
Pour plus d'informations, voir Programmation d'autorisations client.

Période de vérification des droits

eXtreme Scale prend en charge la mise en cache des résultats de la vérification des droits d'accès aux mappes pour des raisons de performances. Sans ce mécanisme, lorsqu'une méthode, qui est répertoriée dans la liste des méthodes de votre classe d'autorisation, est appelée, l'environnement d'exécution appelle le mécanisme d'autorisation configuré pour autoriser l'accès. Lorsque cette période est définie, le mécanisme d'autorisation est appelé périodiquement. Pour la liste des méthodes de chaque classe d'autorisation, voir Programmation d'autorisations client.

Les informations relatives à l'autorisation des droits se fondent sur l'objet Subject. Lorsqu'un client essaie d'accéder aux méthodes, l'environnement d'exécution eXtreme Scale recherche l'objet Subject dans le cache. Si cet objet est introuvable, l'environnement d'exécution vérifie les droits qui lui sont accordés, puis stocke les droits dans un cache.

La période de vérification des droits doit être définie avant l'initialisation de la grille d'objets. Vous pouvez la configurer de deux manières différentes :

Vous pouvez utiliser le fichier XML ObjectGrid pour définir une grille d'objets ainsi que la période de vérification des droits. Dans l'exemple suivant, cette période est définie pour une durée de 45 secondes :
<objectGrids>
	<objectGrid name="secureClusterObjectGrid" securityEnabled="true"
	authorizationMechanism="AUTHORIZATION_MECHANISM_JAAS" 
	permissionCheckPeriod="45">
		<bean id="bean id="TransactionCallback"
className="com.ibm.websphere.samples.objectgrid.HeapTransactionCallback" />
...
</objectGrids>
Si vous souhaitez créer une grille d'objets à l'aide des API, appelez la méthode suivante pour définir la période de vérification des droits. Cette méthode peut uniquement être appelée avant l'initialisation de l'instance ObjectGrid. Elle s'applique uniquement au modèle de programmation eXtreme Scale local lorsque vous instanciez directement une instance ObjectGrid.
/**
 * This method takes a single parameter indicating how often you 
 * want to check the permission used to allow a client access. If the 
 * parameter is 0 then every single get/put/update/remove/evict call  
 * asks the authorization mechanism, either JAAS authorization or custom 
 * authorization, to check if the current subject has permission. This might be 
 * prohibitively expensive from a performance point of view depending on 
 * the authorization implementation, but if you need to have ever call check the 
 * authorization mechanism, then set the parameter to 0. 
 * Alternatively, if the parameter is > 0 then it indicates the number 
 * of seconds to cache a set of permissions before returning to 
 * the authorization mechanism to refresh them. This value provides much 
 * better performance, but if the back-end 
 * permissions are changed during this time then the ObjectGrid can 
 * allow or prevent access even though the back-end security 
 * provider was modified.
 * 
 * @param period the permission check period in seconds.
 */
void setPermissionCheckPeriod(int period);

Autorisation "accès réservé au créateur"

Avec l'autorisation "accès réservé au créateur", seul l'utilisateur (représenté par les objets Principal qui lui sont associés) ayant inséré une entrée dans une mappe ObjectGrid peut accéder (lecture, mise à jour, invalidation et suppression) à cette entrée.

Le modèle d'autorisation d'accès aux mappes ObjectGrid existant se fonde sur le type d'accès et non sur les entrées de données. En d'autres termes, un utilisateur dispose de droits d'accès d'un certain type (par exemple lecture, écriture, insertion, suppression ou invalidation) à toutes les données de la mappe ou ne détient aucun droit d'accès à aucune donnée. En revanche, eXtreme Scale n'autorise pas l'accès à certaines données seulement. Cette fonction constitue une nouvelle manière d'octroyer aux utilisateurs des droits d'accès aux entrées de données.

Dans un scénario où différents utilisateurs accèdent à différents jeux de données, ce modèle peut être utile. Lorsqu'un utilisateur charge des données à partir du stockage de persistance dans les mappes ObjectGrid, l'accès peut être autorisé par le stockage de persistance. Dans ce cas, il est inutile d'accorder une autre autorisation dans la couche de mappes ObjectGrid. Vous devez seulement faire en sorte que la personne qui charge les données dans la mappe peut y accéder en activant la fonction "réservé au créateur".

Valeurs des attributs en mode Réservé au créateur :
disabled
La fonction "accès réservé au créateur" est désactivée.
complement
La fonction "accès réservé au créateur" est activée et vient s'ajouter à l'autorisation d'accès aux mappes. En d'autres termes, les deux fonctions (autorisation d'accès aux mappes et fonction "accès réservé au créateur") sont opérationnelles. Vous pouvez donc limiter les opérations aux données. Le créateur ne peut par exemple pas invalider les données.
supersede
La fonction "accès réservé au créateur" est activée et remplace l'autorisation d'accès aux mappes. En d'autres termes, elle se substitue à cette autorisation, qui n'est plus opérationnelle.

Vous pouvez configurer le mode "accès réservé au créateur" de deux manières :

Avec un fichier XML :

Vous pouvez utiliser le fichier XML ObjectGrid pour définir une grille d'objets et choisir le mode disabled, complement ou supersede, comme dans l'exemple suivant :
<objectGrids>
    <objectGrid name="secureClusterObjectGrid" securityEnabled="true"	
	        accessByCreatorOnlyMode="supersede"
        <bean id="TransactionCallback"
              classname="com.ibm.websphere.samples.objectgrid.HeapTransactionCallback" />
    ...
</objectGrids>

A l'aide d'un programme :

Si vous souhaitez créer une grille d'objets à l'aide d'un programme, vous pouvez appeler la méthode suivante pour définir le mode "accès réservé au créateur". L'appel de cette méthode s'applique uniquement au modèle de programmation eXtreme Scale local lorsque vous instanciez directement l'instance ObjectGrid :
/**
 * Set the "access by creator only" mode.
 * Enabling "access by creator only" mode ensures that only the user (represented
 * by the Principals associated with it), who inserts the record into the map,
 * can access (read, update, invalidate, and remove) the record.
 * The "access by creator only" mode can be disabled, or can complement the
 * ObjectGrid authorization model, or it can supersede the ObjectGrid
 * authorization model. The default value is disabled:
 * {@link SecurityConstants#ACCESS_BY_CREATOR_ONLY_DISABLED}.
 * @see SecurityConstants#ACCESS_BY_CREATOR_ONLY_DISABLED
 * @see SecurityConstants#ACCESS_BY_CREATOR_ONLY_COMPLEMENT
 * @see SecurityConstants#ACCESS_BY_CREATOR_ONLY_SUPERSEDE
 *
 * @param accessByCreatorOnlyMode the access by creator mode.
 *
 * @since WAS XD 6.1 FIX3
*/
void setAccessByCreatorOnlyMode(int accessByCreatorOnlyMode);
Autre exemple : imaginez un scénario selon lequel une grille de données bancaires contient un compte de mappe ObjectGrid dont les deux utilisateurs sont Manager1 et Employee1. Les règles d'autorisation d'eXtreme Scale accordent tous les droits d'accès à Manager1, mais uniquement les droits d'accès en lecture à Employee1. Les règles JAAS d'autorisation d'accès aux mappes ObjectGrid sont représentées ci-dessous :
grant codebase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction" 
    Principal com.acme.PrincipalImpl "Manager1" {
    permission com.ibm.websphere.objectgrid.security.MapPermission 
        "banking.account", "all"
};
grant codebase "http://www.ibm.com/com/ibm/ws/objectgrid/security/PrivilegedAction" 
    Principal com.acme.PrincipalImpl "Employee1" {
    permission com.ibm.websphere.objectgrid.security.MapPermission 
        "banking.account", "read, insert"
};
Observez quelle incidence la fonction "accès réservé au créateur" a sur l'autorisation :
  • disabled Si la fonction "accès réservé au créateur" est désactivée, l'autorisation d'accès aux mappes reste inchangée. L'utilisateur "Manager1" peut accéder à toutes les données de la mappe "account". L'utilisateur "Employee1" peut lire toutes les données de la mappe et en insérer, mais il ne peut ni mettre à jour, ni invalider, ni supprimer ces données.
  • complement Si la fonction "accès réservé au créateur" est activée avec l'option "complement", les deux fonctions sont opérationnelles. L'utilisateur "Manager1" peut accéder aux données de la mappe "account", mais uniquement s'il les a chargées dans celle-ci. L'utilisateur "Employee1" peut lire les données de cette mappe, mais uniquement s'il les a chargées. (Il ne peut cependant ni mettre à jour, ni invalider, ni supprimer les données de cette mappe.)
  • supersede Si la fonction "accès réservé au créateur" est activée avec l'option "supersede", l'autorisation d'accès aux mappes n'est pas activée. L'autorisation "accès réservé au créateur" est alors la seule règle en vigueur. L'utilisateur "Manager1" détient les mêmes privilèges que ceux liés au mode "complement" : il peut accéder aux données de la mappe "account" uniquement s'il les a chargées dans la mappe. Toutefois, l'utilisateur "Employee1" détient maintenant les droits d'accès complet aux données de la mappe "account" s'il les a chargés dans la mappe. En d'autres termes, les règles d'autorisation définies dans les règles Java Authentication and Authorization Service (JAAS) ne sont pas appliquées.