我正在尝试将Identity用于我正在开发的新应用程序。关于它的最少可用信息使得它很难理解。
基于我对身份的理解，我可以创建角色(即Admin, Super User, Users…)，并且对于控制器中的每个动作，我可以限制角色是否可以访问该动作。对于典型的应用程序，这是一种不错的方法。但是在我的应用程序中，我需要对访问级别进行更深层次的控制。我需要能够有更多的控制，而不是基于角色的授权。
在一个典型的应用程序中，我可以在控制器中的动作方法[Authorize(Roles = "Admin")]上添加它，并且只有具有Admin的人才能够被授权访问它。
但是，我希望能够添加个人权限，不确定是否可以使用Identity。(也许与索赔有关?)
这是我的想法，我希望能够做这样的事情
// In a Razor view I want to be able to do this
// Note: HasPermission is not real method, but is something I am posting
// to explain what I am looking for
if(User.HasPermission("Edit Account")){
// Show the Edit button
}
if(User.HasPermission("Add Account")){
// Show the Add Button
}
然后，在我想要做的动作方法中能够做这样的事情。
[Authorize( HasPermission = "Edit Account")]
public ActionResult Edit()
{
// Handle the edit
}
[Authorize( HasPermission = "Add Account")]
public ActionResult Add()
{
// Handle the addition
}
应用程序将有许多权限(即编辑帐户，添加帐户，删除帐户....)我将为一个用户分配多个权限。具有Add Account权限的用户可以添加账号
这样的事情可以用Identity来完成吗?我怎样才能开始而不使问题复杂化呢?
您可以通过向基中添加Permission概念来扩展Identity工作流。您应该关心的最重要的事情是当前模型与新添加的功能之间的关系。我在我的最新项目中做到了这一点，并将其作为开放源代码的身份认证2会员系统的权限扩展发布在这里。您可以阅读Readme文件，也可以自由地提出您的问题或自己扩展库。
作为一个简短的例子，你可以这样使用:
第一种方法:
// GET: /Manage/Index
[AuthorizePermission(Name = "Show_Management", Description = "Show the Management Page.")]
public async Task<ActionResult> Index(ManageMessageId? message)
{
//...
}
第二种方法:
// GET: /Manage/Users
public async Task<ActionResult> Users()
{
if (await HttpContext.AuthorizePermission(name: "AllUsers_Management", description: "Edit all of the users information."))
{
return View(db.GetAllUsers());
}
else if (await HttpContext.AuthorizePermission(name: "UnConfirmedUsers_Management", description: "Edit unconfirmed users information."))
{
return View(db.GetUnConfirmedUsers());
}
else
{
return View(new List<User>());
}
}
声明告诉您用户是谁，而不是用户可以做什么。例如，它们可能是对用户的名字、电子邮件地址等的声明。用户的角色或他们所属的组也可能有声明(有一个细微的区别，但我们现在忽略它)。例如，可能存在角色声明，声明用户是会计和经理。
正如您注意到的，这些声明并没有告诉您用户可以做什么。可能会计可以编辑一个帐户，但索赔不会告诉你。在某种程度上，您必须将角色(和其他声明)转换为权限(如您所称)。
不幸的是，在。net框架中没有标准组件来做这件事。唯一接近的是AzMan，但现在已经被弃用了。
这意味着你有两个选择:
你可以扮演自己的角色。这并不太难。基本上，您需要一个角色和任务之间具有多对多关系的数据结构，以及任务和单个细粒度权限之间具有多对多关系的数据结构。阿兹曼模型可以是一个很好的灵感来源。
对于简单的应用程序来说，许多人采用的替代方法可能已经足够好了，那就是在应用程序中硬编码角色。这就是[Authorize(Roles = "Accountant")]的用武之地。显然，无论何时业务组织发生变化，该模型都需要重新编译，但如果不经常发生，这可能是可以的。