问题标签 [roles]

我来自 ASP.NET 背景，发现整个基于角色的授权方案至少可以说是有限的。我读过微软的新身份模型和基于声明架构的日内瓦框架，但它似乎过于复杂。

一般来说，我想更多地了解可能的授权架构，以找出最适合我的需求。

例如，如果您想创建应用程序范围的角色，例如“管理员”，那么应用程序范围的角色似乎就足够了。但是，如果我有 ie。具有项目实体的项目管理应用程序，其中每个项目都有自己的一组角色（例如项目 A 上的“编辑”和项目 B 上的“摄影师”）和相关权限。

有没有这方面的书可以推荐？

我试图在这里转换这个 VB.NET 示例 http://www.theproblemsolver.nl/usingthemembershipproviderinwinforms.htm

没有任何成功，任何人都可以知道一个例子吗？

谢谢

我有一个供学生、教师和管理员使用的系统。有时，讲师也可以是管理员。

我打算将菜单和子菜单存储在 XML 中。我应该将管理员和讲师菜单存储在单独的节点中，然后在渲染时将它们组合起来，还是应该有一个带有附加角色的主菜单，在确定角色时显示所有选项？

我需要根据用户的角色在 JSP 中做出决定。是否有标签或 EL 表达式可以让我这样做？

我们有一个 Struts 2 Web 应用程序，几乎每个员工都使用它来管理和配置我们的服务器场的作业。我们正在制定一项为客户制作仪表板的计划，这样他们就可以看到自己的工作，并非常简单地显示其状态（“进行中”、“准备打样”、“完成”等）。客户可以看到的所有页面的信息都将比员工的视图少得多，并且无法编辑或更改任何内容。但归根结底，它们本质上是相同信息的两种不同视图：一种非常简单，一种更复杂且可控。

天真的方法是在每个 jsp 中都有 if/else：

有没有更简单的方法来做到这一点？我可以创建两个单独的 jsps 目录，一个名为“customer”，一个名为“employee”（或默认值或其他），然后让 Struts 在我的操作中关闭属性以决定检查哪个目录？

还是有其他方法可以做到这一点？

其实很简单的问题：

我目前禁用了 IIS 匿名访问，用户使用他们的 Windows 登录名自动登录。但是调用 User.IsInRole("Role name") 返回 false。我仔细检查了 User.Identity.Name() 和“角色名称”，它应该返回 true。

我目前在我的 Web.Config 中有这个：

更新
我打电话给 User.IsInRole("Role name") 我应该打电话给 User.IsInRole("DOMAIN\Role name")

但是我仍然想知道是否需要 <membership> 条目？

我应该改变什么？（并且是否需要 <membership> 条目？）

根据我的书，如果启用RoleManagerModule了角色管理，则通过将RolePrincipal对象分配给HttpRequest.User. 但是安全上下文不是已经创建（因此主体对象被分配给HttpContext.User）FormsAuthenticationModule，它在被调用之前RoleManagerModule被调用吗？

我问这个，因为在以下代码中分配给的主体对象HttpRequest.User已经存在，即使RoleManagerModule尚未被调用：

FormsAuthenticationModule那么，由 创造并分配给的主体对象，HttpRequest.User后来被RolePrincipal对象（由 创造RoleManagerModule）取代了吗？

I am looking for a good role based authorization solution to use alongside Authlogic. Anyone have any good suggestions? Please list some pros and cons from your experience if possible please.

您如何在 C# 领域驱动设计项目中实现角色和安全性？关于它应该由调用应用程序（ASP.NET MVC）还是在域模型本身（模型实体和服务）中实现，我们存在一些激烈的争论。有些人认为它应该在网站本身，因为那里已经存在身份验证。但这意味着每次与核心业务系统集成时都必须重新实现安全性。

例如：管理员应该能够在系统中执行几乎任何操作，例如编辑和删除记录（即他们可以删除用户的订单）。另一方面，用户应该只能编辑和删除他们自己的记录（即他们可以从他们的购物车中添加/删除项目）。

顺便说一句，这是一篇关于该主题的不错的论文，涵盖了有关 DDD 和安全的 7 种不同场景：

领域驱动设计中的安全性

• 第四章 安全服务设计场景
  • 4.1 场景一：安全服务作为常规服务
  • 4.2 场景 2：UI 中嵌入的安全性
  • 4.3 场景三：封装领域模型的安全服务
  • 4.4 场景四：安全服务作为 UI 的网关
  • 4.5 场景 5：安全服务作为 UI 的适配器
  • 4.6 场景六：AOP 与适配器集成的安全服务
  • 4.7 场景七：与AOP集成的安全服务

我个人倾向于使用 PostSharp 的 AOP，但之前没有做过太多的工作，所以我犹豫要不要迈出这一步。