Unified security

Cet article a pour objectif de documenter le fonctionnement de la sécurité unifiée. Aujourd’hui, les modules utilisant ce type de sécurité sont :

Workflow
Réservoirs de données
Studio
Agents
SSO

Récupération du Controller de sécurité

Depuis le module adéquat, vous pouvez récupérer ce controller via la méthode getSecurityController(). Cette méthode vous renverra un objet implémentant ISecurityController.

Info

L’interface ISecurityController intègre encore beaucoup de méthode deprecated, méthodes utilisées pour les modules utilisant encore l’ancienne sécurité.

Sur cet objet, vous pourrez alors effectuer :

Des tests de sécurité : checkPermission, hasPermission
Des ajouts, suppressions de droits : addPermission, removePermission
Des cassages d’héritages : breakInheritance

Info

Pour rappel, l’usage du ISecurityController pour ce qui est des tests de lecture sur des éléments SDK est quasiment superflu. En effet, la notion de IContext dans le SDK réalise elle-même des tests de sécurité implicites : je ne récupère que la liste des objets autorisés par mon contexte.

Structure de la sécurité

Les types de droits

Voici la liste des niveaux de droits applicables (ils sont présents dans l’interface IPermissionLevel).

Type de droits	Mapping dans le SDK	Description
Aucun	NO	Aucune permission
Lecture	READ	Droit de lecture
Modification	WRITE	Droit de modification
Propriétaire	OWNER	Droits de modification et de suppression
Contrôle total	GRANT	Droits de modification, de suppression et de modification des droits

Les options supplémentaires, associées aux droits

Voici la liste des options, en complément des niveaux de droits (ils sont présents dans l’interface IPermissionFlags).

Cette interface intègre des sous-interfaces, chacune intégrant des attributs différents et héritant de CommonPermissionFlags :

Interface	Flag(s)
CommonPermissionFlags	CREATE : création
AgentPermissionFlags	EXECUTE : exécution
WorkflowCatalogPermissionFlags	ALLOW_ACCESS : accès à l’application
WorkflowContainerPermissionFlags	LIFE_CYCLE_MANAGE : gestion du cycle de vie sur n’importe quel sous-workflow
WorkflowPermissionFlags
ViewPermissionFlags
WorkflowInstancePermissionFlags	DELETEGATE : suppression d’un document ABORT : annulation d’un document CHANGE_STATE : changement d’état sur d’un document
DatabasePermissionFlags
TablePermissionFlags

Manipulation de la sécurité

La bonne pratique

Pour manipuler la sécurité, il faut commencer par récupérer un ISecurityController sur l’objet sur lequel on souhaite travailler (c’est un ISecuritySupport).

Pour savoir quel objet passer ici, il faut se demander sur quel élément on souhaite éditer cette sécurité ?

Ensuite, il est possible de manipuler la sécurité en travaillant sur :

Un niveau de droits (IPermissionLevel)
Un ou plusieurs flags (facultatifs) (IPermissionFlag)

Exemples

Sur un groupe de processus

Ajout de droit

Sur un groupe de processus, ajouter un droit de modification des documents (options : création d’un document) :

IWorkflowModule iWorkflowModule = getWorkflowModule();

ICatalog iCatalog = ...;
IUser iUser = iWorkflowModule.getUserByLogin("sboirol");

ISecurityController iSecurityController = iWorkflowModule.getSecurityController(iCatalog);
iSecurityController.addPermission(iUser, IWorkflowInstance.class, IPermissionLevel.WRITE, IPermissionFlag.CREATE);

Sur un document de processus

Tester les droits

Sur un document de processus, tester si un utilisateur a les droits d’écritures avec l’option de création :

IWorkflowModule iWorkflowModule = getWorkflowModule();

IWorkflowInstance iWorkflowInstance = ...;
IUser iUser = iWorkflowModule.getUserByLogin("sboirol");

ISecurityController iSecurityController = iWorkflowModule.getSecurityController(iWorkflowInstance);
iSecurityController.checkPermission(iUser, IPermissionLevel.WRITE, IPermissionFlag.CREATE);

Affecter des droits

Sur un document de processus, affecter un droit de modification et d’action pour “Tout le monde” avec un filtre organisationnel et sans filtre de localisation :

ISecurityController iSecurityController = getWorkflowModule().getSecurityController(workflowInstance);
iSecurityController.addPermission(ISecurityController.EVERYONE, IPermissionLevels.WRITE, IScopeFilters.CHILDREN, organization, IScopeFilters.NONE, null, IPermissionFlags.WorkflowInstancePermissionFlags.CHANGE_STATE);

Sur un groupe

Deleting a permission

By using a security controller you may remove the rights of a user, a group on an object. The following example shows how to remove the modifications rights on the object “entity” of the group “users”.

public void security_removeRights( IDirectoryModule directoryModule, IOrganization entity, IGroup users ) throws DirectoryModuleException { 
	// Adjusting rights ISecurityController entitySecurity = directoryModule.getSecurityController( entity ); 
	// The group "Users" should not have the right to manage organizations of the entity. 
	entitySecurity.removePermission( users, IPermissionLevels.WRITE ); 
}

Manage security on custom objects

The development of security on external objects have been made to be able to restrict access to external data (Ex: read database tables).

Apply Visiativ Process security on custom objects

It’s possible to apply Visiativ Process security on a custom object by implementing the IChildSecuritySupport. The IChildSecuritySupport class will handle complex security for custom object (with inheritance).

The getSecurityParent() method will return the security parent of the object for security inheritance.

Example - Apply security on a local folder:

import com.axemble.vdoc.sdk.Modules;
import com.axemble.vdoc.sdk.exceptions.DirectoryModuleException;
import com.axemble.vdoc.sdk.exceptions.ModuleException;
import com.axemble.vdoc.sdk.exceptions.SDKException;
import com.axemble.vdoc.sdk.interfaces.IContext;
import com.axemble.vdoc.sdk.interfaces.IOrganization;
import com.axemble.vdoc.sdk.modules.IDirectoryModule;
import com.axemble.vdoc.sdk.supports.IChildSecuritySupport;
import com.axemble.vdoc.sdk.supports.ISecuritySupport;

import java.io.File;

public class CustomFolderObject implements IChildSecuritySupport {
    private String name;
    private String label;
    public File myFolder;
    public final static String SYSADMIN_LOGIN = "sysadmin";

    public CustomFolderObject(String name) {
        super();
        this.name = name;
        this.label = name + " Label";
        String pathname = "C:\\";

        myFolder = new File(pathname);

    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getLabel() {
        return label;
    }

    public void setLabel(String label) {
        this.label = label;
    }

    @Override
    public String getProtocolURI() {
        try {
            return Modules.getPortalModule().getProtocolURI(this);
        } catch (ModuleException e) {
            throw new SDKException(e);
        }

    }

    @Override
    public String getProtocolURI(boolean useNames) {
        try {
            return Modules.getPortalModule().getProtocolURI(this, useNames);
        } catch (ModuleException e) {
            throw new SDKException(e);
        }
    }

    @Override
    public ISecuritySupport getSecurityParent() {
        // In this situation, the parent is the organization by default.
        IDirectoryModule directoryModule = Modules.getDirectoryModule();
        IContext sysadminContext = directoryModule.getContextByLogin(SYSADMIN_LOGIN);
        IOrganization folderOrganization;
        try {
            folderOrganization = directoryModule.getOrganization(sysadminContext, "DefaultOrganization");
            return folderOrganization;
        } catch (DirectoryModuleException e) {
            throw new SDKException(e);
        }
    }
}

Source : https://wiki.myvdoc.net/xwiki/bin/view/Dev+Floor/ReferenceUnifiedSecurity