如何在声明未映射到 AD 帐户的情况下执行 WIF/声明模拟？
我需要在 SharePoint 2010 中为声明用户执行搜索模拟。为了将其放在上下文中，我想首先说明如何使其与 Windows 帐户一起使用，然后讨论声明/WIF。
Windows 帐户
我可以使用以下方法为“经典”Windows 集成身份验证用户执行此操作：
WindowsImpersonationContext wic = null;
try
{
WindowsIdentity impersonatedUser = new WindowsIdentity("john.doe@mydomain");
wic = impersonatedUser.Impersonate();
// do impersonated work here...
// in my case this is a SharePoint KeywordQuery
}
finally
{
if (wic != null)
{
wic.Undo();
}
}
要使上述功能正常工作，模拟帐户必须与当前用户位于同一域中，并且我必须确保应用程序池所有者是：
- 域具有 Windows 2003 或更高版本“域功能级别”的域中的帐户
- 在本地计算机上具有“充当操作系统的一部分”权限
- 在本地计算机上具有“身份验证后模拟客户端”权限
（注意：如果有人可以弄清楚如何解决当前帐户必须与模拟帐户位于同一域中的问题，我洗耳恭听。）
索赔帐户
我想对索赔/WIF 帐户执行相同的操作。这些帐户不一定与 AD 帐户关联（我需要假设它们不是）。
有没有办法告诉 STS 我想模拟某个特定帐户，并让它为我提供该帐户的适当令牌？我不会拥有我所冒充的用户的密码。
引用 SharePoint Brew 我必须处理在 SharePoint Web 前端 (WFE) 上运行的代码，该前端通过 WCF 调用来调用查询处理器。我希望 WCF 调用位于模拟用户的上下文中。
WFE (Server1) 搜索 Web 部件与服务应用程序代理通信。关联的搜索服务应用程序代理调用本地 STS 来获取用户的 SAML 令牌。收集 SAML 令牌后，搜索服务应用程序代理就会通过 WCF 调用来调用运行查询处理器的服务器。我将此服务器称为“服务器 2”。服务器 2 接收传入请求并根据其本地 STS 验证 SAML 令牌。一旦经过验证，服务器 2 将连接到各个组件以收集、合并和安全调整搜索结果。服务器 2 将修剪后的搜索结果发送回服务器 1，然后将其呈现给用户。
更多的研究引导我查看 ActAs 和 OnBehalfOf。我相信我想使用 OnBehalfOf，但我不确定这两者是否有效。下面列出了我找到的一些参考资料。任何指导表示赞赏。
I need to perform search impersonation in SharePoint 2010 for Claims users. To put this in context, I would like to first state how I get this to work with Windows accounts and then discuss Claims / WIF.
Windows Accounts
I can do this for "classic" Windows Integrated Authenticated users using:
WindowsImpersonationContext wic = null;
try
{
WindowsIdentity impersonatedUser = new WindowsIdentity("john.doe@mydomain");
wic = impersonatedUser.Impersonate();
// do impersonated work here...
// in my case this is a SharePoint KeywordQuery
}
finally
{
if (wic != null)
{
wic.Undo();
}
}
To get the above to work the impersonated account has to be in the same domain as the current user and I have to make sure that application pool owner is:
- A domain account in a domain that has a "domain functional level" of Windows 2003 or greater
- Has "act as part of the operating system" privilege on the local box
- Has "impersonate a client after authentication" privilege on the local box
(Note: if anyone can figure out how to get around the issue where the current account must be in the same domain as the impersonated account I am all ears.)
Claims Accounts
I would like to do the same with Claims / WIF accounts. These accounts are not necessarily associated with AD accounts (I need to assume they are not).
Is there a way to tell the STS that I want to impersonate a particular account and for it to give me the appropriate token for that account? I won't have the password of the user I am impersonating.
Quoting SharePoint Brew I have to contend with my code which runs on a SharePoint web front end (WFE) that calls a Query Processor via a WCF call. I want that WCF call to be in the context of the impersonated user.
The WFE's (Server1) search web part talks to service application proxy. The associated search service application proxy calls the local STS to get a SAML token for the user. Once SAML token is collected, the search service application proxy then calls a server running the Query Processor via WCF call. I'll call this server, "Server 2". Server 2 receives the incoming request and validates the SAML token against its local STS. Once validated, Server 2 connects to various components to gather, merge, and security trims search results. Server 2 sends the trimmed search results back to Server 1 which are then presented to the user.
A little more research is leading me towards looking at ActAs and OnBehalfOf. I believe I would want to use OnBehalfOf, but I'm not certain that either would work yet. Some references I have found are listed below. Any guidance is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我花了几个月的时间试图解决这个问题，在与 Microsoft SharePoint 和 WIF 工程师长时间合作后得出的结论是这是不可能的。看来这个问题基本上就是柯克所提到的。当使用声明创建模拟会话（例如，创建 SPClaim 并转换为 SPUser）时，SharePoint 实际上并未创建完全模拟的会话。创建的会话实际上只能由对象模型理解。这意味着，当您走出 Web 应用程序的边界并进入搜索时，您实际上是在执行双跳，因为您进入了另一个应用程序域/进程空间。
我尝试做一些类似于 eppesuig 建议的事情，但无法让它发挥作用。 也许如果您编写了一个全新的 STS，可以生成 SharePoint 接受的可信声明令牌，那么您也许可以使用 ActAs 令牌来解决此问题（SharePoint 绝对不会接受 OnBehalfOf 令牌）。然而，这样做的安全影响相当令人担忧。理论上它应该可行，但事实证明让自定义 STS 和 SharePoint 混合/信任超出了我的能力。不过，我很乐意看到其他人尝试一下。
I spent several months working on trying to solve this problem and after spending a long time working with Microsoft SharePoint and WIF engineers came to the conclusion that this is not possible. It appears that the issue is basically what Kirk alludes to. When creating an impersonated session using Claims (e.g. creating an SPClaim and converting into a SPUser), SharePoint is not actually creating a completely impersonated session. The session that is created is really only understood by the object model. That means that when you step outside of the boundary of the web application and into search you are effectively performing a double hop because you stepping into another application domain/process space.
I tried to do something similar to what eppesuig suggests and could not get it to work. Perhaps if you wrote a whole new STS that could generate a trusted claim token that SharePoint would accept then you might be able to work around this using the ActAs token (SharePoint absolutely will not accept the OnBehalfOf token). However, the security implications of doing that are rather concerning. Theoretically it should work but getting the custom STS and SharePoint to intermingle/trust proved to be outside of my ability. I would love to see someone else try it, though.
据我了解，您不能直接使用除您自己以外的任何其他身份。如果您想使用像 OnBehalfOf 这样的功能，您需要一个能够处理委托的 STS。因此，STS 将检查您的身份，然后允许使用委托身份。
From what I understand, you cannot use directly any other identity but yours. If you want to use function like to OnBehalfOf, you need an STS that is able to handle delegation. so the STS will check your identity and then permit to use delegated identities.