Home > Forum > General > Replace privileges on several workflow elements

Replace privileges on several workflow elements
0

Hi all!

We have an application which offers a portal for different customers. Each customer has different persons with individual logins (BPSId).

This list of persons can change from time to time, so we need to adjust rights on certain workflow elements (in different processes) to this specific list of persons.

I am wondering if it is possible (with Webcon Standard actions) to replace privileges on certain workflow elements in different processes.

Selection of workflow elements in different processes with SQL would be easy, but I did not find a Webcon action which actually replaces permissions,
which also includes removal of odd users, who should not have access any longer.

Users can also switch roles, which means from Read to Modify or vice versa.

We are considering to implement this in C# and REST API, but maybe there is an easier way to do this.

Many thanks in advance & best regards, Nik

MVP

Did you consider the creation of BPS groups for each customer rather than users?

For each customer you could have a group for modifying and one for read only permissions and use those on all your workflow elements you need to secure.
It would be easier to maintain the members of the groups, than changing permissions on multiple elements.

However, I don't know if there is a limit in the amount of BPS groups WEBCON BPS can maintain.

In reply to: Markus Jenni

Did you consider the creation of BPS groups for each customer rather than users?

For each customer you could have a group for modifying and one for read only permissions and use those on all your workflow elements you need to secure.
It would be easier to maintain the members of the groups, than changing permissions on multiple elements.

However, I don't know if there is a limit in the amount of BPS groups WEBCON BPS can maintain.

Hi Markus!

Thanks for the hint.

Yes, I considered this.

But this won't work when using (local) BPS groups, right?

I am considering using Azure AD groups and manage group members with Microsoft Graph API. Groups and Users should be synched by Webcon then.

Do you have any experience with assigning rights to Azure AD groups? Will Webcon detect the right group membership of current user (after sync of course)?

Thanks a lot in advance & best regards, Nik

MVP
In reply to: Nikolaus Schusser

Hi Markus!

Thanks for the hint.

Yes, I considered this.

But this won't work when using (local) BPS groups, right?

I am considering using Azure AD groups and manage group members with Microsoft Graph API. Groups and Users should be synched by Webcon then.

Do you have any experience with assigning rights to Azure AD groups? Will Webcon detect the right group membership of current user (after sync of course)?

Thanks a lot in advance & best regards, Nik

Local BPS groups you can compare with SharePoint Groups WEBCON BPS used ages ago.

We are using BPS groups in all of our projects because we are more flexible during developing/testing phase. For example, with AD groups it is almost impossible to test whether users have access to the right workflow elements / dashboard / reports or not. In addition, the Dev environment is very often not in the same active directory.

You also have the built-in actions to create and maintain the BPS groups. So, why not creating the groups when you create a customer?

We are using the privileged access groups feature of Azure AD to grant temporary admin permissions to one of our Azure AD integrated environments.
For this group we granted admin permission in WEBCON BPS.
After activating the group in Azure, we are forcing an immediate sync of this Azure AD group with a helper workflow we created.
Works like a charm.

In my opinion, when it is about permissions, WEBCON BPS does a nice job.

In reply to: Markus Jenni

Local BPS groups you can compare with SharePoint Groups WEBCON BPS used ages ago.

We are using BPS groups in all of our projects because we are more flexible during developing/testing phase. For example, with AD groups it is almost impossible to test whether users have access to the right workflow elements / dashboard / reports or not. In addition, the Dev environment is very often not in the same active directory.

You also have the built-in actions to create and maintain the BPS groups. So, why not creating the groups when you create a customer?

We are using the privileged access groups feature of Azure AD to grant temporary admin permissions to one of our Azure AD integrated environments.
For this group we granted admin permission in WEBCON BPS.
After activating the group in Azure, we are forcing an immediate sync of this Azure AD group with a helper workflow we created.
Works like a charm.

In my opinion, when it is about permissions, WEBCON BPS does a nice job.

Hi Markus!

Yes, you're right.

We will go with creation of BPS groups on creation of customer.

Assignment of a customer group to individual workflow elements belonging to this customer should be an easy task.

But what about synchronizing BPS group members, especially removing odd users, which have been deactivated or moved from one role to another (e.g. from write -> read)?

The problem still persists here, there is an add/remove users to/from BPS group action, but no actual replace users...