When does Starter Groups and Starter Users of a BPMN get generated as authorizations?

Looking at: https://github.com/camunda/camunda-bpm-platform/blob/66def900cd57366ded1fb47e5f4ce9ff43801377/engine/src/main/java/org/camunda/bpm/engine/impl/bpmn/deployer/BpmnDeployer.java#L403-L422

It seems that identity links are generated, but do these translate to Authorizations?

The repositoryService.getIdentityLinksForProcessDefinition() method is marked at deprecated, and the javadoc indicates to use Authorizations. But Authorizations dont seem to be used by the engine…

Even the engine’s Unit Tests are using .getIdentityLinksForProcessDefinition().

So what is the logic going on here? From the view in the Admin there are no authorizations, and save goes for direct view on the Java api

Working on 7.10

It seems like the BPMN parser was never updated to actually support authorization generation… as

does not actually generate authorizations.

So this really seems to be a bug (at least a unfinished feature as the javadocs dictate that identity links for Startable By is deprecated, but authorizations are never created.

cc @thorben

So the first iteration of a fix for this was built with:

Plugin:

public class CamundaPlugin1 implements ProcessEnginePlugin {
    @Override
    public void preInit(ProcessEngineConfigurationImpl processEngineConfiguration) {
    }

    @Override
    public void postInit(ProcessEngineConfigurationImpl processEngineConfiguration) {
        System.out.println("Deploy Custom BPMN Deployer");

        // FInd the default bpmndeployer class in the Deployers list
        Deployer bpmnDeployer = processEngineConfiguration.getDeployers().stream()
                .filter(d -> d.getClass().equals(BpmnDeployer.class))
                .findFirst()
                .orElseThrow(IllegalStateException::new);

        // Generate the custom deployer which is overwriting the add authorization method
        Deployer customDeployer = new CustomDeployerWithAuths();

        // Copy properties was needed to have the same configurations (further review required)
        BeanUtils.copyProperties(bpmnDeployer, customDeployer);

        //Remove the default bpmn deployer as it will conflict with the custom deployer
        processEngineConfiguration.getDeployers().remove(bpmnDeployer);

        // Add the custom deployer
        processEngineConfiguration.getDeployers().add(customDeployer);

        // There are missing getters in the bpmnDeployer Class for the DefaultCacheFactory and the default cacheCapacity, so we recreate the values
        // If the deployment cache is not reset, then the authorizations are not set. So you MUST rebuild the cache.
        DeploymentCache cache = new DeploymentCache(new DefaultCacheFactory(), 1000);
        
        // Set the deployers link of the DeploymentCache to the current set of Deployers
        cache.setDeployers(processEngineConfiguration.getDeployers());
        processEngineConfiguration.setDeploymentCache(cache);
    }

    @Override
    public void postProcessEngineBuild(ProcessEngine processEngine) {
    }
}

and then we have the replacement of the Deployer:

public class CustomDeployerWithAuths extends CustomBpmnDeployer {

    @Override
    protected void addAuthorizationsFromIterator(Set<Expression> exprSet, ProcessDefinitionEntity processDefinition, ExprType exprType) {
        System.out.println("RUNNING AUTH!!!");
        if (exprSet != null) {
            for (Expression expr : exprSet) {

                AuthorizationManager authManager = getCommandContext().getAuthorizationManager();
                Authorization authorization = authManager.createNewAuthorization(1);
                authorization.addPermission(Permissions.CREATE_INSTANCE);
                authorization.setResourceId(processDefinition.getId());
                authorization.setResourceType(6);

                if (exprType.equals(ExprType.USER)) {
                    System.out.println("EXECUTING AUTH FOR USER");
                    authorization.setUserId(expr.toString());

                } else if (exprType.equals(ExprType.GROUP)) {
                    System.out.println("EXECUTING AUTH FOR GROUP");
                    authorization.setGroupId(expr.toString());
                }

                authManager.insert((AuthorizationEntity)authorization);
            }
        }
    }
}

NOTE: the “CustomBpmnDeployer” class that I am extending from is just a copy of the BpmnDeployer class with a single modification to make the ExprType Enum into a public so it can be used by the addAuthorizationsFromIterator method

...
    public enum ExprType {
        USER, GROUP;

    }
...

Todo:

  1. When a deployment is deleted, the Authorizations are not cleared.
1 Like

@thorben any pointer on if this should be considered a bug? Is the identity links method disucussed above considered still viable in subsequent releases? As it seems it’s still heavily used