我使用Windows身份验证的ASP.Net MVC应用程序,我检查组成员对控制器操作的安全性。
简单,因为它的声音,我发现可以解决我遇到的问题没有其他问题。
第一尝试:[授权]
经典的方法是简单地拍一个Authorize
的控制器操作数据注解属性和去镇:
[Authorize(Roles = @"domain\groupName1")]
没有骰子。 提示我输入凭据。 通常,这意味着什么是错的与Windows身份验证的配置,但它是建立罚款:(1) HttpContext.User
是一个WindowsPrincipal
对象,和(2)我证实了另一种已知的组名的作品。
第二次尝试:IsInRole()
采取下一步是去一个更老式的路线和使用IPrincipal.IsInRole()
并再次,一个返回false
,其他的true
。
var wp = (WindowsPrincipal)User;
// false
var inGroup1 = wp.IsInRole(@"domain\groupName1");
// true
var inGroup2 = wp.IsInRole(@"domain\groupName2");
难倒...所以我打了我的系统书呆子,我们仔细检查了一切。 用户是一组成员? 是。 集团名称拼写是否正确? 是。 下一步是抽丝的SID。
第三次尝试:搜索身份的集团回收
在我的控制器我检查WindowsIdentity
并通过集团回收的麻烦组的SID看看:
var wi = (WindowsIdentity)wp.Identity;
var group = wi.Groups.SingleOrDefault(g => g.Value == "group1-sidValue");
该group
变量是SecurityIdentifier
对象。 因为它是不为空,我们可以肯定的是该当前用户是,无论是所述组的成员[Authorize()]
或IsInRole()
尝试失败确认。
第四次尝试:DirectoryServices.AccountManagement
在这一点上,我要坚果和添加参考AccountManagement的API。 我搜索域上下文GroupPrincipal
按名称和SID:
var pc = new PrincipalContext(ContextType.Domain, "domain");
var gp1byName = GroupPrincipal.FindByIdentity(pc, "groupName1")
var gp1bySid = GroupPrincipal.FindByIdentity(pc, IdentityType.Sid, "group1-sidValue");
这两个组的主要变量是成熟与同一个对象,并通过我的手表变量校长核实Members
集合包含一个UserPrincipal
具有相同的SID与当前对象WindowsPrincipal
上HttpContext
。
题:
在地狱有什么我错过了吗? 为什么这两个角色检查,当它是清楚和明白,通过对象的探索用户是该给定组的有效成员的方法失败?
事实上,一组检查罚款和其他似乎并不在这一点上最奇怪的一部分。