Sécurité


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

    Annuaire d’entreprise

    FlowerDocs 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 FlowerDocs avec un système d’authentificaiton existant et mutualisé à travers le système d’information, FlowerDocs supporte le protocole OpenID Connect. Ce protocole permet d’authentifier un utilisateur auprès de FlowerDocs GUI.

    Jeton

    Les APIs de FlowerDocs 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 de FlowerDocs Core ou pour ouvrir FlowerDocs 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 FlowerDocs (composants, recherches sauvegardées, rapports, scopes, …). Ces objets de sécurité sont référencés sur les objets FlowerDocs.

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

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

    Ces objets de sécurité 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 celles-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ées selon l’ACL référencée.

    Trois types de conditions 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 composants 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’utilisateurs est un regroupement, propre à FlowerDocs, d’utilisateurs.