使用 CustomData 的多维数据集级安全性

发布于 2024-12-05 18:09:02 字数 1187 浏览 2 评论 0原文

我是 SSAS 新手,但被要求创建一个具有三个立方体的产品(现在将它们称为“A”、“B”和“C”)。另一个团队正在创建 Web 部件“A”、“B”和“C”来访问这些多维数据集,并且角色“A”、“B”和“C”决定哪些用户可以访问这些多维数据集。

我的问题

不能保证客户的 SSAS 服务器与 SharePoint 服务器位于同一个机器上,因此我们遇到了用户登录到 SharePoint 且 SP 未模拟该用户的问题。我们无法保证客户端会让我们安装 Kerberos 身份验证,或将 SharePoint 设置为受信任的站点,因此我们正在研究使用 CustomData 变量传递当前用户的 ID。

问题

然而,这导致了实现多维数据集访问安全性的问题。我是否

  1. 创建一个采用 CustomData 变量的“SharePoint”角色,然后授予(通过维度安全性?)对多维数据集的访问权限(通过维度的所有成员?)
  2. 创建一个“安全多维数据集”,封装谁有权访问什么内容,并让 Web 部件确定它是否“应该”具有访问权限,
  3. 而不是将安全性存储在事实表中的用户/多维数据集形式中,而是将其存储在维度形式的用户/成员中(我不喜欢这样,因为传入的数据位于 user/cube 中形式,并将其扩展到维度的成员会创建“不必要的”行)。

更多背景信息

目前,安全性排列在事实表中,即

|用户密钥 |安全项目密钥 |

其中 Personkey 链接回用户表,SecurityItemKey 当前链接到多维数据集列表(我们有一个可用的安全项表,以便用户可以轻松列出他们的选项并检查他们想要的内容)。

我目前正在尝试上面的选项 1,但是当我按照

Exists(
  {[Security Item].[Security Item Key].&[235]},
    StrToSet("{([User].[User].[User].[" +
            CustomData() + "])}"
    ),
    'Fact Security'
    )

维度安全性创建 MDX 时,我收到类似于“‘{2}’维度中的‘{1}’属性具有生成的维度”的错误安全表达式无效”。 我在查询中使用相同的 MDX,效果很好。

请注意,MDX 中未引用我添加的维度,我担心这是问题的一部分,但我还找不到任何说“是”或“否”的内容。

那么,我做错了什么,你建议采取什么不同的做法?

I'm new to SSAS, but have been asked to create a product with three cubes (call them "A","B", and "C" for now). Another team is creating web parts "A","B", and "C" to access these cubes, and there are roles "A","B", and "C" which determine which users can access the cubes.

My problem

The customer's SSAS server is not guaranteed to be on the same box as the SharePoint server, and so we have had issues with a user logging on to SharePoint, and SP not impersonating that user. We can't guarantee that the client will let us install Kerberos authentication, or set up SharePoint as a trusted site, and so we are investigating using the CustomData variable to pass in the ID of the current user.

Question

However, this leads to the question of implementing cube access security. Do I

  1. Create a "SharePoint" role which takes the CustomData variable, and then either grants (through dimension security?) access to the cube (through all members of a dimension?)
  2. Create a "Security cube", encapsulating who has access to what, and have the web part determine whether or not it "should" have access,
  3. Rather than store the security in a user / cube form in a fact table store it in a user / members of a dimension form (I don't like this, as the incoming data is in user / cube form, and expanding it out to members of a dimension creates "unnecessary" rows).

More background info

Currently the security is arranged in fact table that is

| UserKey | SecurityItemKey |

where Personkey links back to a user table, and SecurityItemKey currently links to a list of cubes (we have a security item table available so that users can easily list their options and check what they want).

I am currently trying option 1. above, but when I create MDX along the lines of

Exists(
  {[Security Item].[Security Item Key].&[235]},
    StrToSet("{([User].[User].[User].[" +
            CustomData() + "])}"
    ),
    'Fact Security'
    )

for a dimension security, I get errors along the lines of "The '{1}' attribute in the '{2}' dimension has a generated dimension security expression that is not valid".
I use the same MDX in a query, and it's just fine.

Note that the dimension I add this to is not referenced in the MDX, and I worry that this is part of the issue, but I can't find anything yet saying "yes" or "no".

So, what am I doing wrong, and what do you recommend doing differently?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

帅的被狗咬 2024-12-12 18:09:02

跟进 - 这就是我们所做的:

我们没有强制维度数据安全性来保护整个多维数据集,而是创建了一个由 SharePoint 进程查询的“安全”多维数据集,然后该多维数据集负责授予或拒绝访问权限。只有 SharePoint 用户有权访问此角色并有权访问所有多维数据集。

普通用户仍然可以通过单独的角色单独访问每个多维数据集。

因此,安全问题在于,有一个角色可以访问所有角色,但我们认为这是可以接受的,并且只需相信该角色的成员已正确分配。

Follow up - here's what we did:

Rather than forcing a dimension data security to secure an entire cube, we made a "Security" cube which is queried by the SharePoint process, which is then responsible for granting or denying access. Only the SharePoint user has access to this role with access to all cubes.

Normal users are still granted access to each cube individually through separate roles.

So, the security issue is that there is one role with access to all, but we felt that was acceptable, and just have to trust that the role's members are assigned appropriately.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文