Fine-grain access control for content (AAD- and Product-based)

[AnRei123]

Bug description

Currently it is very cool that the APIM portal allows to control which AAD group can see which API definitions in the DevPortal (list of APIs and list of API products is displayed user-specific).

But this isn´t sufficient for our use cases. Beyond this, we need to control also the visibility of page contents depending on the currently logged in user. In some cases, our internal app developers and our external partners should see different contents when navigating through the DevPortal pages depending on the AAD groups they are assigned to.

In the DevPortal there is currently no function that allows me to configure on navigation, page, block/section and on web widget level which AAD groups should be able to see the contents.
Thus, we do currently a bad compromise/workaround and add a tag to the blocks/sequences that are internal only or for partners only. And with the help of scripts, we remove these blocks during deployment to other environments depending on if external partners do have access to these environments or not. This is better than nothing, but this is not fitting our needs. It is a very poor and inflexible temporary approach.

Currently, we need to maintain for the same topics internal wikis and the DevPortal. This is fine for topics that are internal only. But for topics that are also covered in the DevPortal for our external app developers this is not efficient. Often, we would like to at least link to an internal wiki page for our internal developers. In other use cases, for our external partners, the information sometimes slightly varies.

Expected behavior

What we need is a role-/group-based variant management also for the further DevPortal pages and contents beside the dynamically listed APIs and API products.

This kind of control should be given on navigation, page, block/section and on widget level. A block/section or a widget should be only displayed for the configured target groups.

target group options should be:

• provide access for all AAD groups that are listed in the APIM instance: Contents and elements should be displayed to everyone
• provide access to no AAD group: editorial comments or for content that is in preparation and should not be deployed yet at all.
• provide access to all AAD groups except of the specified AAD groups: e.g. name of the AAD groups for external partners)
• provide access only to specified AAD groups: all relevant AAD groups that should see the contents need to be explicitly listed
• Apply same access rights as for the API product xyz: all AAD groups that have access to a dedicated API product are also able to see the contents on the pages.

Access rights should be inherited to the smallest piece inside a block/sequence including the media and it should be allowed to narrow further down on widget level.

There should be a possibility to preview the contents already in editor/designer mode for the already used target group options from a pulldown menu to test the results during writing or designing a new or updated page.

And there should be an indicator like a red point or a special frame color of the block/section or widget in the editor mode if the content will not be visible to all and has been restricted to a dedicated target group. When clicking the edit icon it should be possible to configure the access of the item.

If a page has been configured to be not visible to a target group, automatically the related navigation elements should be adapted as well.

The more contents we create, the more teams contribute, the partners join this topic became more and more important to us.

When could you come up with a solution to resolve this current limitation and inconsistency to apply the AAD access rights?

Remark: Later, there will be also the need to be able to deploy the contents locally (on-premise) for dedicated target groups. Thus, it is very important that I would then be also able to "download"/"backup" the data.json file and the required media files for a given AAD group configuration from my single editor source.

Is your portal managed or self-hosted?

Managed

[mikebudzynski]

@AnRei123, thanks for opening the feature request. Initially, we have been planning to implement page-level-only access controls to hide pages from unauthenticated users (so without fine-grain access control you described above), but we will reevaluate the feature based on your feedback. At this moment, we don't have an ETA for it.

Cross-referencing #533.

[mikebudzynski]

We're now working on defining the scope of a feature that will enable content access control in the developer portal. If you're interested in this improvement, please respond to our survey: https://aka.ms/apim/survey/devportal/accesscontrol - your feedback will help us better understand your requirements and design the right solution. The survey closes on Friday, November 5.

[mikebudzynski]

We're now working on defining the scope of a feature that will enable content access control in the developer portal. If you're interested in this improvement, please respond to our survey: https://aka.ms/apim/survey/devportal/accesscontrol - your feedback will help us better understand your requirements and design the right solution. The survey closes on Friday, November 5.

Just a reminder that the survey closes in 2 days.