Sécurité


    Plusieurs mécanisme permettent d’assurer l’authentification des utilisateurs (ou clients).

    Annuaire d’entreprise

    Flower supporte nativement le protocole LDAPv2 afin d’authentifier les utilisateurs.

    • récupération des groupes
    • attibuts spéficiques (mail, …)
    • changement de mot de passe

    Les annuaires qualifiés sont :

    • Microsoft Active Directory
    • OpenLDAP
    • Apache Directory Server

    OpenID Connect

    Afin d’intégrer Flower avec un système d’authentificaiton existant et mutualisé à travers le système d’information, Flower supporte le protocole OpenID Connect. Ce protocole permet d’authentifier un utilisateur auprès de la GUI Flower.

    Jeton

    Les APIs de Flower Core permettent la génération de jeton utilisateur. Le jeton généré peut ensuite être ré-utilisé afin d’authentifier des requêtes effectuées auprès du Core ou pour ouvrir Flower GUI.

    Plus d’information peuvent être consultées ici.


    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.


    Une équipe d’utilisateur est un regroupement, propre à Flower, d’utilisateurs.