Sécurité

Un client FlowerDocs, comme FlowerDocs GUI, nécessite d’être authentifié pour pouvoir communiquer avec FlowerDocs Core. Cette authentification est soumise sous la forme d’un jeton _JWT_s.


Un jeton est généré par FlowerDocs Core et est signé grâce à un HMAC calculé à partir de l’algorithme de hashage SHA-256 et d’une clé secrète.

A chaque requête reçue, FlowerDocs Core valide le jeton fourni à l’aide de la clé secrète.


Par défaut, cette clé secrète est générée au démarrage de FlowerDocs Core de manière aléatoire (sur 32 caractères). Il est conseillé de la définir dans le fichier core.properties grâce au paramètre token.key.


Un jeton est valide pendant 3600s (soit 60 minutes) à partir du moment où il a été généré. Pour changer cette durée de validité, le paramètre token.expiration.time (durée en secondes) peut être défini au niveau de FlowerDocs Core.


Dans certains cas, il peut être nécessaire d’inclure le mot de passe du compte utilisé dans le jeton généré. Cette configuration peut être activée à l’aide des paramètres :

  • Inclusion : token.password.include (valeur par défaut false)
  • Passphrase : token.password.passphrase
  • Iv : token.password.iv


La durée de vie du token doit être supérieure à celle de la session utilisateur pouvant être définie grâce à gui.session.timeout (secondes - valeur par défaut 1800)

Des utilisateurs propres à FlowerDocs peuvent être définis au niveau de FlowerDocs Core. Ces utilisateurs peuvent être utilisés comme compte de service, pour des administrateurs etc.

L’utilisateur system est le compte utilisé par les différentes applications FlowerDocs. Ses informations peuvent être configurées à l’aide des paramètres system.admin.username et system.admin.password.


Ce compte est utilisé par :

  • FlowerDocs GUI pour charger sa configuration
  • FlowerDocs Core pour exécuter les OperationHandlers
  • Le CLM pour gérer les scopes
  • Le client Java FlowerDocs simplifiant l’authentification auprès de FlowerDocs

Pour chacune de ces applications, il est conseillé de configurer le compte utilisé (un différent pour chaque application).


FlowerDocs Core permet de définir des comptes additionnels et leurs informations :

  • id : l’identifiant du compte
  • password : le mot de passe du compte
  • profiles : les profils (rôles, groupes, équipes) du compte

Ces comptes additionnels peuvent être configurés dans les fichiers core.properties et gui.properties tels que :

internal.realm.users[0].id=client1
internal.realm.users[0].password=<password>
internal.realm.users[0].profiles=ADMIN,ALL_USERS,JURIDIQUE,COMMERCE,MARKETING,COMPTABILITE


Les différents comptes définis au niveau de FlowerDocs Core peuvent être utilisés pour l’ensemble des scopes existants.

Il est déconseillé de stocker des mots de passe en clair dans des fichiers de configuration. Afin d’éviter de stocker les différents secrets en clair dans les fichiers core.properties et gui.properties, Flower fourni un mécanisme de chiffrement des secrets.


Afin d’indiquer à FlowerDocs que la valeur d’une propriété est chiffrée, elle doit être définie telle que ENC(<valeur chiffrée>). Une propriété chiffrée est déchiffrée au démarrage de l’application à l’aide de son secret principal (secret). Ainsi un chiffrement différent peut être défini pour chacune des applications.

L’application ne peut pas démarrer si une propriété, indiquée comme étant chiffrée, ne peut être déchiffrée.


Le chiffrement de propriété peut être réalisé de plusieurs façons à partir d’un secret principal :


<clm> encrypt --secret=<secret> --password=<propriété à chiffrer>

curl -X POST \
  <core>/rest/encrypt \
  -H 'token: <token>' \
  -d {{toEncrypt}}

Le secret de chacune des applications peut être défini de différentes manières :

  • comme variable d’environnement
  • comme propriété de la JVM
  • dans les fichiers core.properties et gui.properties (déconseillé)


Il est conseillé de définir, avec cette méthode, les propriétés token.key et system.admin.password à minima

LDAP par défaut

Cette partie concerne la configuration d’un annuaire par défaut pour une instance FlowerDocs.

Cette partie n’est pas à suivre dans le cas d’une configuration de l’annuaire à travers l’interface d’administration.

Accès

Pour configurer l’accès à l’annuaire d’entreprise, il nécessaire d’identifier le type nécessaire :

  • simple : LDAP simple de type Apache Directory Server ou OpenLDAP
  • ad : Microsoft Active Directory
  • ad-ds : Microsoft ADLDS
  • embedded : Apache Directory Server embarqué sur le port 3389

Le type d’annuaire peut ensuite être défini par application WEB :

  • Pour FlowerDocs GUI grâce à la propriété : gui.ldap.type
  • Pour FlowerDocs Core grâce à la propriété : ws.ldap.type

Exemple : Configuration d’un serveur embarqué

gui.ldap.type=embedded
ws.ldap.type=simple

Pour configurer l’accès à l’annuaire LDAP, il est nécessaire de renseigner la propriété ldap.

Propriété Valeur par défaut Description
ldap.bind.url ldap://localhost:389 Adresse de l’annuaire
ldap.bind.root Noeud de base dans la structure LDAP
ldap.base.dn Base de recherche des utilisateurs

Note : Dans le cas où l’annuaire LDAP est embarqué, il est nécessaire d’ajouter la propriété ldap.bind.root correspondant au noeud de base dans la strucutre LDAP.

Compte d’accès

Un compte de type admnistrateur doit être configuré permettant d’effectuer des actions :

  • recherche d’utilisateur
  • récupération d’utilisateur
  • authentification
  • etc.
Propriété Description
ldap.bind.dn Distinguished Name de l’utilistateur
ldap.bind.password Mot de passe de l’utilistateur

Attributs / mapping

Afin de récupérer (ou authentifier) des utilisateurs contre l’annuaire configuré, il faut également définir :

Propriété Description
ldap.attr.id Attribut permettant de récupérer l’identifiant d’un utilisateur

Exemples :

  • MS Active Directory : sAMAcountName
  • MS Active Directory LDS : uid
  • Apache Directory Server : uid

D’autres attributs utilisés pour le mapping d’utilisateur peuvent être définis :

Propriété Description
ldap.attr.display.name Attribut permettant de récupérer l’identifiant d’un utilisateur
ldap.attr.password Attribut permettant de récupérer le mot de passe d’un utilisateur

Administration du LDAP

Création d’un utilisateur

Depuis l’interface d’administration, il est possible de créer des utilisateurs avec un mot de passe par défaut. Pour cela, le mot de passe ne doit pas être obligatoire.

Propriété Description
ldap.default.password Mot de passe par défaut si aucun n’est défini lors de la création
ldap.user.password.mandatory Booléen définissant le critère obligatoire du champ mot de passe

La création d’utilisateurs ou de groupes ne peut être effectuée qu’à la racine du noeud d’accès au LDAP.

Exemple : Pour un MS Active Directory: <domaine>/<base DN>

Batch

Pour créer plusieurs utilisateurs en une seule requête, il est possible d’envoyer la requête :

  • Méthode : POST

    <UserBatch xmlns:ns2="http://flower.com/docs/domain/security" xmlns:ns3="http://flower.com/docs/domain/common">
    <users>
        <ns3:id>user_id</ns3:id>
        <ns2:displayName>My Display name</ns2:displayName>
        <ns2:credentialsExpired>false</ns2:credentialsExpired>
    </users>
    </UserBatch>

Exemples de configuration

LDAP embarqué

ldap.bind.url=ldap://localhost:3389
ldap.bind.root=dc=arondor,dc=com
ldap.base.dn=ou=employees
ldap.attr.id=uid
ldap.bind.dn=uid=fadmin,ou=Administrators,ou=employees,dc=arondor,dc=com
ldap.bind.password=okidoki

ADLDS

ldap.bind.url=ldap://ldap.company.com:389
ldap.bind.root=dc=arondor,dc=dev
ldap.bind.dn=CN=fadmin,OU=Demo,OU=FlowerDocs,DC=arondor,DC=dev
ldap.bind.password=okidoki
ldap.base.dn=OU=Demo,OU=FlowerDocs
ldap.attr.id=CN
ldap.attr.display.name=displayName

OpenLDAP

OpenLDAP requiert que le base DN utilisé

ldap.bind.url=ldap://ldap.company.com:389
ldap.bind.root=
ldap.base.dn=dc=arondor,dc=dev
ldap.attr.id=CN
ldap.bind.dn=CN=admin,DC=arondor,DC=dev
ldap.bind.password=okidoki
ldap.attr.display.name=displayName

Concept

OpenID Connect est un protocole permettant de déléguer l’authentification d’une application à une application tierce appelée Identity Provider (IDP). Basé sur le protocole OAuth 2 et son mécanisme de code d’autorisation, OpenId Connect est utilisé par FlowerDocs GUI afin de fournir à ses utilisateurs un mécanisme de Single Sign On.

Depuis la page d’authentification, les utilisateurs s’authentifient en sélectionnant un des Identity Providers affichés. Une fois authentifié au niveau de l’Identity Provider, l’utilisateur est redirigé vers une URL de redirection redirect_uri de FlowerDocs GUI avec un code d’autorisation généré par l’Identity Provider.

A partir de ce code d’autorisation, FlowerDocs GUI initialise la session HTTP utilisateur après avoir récupéré les id_token et access_token auprès de l’Identity Provider. Ensuite un jeton utilisateur propre à FlowerDocs est généré.

Prérequis

1. La clé secrète de FlowerDocs Core doit être partagée avec FlowerDocs GUI pour pouvoir utiliser ce mécanisme. Le partage de la clé secrète est nécessaire afin que FlowerDocs GUI puisse initialiser la session utilisateur en générant un jeton utilisateur valide (propriété token.key dans le fichier gui.properties).

2. Autorisation de l’URL de retrait dans l’Identity Provider

Configuration

La configuration d’un Identity Provider OpenId Connect peut être réalisée à travers la console d’administration FlowerDocs. Cette configuration est stockée dans des documents techniques de classe OAuthClientConfiguration. Les différents paramètres à renseigner sont stockés dans des tags.


Classe de documents OAuthClientConfiguration

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns5:DocumentClass category="DOCUMENT" active="false" technical="true" xmlns="http://flower.com/docs/domain/common" xmlns:ns2="http://flower.com/docs/domain/componentclass" xmlns:ns4="http://flower.com/docs/domain/tagclass" xmlns:ns3="http://flower.com/docs/domain/i18n" xmlns:ns6="http://flower.com/docs/domain/component" xmlns:ns20="http://flower.com/docs/domain/security" xmlns:ns5="http://flower.com/docs/domain/documentclass" xmlns:ns8="http://flower.com/docs/domain/search" xmlns:ns7="http://flower.com/docs/domain/acl" xmlns:ns13="http://flower.com/docs/domain/scope" xmlns:ns9="http://flower.com/docs/domain/file" xmlns:ns12="http://flower.com/docs/domain/reservation" xmlns:ns11="http://flower.com/docs/domain/task" xmlns:ns22="http://flower.com/docs/domain/folderclass" xmlns:ns10="http://flower.com/docs/domain/taskclass" xmlns:ns21="http://flower.com/docs/domain/virtualfolderclass" xmlns:ns17="http://flower.com/docs/domain/folder" xmlns:ns16="http://flower.com/docs/domain/document" xmlns:ns15="http://flower.com/docs/domain/report" xmlns:ns14="http://flower.com/docs/domain/workflow" xmlns:ns19="http://flower.com/docs/domain/fact" xmlns:ns18="http://flower.com/docs/domain/virtualFolder">
    <id>OAuthClientConfiguration</id>
    <ns2:data>
        <ACL>acl-admin</ACL>
    </ns2:data>
    <ns2:tagReferences tagName="ClientId" mandatory="true" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="ClientSecret" mandatory="true" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="AuthorizationGrantType" mandatory="false" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="RedirectUriTemplate" mandatory="true" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="Scope" mandatory="false" multivalued="true" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="AuthorizationUri" mandatory="true" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="TokenUri" mandatory="true" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="JwkSetUri" mandatory="false" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="UserInfoUri" mandatory="true" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="UserNameAttributeName" mandatory="true" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="MemberOfAttribute" mandatory="false" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="RegistrationId" mandatory="true" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="ClientName" mandatory="false" multivalued="false" technical="false" readonly="false" order="0" />
    <ns2:tagReferences tagName="Icon" mandatory="false" multivalued="false" technical="false" readonly="false" order="0" />
  	<ns2:tagReferences tagName="RegistrationOrder" mandatory="false" multivalued="false" technical="false" readonly="false" order="10">
        <ns4:descriptions language="EN">
            <ns3:value>Loading order</ns3:value>
        </ns4:descriptions>
        <ns4:descriptions language="FR">
            <ns3:value>Ordre de chargement</ns3:value>
        </ns4:descriptions>
        <ns4:pattern></ns4:pattern>
    </ns2:tagReferences>
	<ns2:displayNames language="EN">
		<ns3:value>oAuthClients configuration</ns3:value>
	</ns2:displayNames>
	<ns2:displayNames language="FR">
</ns5:DocumentClass>

Compte d’accès

La plupart des Identity Providers nécessitent une authentification pour pouvoir lancer le processus d’authentification. Pour configurer le compte utilisé par FlowerDocs pour contacter l’Identity Provider, il est nécessaire de valoriser les tags :

  • ClientId : l’identifiant représentant l’application cliente (ou Relying party) : FlowerDocs GUI
  • ClientSecret : le mot de passe associé à l’identifiant

Lien avec FlowerDocs

  • RedirectUriTemplate : template utilisé pour la génération du paramètre redirect_uri (la valeur doit être définie à {baseUrl}/login/oauth2/code/{registrationId})
  • Scope : les scopes OAuth 2.0 (à minima openid et email)
  • UserNameAttributeName : Nom de l’attribut à utiliser comme identifiant de l’utilisateur
  • RegistrationId : Identifiant unique du serveur d’autorisation
  • ClientName : Libellé du client
  • Icon : Icône Font Awesome à afficher sur la page de connexion
  • MemberOfAttribute : Nom de l’attribut permettant de fournir des groupes

Endpoints

Les différents endpoints requis par le protocole OpenId Connect doivent être configurés à l’aide des tags suivants :

  • AuthorizationUri : Endpoint d’autorisation de l’utilisateur
  • TokenUri : Endpoint permettant de récupérer les jetons
  • JwkSetUri : Endpoint utilisé pour accéder à la clé publique (JWK) du serveur d’autorisations permettant de valider les informations reçues
  • UserInfoUri : Endpoint exposant les attributs (ou claims) des utilisateurs

Pour plus de détails, consultez les spécifications OpenId Connect

Alfresco

Lorsque Alfresco est configuré comme référentiel de données de FlowerDocs, certaines étapes de configuration supplémentaires sont nécessaires. Le module flower-docs-alfresco-authentication-2.5.1.amp doit être déployé comme un module AMP Alfresco.

Ce module défini un nouveau sous-système d’authentification permettant d’authentifier un utilisateur existant à partir d’un jeton fourni par FlowerDocs suite à une authentification OIDC.

Il est ainsi nécessaire de définir ce sous-système d’authentification fdtoken:tokenauthenticator dans la configuration Alfresco via la propriété authentication.chain.

L’ajout de ce module requiert la définition de la clé secrète (token.key) utilisée par FlowerDocs afin de valider les jetons utilisateurs afin de les valider.


authentication.chain=fdtoken:tokenauthenticator,alfinst:alfrescoNtlm
token.key=<clé secrète>


Pour les versions antérieures à la versions 2.5.0, il est nécessaire d’ajouter les paramètres suivants à la configuration de FlowerDocs GUI :


oauth.config.class=fd:oauthClientConfiguration
oauth.config.clientId=fd:clientId
oauth.config.clientSecret=fd:clientSecret
oauth.config.authorizationGrantType=fd:AuthorizationGrantType
oauth.config.redirectUriTemplate=fd:RedirectUriTemplate
oauth.config.scope=fd:Scope
oauth.config.authorizationUri=fd:AuthorizationUri
oauth.config.tokenUri=fd:TokenUri
oauth.config.userInfoUri=fd:UserInfoUri
oauth.config.userNameAttribute=fd:UserNameAttributeName
oauth.config.memberOfAttribute=fd:MemberOfAttribute
oauth.config.registrationId=fd:RegistrationId
oauth.config.jwkSetUri=fd:JwkSetUri
oauth.config.clientName=fd:ClientName
oauth.config.icon=fd:Icon

Exemples


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:Document category="DOCUMENT" name="Google" xmlns="http://flower.com/docs/domain/common"
    xmlns:ns2="http://flower.com/docs/domain/component" xmlns:ns3="http://flower.com/docs/domain/document">
    <id>Google</id>
    <ns2:data>
        <ns2:classId>OAuthClientConfiguration</ns2:classId>
    </ns2:data>
    <ns2:Tags>
        <ns2:tags name="ClientId" readOnly="false">
            <ns2:value>***</ns2:value>
        </ns2:tags>
        <ns2:tags name="ClientSecret" readOnly="false">
            <ns2:value>***</ns2:value>
        </ns2:tags>
        <ns2:tags name="RedirectUriTemplate" readOnly="false">
            <ns2:value>{baseUrl}/login/oauth2/code/{registrationId}</ns2:value>
        </ns2:tags>
        <ns2:tags name="Scope" readOnly="false">
            <ns2:value>openid</ns2:value>
            <ns2:value>profile</ns2:value>
            <ns2:value>email</ns2:value>
            <ns2:value>address</ns2:value>
            <ns2:value>phone</ns2:value>
        </ns2:tags>
        <ns2:tags name="AuthorizationUri" readOnly="false">
            <ns2:value>https://accounts.google.com/o/oauth2/v2/auth</ns2:value>
        </ns2:tags>
        <ns2:tags name="TokenUri" readOnly="false">
            <ns2:value>https://www.googleapis.com/oauth2/v4/token</ns2:value>
        </ns2:tags>
        <ns2:tags name="JwkSetUri" readOnly="false">
            <ns2:value>https://www.googleapis.com/oauth2/v3/certs</ns2:value>
        </ns2:tags>
        <ns2:tags name="UserInfoUri" readOnly="false">
            <ns2:value>https://www.googleapis.com/oauth2/v3/userinfo</ns2:value>
        </ns2:tags>
        <ns2:tags name="UserNameAttributeName" readOnly="false">
            <ns2:value>sub</ns2:value>
        </ns2:tags>
        <ns2:tags name="RegistrationId" readOnly="false">
            <ns2:value>google</ns2:value>
        </ns2:tags>
        <ns2:tags name="ClientName" readOnly="false">
            <ns2:value>Google</ns2:value>
        </ns2:tags>
        <ns2:tags name="Icon" readOnly="false">
            <ns2:value>border-danger text-danger mdi mdi-google</ns2:value>
        </ns2:tags>
    </ns2:Tags>
</ns3:Document>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:Document category="DOCUMENT" name="Microsoft" xmlns="http://flower.com/docs/domain/common"
    xmlns:ns2="http://flower.com/docs/domain/component" xmlns:ns3="http://flower.com/docs/domain/document">
    <id>Microsoft</id>
    <ns2:data>
        <ns2:classId>OAuthClientConfiguration</ns2:classId>
    </ns2:data>
    <ns2:Tags>
        <ns2:tags name="ClientId" readOnly="false">
            <ns2:value>***</ns2:value>
        </ns2:tags>
        <ns2:tags name="ClientSecret" readOnly="false">
            <ns2:value>***</ns2:value>
        </ns2:tags>
        <ns2:tags name="AuthorizationGrantType" readOnly="false">
            <ns2:value>{baseUrl}/login/oauth2/code/{registrationId}</ns2:value>
        </ns2:tags>
        <ns2:tags name="RedirectUriTemplate" readOnly="false">
            <ns2:value>{baseUrl}/login/oauth2/code/{registrationId}</ns2:value>
        </ns2:tags>
        <ns2:tags name="Scope" readOnly="false">
            <ns2:value>openid</ns2:value>
            <ns2:value>profile</ns2:value>
            <ns2:value>email</ns2:value>
        </ns2:tags>
        <ns2:tags name="AuthorizationUri" readOnly="false">
            <ns2:value>https://login.microsoftonline.com/common/oauth2/v2.0/authorize</ns2:value>
        </ns2:tags>
        <ns2:tags name="TokenUri" readOnly="false">
            <ns2:value>https://login.microsoftonline.com/common/oauth2/v2.0/token</ns2:value>
        </ns2:tags>
        <ns2:tags name="JwkSetUri" readOnly="false">
            <ns2:value>https://login.microsoftonline.com/common/discovery/v2.0/keys</ns2:value>
        </ns2:tags>
        <ns2:tags name="UserInfoUri" readOnly="false">
            <ns2:value>https://graph.microsoft.com/oidc/userinfo</ns2:value>
        </ns2:tags>
        <ns2:tags name="UserNameAttributeName" readOnly="false">
            <ns2:value>sub</ns2:value>
        </ns2:tags>
        <ns2:tags name="RegistrationId" readOnly="false">
            <ns2:value>microsoft</ns2:value>
        </ns2:tags>
        <ns2:tags name="ClientName" readOnly="false">
            <ns2:value>Microsoft</ns2:value>
        </ns2:tags>
        <ns2:tags name="Icon" readOnly="false">
            <ns2:value>border-info text-info mdi mdi-microsoft</ns2:value>
        </ns2:tags>
    </ns2:Tags>
</ns3:Document>

Connexion automatique

Pour authentifier un utilisateur automatiquement à l’aide de ce mécanisme d’authentification, il est possible d’ajouter le paramètre sso=auto dans l’URL.

Avec ce paramètre, l’utilisateur, lorsqu’il accède à la page de connexion est automatiquement authentifié en utilisant OpenId Connect.

Les permissions

De manière générale, les permissions autorisées sont :

Permission Description
CREATE Autorise la création
READ Autorise l’accès en lecture
UPDATE Autorise la modification
DELETE Autorise la suppression
READ_HISTORY Accès à l’historique, au diagramme de suivi d’avancement d’un case ou d’un processus
READ_TASK_HISTORY Accès au suivi des tâches

Les permissions spécifiques aux documents :

Permission Description
READ_CONTENT Accès en lecture du contenu
UPDATE_CONTENT Modification du contenu
DOWNLOAD_CONTENT Téléchargement du contenu (visionneuse)
PRINT Impression (visionneuse)
CREATE_ANNOTATION Création d’annotation (visionneuse)
READ_ANNOTATION Lecture des annotations existantes (visionneuse)
BUILD_NEW_DOCUMENT Activation du découpage de document (visionneuse)

Les permissions spécifiques aux tâches :

Permission Description
APPROPRIATE S’approprier une tâche non assignée
APPROPRIATE_ALREADY_ASSIGNED S’approprier une tâche déjà assignée
ASSIGN Assigner une tâche à un utilisateur
APPLY_ANSWER Appliquer une réponse
UPDATE_CONTENT Modification des pièces jointes
DELETE_CONTENT Suppression d’une pièce jointe
READ_CONTENT Visualisation des pièces jointes

Les identités

Au sens FlowerDocs, une identité est soit un utilisateur, un groupe ou une équipe. La notion d’équipe a été introduite afin de centraliser et mutualiser la gestion des autorisations communes à une ou plusieurs identités.

ACL Proxy

Les objets de type ACLProxy permettent d’ajouter un aspect métier à la gestion des habilitations.

Un proxy est également un SecurityObject permettant de définir la sécurité à appliquer sur un composant. Il s’appuie sur des conditions pour déterminer quelle est l’ACL à appliquer sur un composant.

Exemple :

Pour une classe de documents Facture, le proxy suivant pourrait être utilisé :

  • si montant < 100€ : tout le monde a le droit de voir / modifier le document
  • si 100€ < montant : tout le monde a le droit de voir en lecture seule le document

Schéma

                      SecurityObject
                            |
         _______________________________
        |                               |
 AcessControlList  <-----            ACLProxy
        |                |              |
        | 1:N            |              | * rules : List<ACLRule>  ---
        |                |                                           |
AccessControlEntry       |                                           |
                         |                                           |
                         |           ACLRule  <-----------------------
                         |              |
                         |              | * conditions : List<String>
                         |____1:1_______| * aclId : Id

Règle par défaut

La définition d’une entrée sans condition dans un proxy permet de définir quelle est l’ACL à évaluer pour créer un composant depuis FlowerDocs GUI.

Rôles

Les rôles donnent accès à des fonctionnalités FlowerDocs à travers la notion d’équipe.

Pour affecter un rôle à un utilisateur :

  • créez une équipe dont l’identifiant est le nom du rôle
  • ajoutez des utilisateurs dans une équipe
Rôle Description
ADMIN Administre un scope
DOCUMENT_CREATOR Accède à l’onglet Insérer