Azure Analysis Services (AAS) Cube Roles: How to grant 2 levels of access, without having overlapping users, who thus get the lower level of access?

Viewed 37

Situation is:

We have an AAS cube. We want some users to have access to everything, and some to have limited access. Am currently doing this via roles:

  • [Role- All Access]: Has access to everything. Very limited number of users; hand curated by the business
  • [Role- Limited Access]: Has a few tables restricted. Many users; business has ~10 existing security groups whose members should have this access.

This issue is security is reductive.

If someone is a member of both [Role- All Access] and one of the security groups that rolls up to [Role- Limited Access], that user ends up with Limited Access. At least the way I know to write the roles.

My first thought was to do add an single security group to each role:

  • [Role- All Access]: Gets [Security Group, All Access], which itself is hand curated
  • [Role- Limited Access]: Gets [Security Group, Limited Access]. This ones gets those 10 security group nested in it. But do this as a Dynamic User AAD Security Group, and exclude any one who is a member of [Security Group, All Access], via the new memberof property - but from what I read:

https://identity-man.eu/2022/06/07/using-the-new-azure-ad-dynamic-groups-memberof-property/

You can’t use other operators with memberOf (i.e. you cannot create a rule which states member Of group A can’t be in Dynamic group B).

So that doesn't work.

I may be thinking about this the entirely wrong way as well (neither AAS nor dynamic security groups are things I know much about). Thoughts?

EDIT: Maybe the way I wrote the role, is causing security to be reductive? If security were not reductive, that would make it easy.

{
"create": {
"parentObject": {
  "database": "redacted"
},
"role": {
  "name": "Role - Limited Access",
  "modelPermission": "read",
  "members": [
    {
      "memberName": "obj:blablaSecurityGroupGUID",
      "identityProvider": "AzureAD"
    }
  ],
  "tablePermissions": [
    {
      "name": "FACTGeneralLedger",
      "metadataPermission": "none"
       }
     ]
   }
  }
 }
1 Answers

Somehow having the [Role- All Access] as read and process was screwing something up. Switching it to just read, and the security switched back to additive.

Related