问题标签 [iprincipal]

我对 ApiController 的单元测试使用一些辅助方法来实例化控制器：

我的问题是：如何设置控制器的用户属性？

我试过了：

但这也不起作用（resourcesController.User 属性保持为空）。

我正在尝试在我的应用程序中实现安全性。我在视觉工作室做了一个项目来测试这个。这行得通。这是让您了解我如何使用它的项目https://www.dropbox.com/s/4dyhmqe5kntbcvy/Principalpsermission.zip?v=0mcns

但是当我以相同的方式将这些东西应用到我的实际应用程序时，它在 mscorlib.dll 上失败（调用 Demand 方法时）。

所以我想这里可能有一个线索：http: //msdn.microsoft.com/en-us/library/9kc0c6st.aspx，但我不知道如何解决它。

代码：

安全控制器.cs

登录

本地设置控制器.cs

FrmMDi：即使登录用户的角色正确，也会出现错误

堆：

有人有想法吗？

提前致谢。

我对 ASP.NET Web API 还是很陌生。我目前正在研究基于 Web API 的新应用程序的身份验证部分，该应用程序是使用公司的一些库/某种框架开发的。

已经有一些 MVC 应用程序 - 他们使用基于表单的身份验证，并且他们没有使用 IPrincipal 来存储有关用户的信息，而是基于统一的方法，将数据保存在自定义 IUser 对象中（基本上保存在会话中）。Web API 应用程序将是无状态的（无会话），只是我将在身份验证 cookie 中添加一些与用户相关的信息（在 Application_PostAuthenticateRequest 中按请求检索）。

我有点犹豫是否将这些用户相关数据保存在 IPrincipal 的自定义实现中（我注意到这是一种做法），或者使用公司中其他应用程序的当前方法，利用 IUser - 由 Unity 提供服务，使用每个请求的生命周期经理。

您认为哪种方法更好？

我的 Web-API 服务中有一个DelegatingHandler，它根据提供的标头在 Thread.CurrentPrincipal 和 HttpContext.Current.User 上设置自定义 IPrincipal (ServicePrincipal)。这一切都是在调用SendAsync时完成的。

但是，当调用 get 进入 Controller 时，User 属性、HttpContext.User 和 Thread.CurrentPrincipal 都被神秘地设置为 RolePrincipal。

有谁知道我做错了什么，或者如何防止设置额外的主体？

谢谢，
基龙

假设在 ASP.NET Web 窗体应用程序中有一个相当普遍的用例，我应该在哪里检索我的主体 + 身份？

我知道通常有两种方法可以解决它：

• HttpContext.Current.User
• Thread.CurrentPrincipal

我推测 usingHttpContext会在某些边缘情况下运行当前上下文不存在（即HttpContext.Current == null）的风险，但我更经常看到使用它而不是Thread.CurrentPrincipal（我认为它更安全，因为它应该始终存在？）的代码。

为什么是这样？如果我选择其中一个，我会让自己陷入什么影响？

我猜测默认情况下 [Authorize] 属性会检查实现 IPrincipal 的非空对象？

我在正确的轨道上吗？

我的 MVC4 应用程序有一个自定义角色提供程序，它运行良好，它创建角色、检查角色存在、检查 IsUserInRole，但我的 [Authorize(Roles = "Admin")] 仍在使用默认的 System.Web.Security。 RolePrincipal.IsInRole(String role) 方法

我试图创建一个覆盖 IsInRole 方法的自定义 RolePrincipal，但我在为构造函数找到正确参数时遇到问题，并且不确定如何在 web.config 中设置它。代码如下：

}

我查看了 RolePrincipal 文档http://msdn.microsoft.com/en-us/library/system.web.security.roleprincipal.aspx，可以看到最基本的构造函数 RolePrincipal(IIdentity) 采用 IIdentity 的参数。由于我不确定它是什么，如何以及在哪里可以检索到它？webconfig 中是否需要进行其他更改？

我在从 AD 检索用户主体对象时遇到问题，如下所示：

都很正常吧？但是，在我的 Web 应用程序中，我从 中提取用户名User.Identity.Name，这为我提供了低级格式的用户名（域\用户名），而不是我的 UPN（用户名@域.com）。我的单元测试（1 和 2）通过 UPN 或 SAM IdentityTypes，但没有通过提供的下级名称（3），也不是不合格的用户名（4），使用 IdentityType.Name：

我可以在不对从中获得的下级名称进行任意字符串解析的情况下完成这项任务User.Identity.Name吗？我可以/应该只从用户对象中挖掘 SID 并使用它吗？

我很困惑为什么在 WebAPI 中需要设置 Principal，因为每个调用都是完全无状态的。由于每个呼叫都应该是完全无状态的，因此使用您记录的用户信息进行设置有什么好处和原因？

我的印象是一个登录的用户正在获取一个服务器创建的令牌，这是每次调用都需要发送和转发的密钥，直到用户决定注销或令牌过期？

在这种情况下“需要”设置 IPrincipal 的主要原因是什么？

有没有办法手动安全地序列化会话安全令牌？

我正在设置一个使用 Azure ACS 进行身份验证的 Web 应用程序。

我得到了索赔和委托人确定。现在我需要将整个事情传递给后端服务。最好的方法是什么？

1. 我应该序列化主体对象吗？并通过通道拦截手动恢复并设置它们？
2. 我可以以某种方式重用 SessionSecurityToken 吗？虽然一些后端服务可以使用像 msmq 这样的技术，所以会话和 cookie 的概念是没有实际意义的。为了统一起见，有没有办法仍然使用在 cookie 中设置的相同标记。如果有怎么办？
3. 我应该在后端服务上设置 WIF 吗？这似乎是个大麻烦。如果用户已通过身份验证，我想获取所有声明并将其传递，或者设置我自己的自定义角色管理器。
4. 我是否应该简单地创建一个票证，可以兑换一个缓存服务来检索所有这些信息？