Delegating Permissions to vCO Workflows and Publishing for Consumption

I needed to look into the possibilities around granting delegated access to vCO workflows and ways to consume them without necessarily using the standard vCO client. The general idea was to have one group of people authoring workflows and another group consume some of them.

vCO has the ability to delegate permissions to workflows and folders of workflows using users and groups; ideally you would have already setup vCO to use your AD for authentication so enabling this delegation via AD users and groups.

Each workflow or folder has a Permissions tab where users and groups can be added with different rights selectable; View, Inspect, Admin, Execute, Edit.

 

One thing to watch out for is that (at least) View Permissions need to be set right at the top of the tree for a user to be able to authenticate with the vCO (or other) client. The top level has a similar Permissions tab, however no Pencil style edit button like all of the levels further down.

Turns out it is hidden away in a context sensitive right-click set of options on the top level, Edit access rights…

Now we’ve figured that out, let’s take a scenario where we want to give an AD group access to run workflows in one folder, but not in another. We’ll use the AD group vCO_Users.

In the screenshot above vCO_Users have been given View and Inspect rights at the top level, which will filter all the way down. That will get our vCO_User authenticated, but not able to do too much.

On the folder JM-Dev vCO_Users have been given View, Execute and Inspect rights. Consequently, in the vCO client they are able to view and run the workflow, but not edit it - note the presence of the green Run button, but the Edit button is greyed out.

On the folder JM-Dev2 vCO_Users have only the View and Inspect rights which have filtered down from the top. Consequently, they can see the workflow, but neither run it nor edit it.

So we’ve got the permissions sorted for this example, but how about that requirement to not use the vCO client?

vCO has a built in web client, known as web operator. It is enabled by navigating to the Administer section of the client and then publishing the default weboperator.

Now we navigate to:

https://vcoserver.fqdn:8281/vco/vmo/weboperator/default.html

and login with some credentials of a member of the vCO_Users group

Now we can see the tree of workflows similar to the vCO client view

As this user we are able to run the workflow in the JM-Dev folder where we have the Execute permission:

but not the workflow in the JM-Dev2 folder which doesn’t have the Execute permission:

I found the web interface to be pretty basic, but possibly it’s worth evaluating if it might meet your needs.