在自定义 BCS/.net 类上实现安全性?
我正在实现一个自定义 BCS 模型以从后端系统获取数据。由于后端使用它自己的用户管理,我通过服务帐户访问它。
所有这些都运行良好,并允许我将数据提取到 SharePoint 中。然而,由于它是通过服务帐户传递的,因此每个人都可以访问它,这很糟糕。
谁能给我一些建议来实施哪种方法?后端没有给我 NT ACL,但我想知道我是否可以以某种方式“伪造”它们? (本质上说“这个 NT 组具有读取访问权限”就足够了)。
我知道用于搜索结果的 ISecurityTrimmer2,但理想情况下我想涵盖 BCS 模型内部的安全性,以便它也适用于外部列表。我想避免使用安全存储并将每个单独的用户映射到后端。
I'm implementing a custom BCS Model to get data from a backend system. As the backend uses it's own user management, I'm accessing it through a service account.
All of this works well and allows me to pull data into SharePoint. However because it's channeled through the service account, everyone can access it, which is bad.
Can anyone give me some tips which method to implement? The backend does not give me NT ACLs, but I wonder if I could just "fake" them somehow? (Essentially saying "This NT Group has Read Access" is good enough).
I am aware of ISecurityTrimmer2 for Search Results, but ideally I want to cover security inside the BCS Model so that it applies to external lists as well. I want to avoid using Secure storage and mapping each individual user to the backend.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
此处得到了答案。我可以将 BCS 模型中的一个字段设置为 WindowsSecurityDescriptorField,然后我可以在 BCS 方法中使用自定义代码来创建 ACL:
这效果很好,并且允许我在后端系统和 Active Directory 之间转换用户后创建自定义 ACL 。
如果将安全性作为 BCS 模型的一部分,我仍然有兴趣了解是否有人有其他方法。
Got an answer here. I can set a field in the BCS Model to be the WindowsSecurityDescriptorField and then I can use custom code in my BCS methods to create a ACLs:
This works well and allows me to create custom ACLs once I translated users between the backend system and Active Directory.
I'm still interested to hear if someone has another way if having security as part of the BCS Model.
如果您想避免使用 Secure Store,那么听起来您唯一的选择就是 PassThrough。问题是您不能使用 NTLM。您必须使用 Kerberos,因为 NTLM 不允许身份委派,因为您要将凭据从用户传递到 SharePoint 服务器再到外部系统。在使用 Kerberos 进行身份委托时,您需要为您的服务创建 SPN(服务主体名称),以便 AD 知道它可以委托身份。
对外部系统进行身份验证< /a>
请参阅使用 Kerberos 身份验证为您的 Web 应用程序创建服务主体名称 在本文中创建 SPN。
If you want to avoid Secure Store, it sounds like your only choice is PassThrough. The catch is that you cannot use NTLM. You must use Kerberos because NTLM does not allow for identity delegation since you are passing credentials from the user to the SharePoint server to the external system. In using Kerberos for identity delegation, you need to create a SPN (Service Principle Name) for your service so that AD knows that it is permitted to delegate identities.
Authenticating to Your External System
See Create Service Principal Names for your Web applications using Kerberos authentication in this article for creating a SPN.
我正在使用一种稍微不同的方法。如果您编写 .NET 对象代码以从外部系统检索数据,则可以访问 SPContext 对象来检查您所在的站点或哪个用户正在查询数据。在代码中,您可以使用该信息来过滤您喜欢的任何数据。
因此,SharePoint 网站上完全相同的外部列表实例可能会根据用户名或组成员身份为用户 A 返回 5 个结果,但为用户 B 返回 10 个结果。实施起来并不难,而且实际上效果很好。
查看 http:// /jsiegmund.wordpress.com/2010/05/19/creating-secured-bcs-objects-with-bcs-meta-man/。
I'm using a somewhat different approach. If you code .NET objects to retrieve the data from your external system, you can access the SPContext object to check on what site you're on, or which user is querying the data. In code, you can use that info to filter the data any what you like.
So the exact same instance of an External List on your SharePoint site might return 5 results for use A, but 10 results for user B based on username or perhaps group membership. Not that hard to implement and actually works pretty good.
Check out http://jsiegmund.wordpress.com/2010/05/19/creating-secured-bcs-objects-with-bcs-meta-man/.