Autorisation

Sécuriser votre application


Le rôle d’un objet de sécurité est de gérer les différentes permissions sur les objets dans Flower (composants, recherche sauvegardées, rapports, scope, …). Ces objets de sécurité sont référencés sur les objets Flower.

Au sein de l’application, nous définissons deux types d’objets de sécurités :

  • Liste de contrôle d’accès (ACL)
  • Proxy

Ces objets de sécurités permettent d’autoriser (ou d’interdire) une identité à effectuer une action.

Les objets de sécurité

Liste de contrôle d’accès (ACL)

Une liste de contrôle d’accès contient une ou plusieurs entrées de contrôle d’accès (ACE).

Dans chaque entrée, les différentes permissions sont définies pour un ensemble d’identités (utilisateur, groupe, équipe).


Par exemple, quand un utilisateur veut accéder en lecture à un composant, l’application va évaluer la permission de lecture en fonction de l’ACL portée par le composant.


Si l’utilisateur n’appartient à aucune identité définie dans l’ACL référencée par un composant, il est considéré qu’il n’a pas de droit d’accès à ce composant.

Les classes de composants portent une ACL qui est appliquée par défaut à la création d’un composant de cette classe. Cette ACL peut être modifiée plus tard par le biais d’intégration.

Ordre des entrées de contrôles d’accès (ACE)

L’ordre de définition des ACE est important car il correspond à l’ordre d’évaluation de celle-ci. La première entrée correspondant à l’utilisateur, un de ses groupes, une de ses équipes ou *, sera celle utilisée pour évaluer les différentes permissions de l’utilisateur pour un composant.


Par exemple, si la première entrée a pour identité * permettant de voir le composant et que la deuxième a pour identité l’identifiant de l’utilisateur X ne permettant pas de voir le composant, l’utilisateur pourra voir ce composant.

En inversant les deux entrées de l’ACL, tous les utilisateurs pourront voir le composant sauf cet utilisateur X.

Proxy d’ACL

Un proxy permet de définir une sécurité dynamique en fonction d’une ou plusieurs règles.

Chaque règle correspond à une liste de conditions et un identifiant d’ACL. Si toutes les conditions d’une règle sont satisfaites, les permissions de l’utilisateur sont déterminé selon l’ACL référencée.

Trois types de condition sont supportés par l’application :


Exemple

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ACLProxy name="Acl proxy for document" xmlns="http://flower.com/docs/domain/acl" xmlns:common="http://flower.com/docs/domain/common">
	<common:id>acl-proxy-document</common:id>
	<rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ACLConditionalRule">
		<conditions>${user.authorities}.contains("DSI")</conditions>
		<conditions>${tags.TypeCourrier}==Resiliation</conditions>
		<aclId>acl-courrier-entrant</aclId>
	</rules>
	<rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ACLConditionalRule">
		<conditions>${user.authorities}.contains("COMPTABILITE")</conditions>
		<conditions>${data.classid}==CourrierEntrant</conditions>
		<aclId>acl-courrier-entrant</aclId>
	</rules>
	<rules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ACLConditionalRule">
		<conditions>!${user.authorities}.contains("JURIDIQUE")</conditions>
		<conditions>${tags.TypeCourrier}!=Contrat</conditions>
		<conditions>${tags.TypeCourrier}!=Resiliation</conditions>
		<aclId>acl-courrier-entrant</aclId>
	</rules>
</ACLProxy>



Tout comme les ACLs, si aucune des règles n’est satisfaite, il est considéré que l’utilisateur n’a pas de droit d’accès au composant.

Association d’un objet de sécurité

Un objet de sécurité est associé à un objet à travers son champ ACL. Ce champ ne porte que l’identifiant de l’ACL ainsi une ACL peut être définie sur plusieurs composants afin de fournir la possibilité de gérer des politiques de sécurité communes à des ensembles de composant.

L’ACL référencée, par exemple sur un composant, sera utilisée pour déterminer si un utilisateur est autorisé ou non à effectuer une action sur celui-ci.


La création d’un composant est un cas particulier. En effet, celui-ci n’existant pas encore, c’est l’ACL définie au niveau de la classe de composant qui est évaluée. Ainsi afin d’autoriser un utilisateur à créer un composant, il est nécessaire qu’il possède la permission CREATE sur l’ACL référencée au niveau de sa classe.