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 type d’objet de sécurité :

  • 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éfinis dans l’ACL référencé 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.

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.