Gestion de la sécurité

MRules fournit nativement un gestionnaire de sécurité permettant de limiter certaines actions accessibles par les règles.

Fonctionnement

Le principe général est assez simple. Un repository central (com.massa.util.security.MRulesSecurityManagers) permet d’enregistrer un ou plusieurs gestionnaire de sécurité (implémentation de com.massa.util.security.IMRulesSecurityManager), en général un par module.

Les managers de sécurité peuvent être déclarés de deux façons :

  • Programmatiquement, via l’API de repository.
  • Via la configuration, c.f. chapitres suivant pour la syntaxe.

Objectif

L’objectif n’est donc pas de contrôler ce que le développeur de l’application, qui a accès au code, peut faire : ce n’est pas le rôle de la solution MRules. Par contre, il s’agit bien de donner au développeur la possibilité de contrôler ce qu’il est possible de faire ou non par l’intermédiaire du moteur de règles.

Par exemple, il ne serait pas envisageable qu’un utilisateur puisse configurer un « ruleset » faisant un appel à « System.exit() ».

Configuration par défaut

Couche d’accès aux données

Nativement, si invoquée avec contrôle d’accès, la couche d’accès aux données interdit les appels statiques suivants :

  • System.exit
  • Runtime.*
  • MRulesSecurityManagers.*

Moteur de règles

Nativement, le moteur de règles appelle la couche d’accès aux données en activant le contrôle d’accès.

Egalement, les appels à des commandes systèmes (via l’addon d’action « EXEC ») sont interdits.

Surcharger la configuration par défaut

Via la configuration globale

Pour surcharger la configuration par défaut, il faut déclarer un nouveal gestionnaire de sécurité dans le fichier  « mrules-utils.xml ». Ce fichier doit avoir une priorité supérieure à celle de la configuration par défaut, qui est « 1 ».

Exemple pour surcharger la configuration de l’accès aux données, pour ajouter une nouvelle restriction sur un appel statique :

<?xml version="1.0" encoding="UTF-8" standalone='no' ?>
<!DOCTYPE mrulesconfig SYSTEM "mrules-utils.dtd">
<mrulesconfig priority="2">
  <securityManager class="com.massa.util.security.MRulesUtilsSecurityManager">    
    <prohibitedStaticAccesses>System.exit</prohibitedStaticAccesses>
    <prohibitedStaticAccesses>Runtime.*</prohibitedStaticAccesses>
    <prohibitedStaticAccesses>MRulesSecurityManagers.*</prohibitedStaticAccesses>
    <prohibitedStaticAccesses>MyForbiddenClass.*</prohibitedStaticAccesses>
  </securityManager>
</mrulesconfig>

Exemple pour surcharger la configuration du moteur de règles, pour autoriser les appels système :

<?xml version="1.0" encoding="UTF-8" standalone='no' ?>
<!DOCTYPE mrulesconfig SYSTEM "mrules-utils.dtd">
<mrulesconfig priority="2">
  <securityManager class="com.massa.mrules.security.MRulesBreSecurityManager">
    <authorizeSystemCalls>true</authorizeSystemCalls>
  </securityManager>
</mrulesconfig>

Programmatiquement

Créer une nouvelle instance de com.massa.util.security.MRulesUtilsSecurityManager ou de com.massa.mrules.security.MRulesBreSecurityManager, puis utiliser l’API de com.massa.util.security.MRulesSecurityManagers pour l’enregistrer dans le repository global.

Pour une exécution donnée

Il est envisageable de surcharger les managers de sécurités utilisés pour une exécution données. Ceci ne peut se faire que programmatiquement.

Il faut pour cela surcharger la méthode « getSecurityManager » du contexte de compilation / d’exécution.