ASP.NET在用户管理权限中的应用

2022-09-10

用户权限控制的核心是授权模型的选择与建立。选择正确的授权模型, 就从本质上决定了权限系统的易用性和通用性。目前, 比较通用的授权模型是基于角色的访问控制RBAC (Role-Based Access Control) 模型, 并且在中小型系统中已经得到了广泛应用。

RBAC的概念是从20世纪70年代对在线的多用户、多应用系统的研究开始的。最早是由美国国家标准与技术研究院的研究人员David和Richard提出的。它的基本思想就是引入了角色的概念, 并且将用户和用户所具有的权限分离开来, 管理员可以分别对角色、用户、权限进行管理, 为用户指定角色来实现对用户的授权操作, 因此形成了用户—角色、角色—权限和角色—角色之间的关系模型。

A S P.N E T是微软推出的基于通用语言的编程框架, 可用于在服务器上生成功能强大的Web应用程序。它是一个基于.NET框架的编译环境, 可以用任何.N E T兼容的语言创建程序。A S P.N E T不是传统A S P的简单升级, 它是微软将Web的基础和面向对象的编程思想结合起来推出的产物。相较于以前的W e b开发模型, A S P.N E T具有以下优点:增强的功能、世界级的工具支持、威力和灵活性、简易性、可管理性、可缩放性及可用性、自定义性及扩展性。

1 方案设计

新的系统站点采用三层设计, 分为数据层、商务层和表示层。并需创建数据库保存有关用户和有效许可的信息。

在.NET环境下构建的MIS中, ASP.NET和IIS (Internet信息服务) 一起为用户提供安全保障。当用户向服务器请求MIS中的资源时, IIS将接过此请求, 并使用基本式、摘要式或其他的验证方式对用户进行验证。如果系统网站中全部或部分内容无须经过验证, 则可将IIS设为匿名访问。IIS可以根据ACL (存取控制清单) 定义的NTFS权限对客户端进行授权。通过授权, IIS会允许或禁止用户存取要求的资源。经过验证之后, 用户的W i n d o w s存取令牌将会被传送到ASP.NET, 如果IIS使用的是匿名验证, 则存取令牌为匿名Internet使用者 (使用默认值I U S R_M A C H I N E) 。只有通过了I I S中的验证, 用户的请求才能传送到A S P.N E T。

将基于A S P.N E T的用户权限设计应用于MIS, 不仅要解决用户准入和权限分配的问题, 还要考虑该权限设计如何与.NET安全机制相结合。以此为基本思想, 来实现用户权限设计。

1.1 数据库设计

根据R B A C思想, 系统主要创建三个核心数据结构:用户、许可和角色。角色是一个许可的逻辑分组, 不同的角色包含不同的许可集。角色和许可及用户相关, 而许可和许可组相关。许可组是按照功能分类的许可的集合。

将系统按功能分为四个模块:系统管理模块、人员管理模块、信息管理模块和业务管理模块;分别在数据库中建立六个表, 即系统用户表、系统角色表、系统用户角色表、系统许可表、许可组表和系统权限表。

1.2 ASP.NET安全扩展机制设计

A S P.N E T的安全机制是非常强大的, 它能够自动地在Context对象中生成一个名为User的属性, 该属性能够让我们访问各种信息, 包括用户是否已经验证、验证用户的类型和用户名等。不论程序是基于表单的验证还是Windows验证, 都可以使用Context对象表示当前HttpContex实例中的Uers对象。

但是由于.N E T的安全实现没有提供一种从数据库获取许可级别的方式, 因此方案在利用.N E T已有的安全机制的基础上必须实现扩展。.N E T的安全机制基于负责人 (Principal) 的概念。Principal对象代表以其名义运行代码的用户的安全环境。低于负责人的级别是 (Identity) , 代表执行代码的用户。每一个负责人都有一个。这种通用的负责人和身份概念用于基于表单的验证、W i n d o w s验证和其他验证。方案在扩展时, 可以通过.NET提供的IPrincipal和Identity接口方便地使用此安全机制。

在方案中创建两个实现IPrincipal和Identity接口的类, 一是SitePrincipal类, 它从系统商务层继承, 用来得到用户的各种信息, 并可以返回用户在数据库中的角色或者权限列表以供判断用户的权限。该类的主要方法有验证类, 用来验证用户是否有登录的权限。Site Principal类必须实现IPrincipal接口成员I d e n t i y和I s I n R o l e;二是SiteIdentity类, 它也继承自商务层, 主要存放用户的基本信息, 包括用户名、I D号等。SiteIdentity类要实现Iidentity接口的AuthenticationType和IsAuthenticated成员。

在方案实现中, 使用A S P.N E T中基于表单的验证机制设置负责人的身份。将基于当前用户身份创建的SitePrincipal类的实例赋予Context.User属性, 在需要进行用户验证时, 只需判断当前Context对象中User属性的信息即可获得该用户的权限, 并通过权限的大小授予其相应的系统资源。

2 方案实现

由于在A S P.N E T的安全策略中, 基于Windows的身份验证适用于受控环境的网站 (例如企业内网) 而非Internet网络, 因此方案使用基于表单的验证机制, 此机制依靠Cookies工作。在任何时段, 用户都可以访问无需验证的链接, 系统会为用户加载新的页面。当用户请求需要验证的资源时, 登录验证页面将会加载, 通过验证的用户才能对所要求的系统资源进行访问, 否则请求将被拒绝。系统会识别已经验证过的用户, 不会强制其手工验证, 并对其分配相应的资源。

系统站点采用三层设计, 分为数据层、商务层和表示层。并需创建数据库保存有关用户和有效许可的信息。

2.1 数据库实现

(1) 系统用户表。保存所有系统用户的登录账号及相关用户信息, 如用户的住址和邮箱等。

(2) 系统角色表。保存了用户所有的角色信息, 用户和角色是双向多对多的关系。如前所述, 系统角色由教师、学校负责人、培训班负责人、培训中心负责人和中心主任构成。

(3) 系统用户角色表。保存用户所拥有的角色信息。它实际上是用户和角色的关联。

(4) 系统许可表。保存访问系统资源所需要的所有的权限信息。

(5) 系统许可组表。保存系统中各许可组的分类号和描述信息。每一个许可组和系统中的一个功能模块相对应, 包含了该模块拥有的权限, 是模块中所用权限的集合。

(6) 系统权限表。保存了所有角色的权限集合。是角色和许可的关联。

在系统许可组表中, 许可组ID号以100、200、300、400依次表示, 分别代表系统中系统管理模块、人员管理模块、信息管理模块和业务管理模块的许可集合。系统许可表中, 许可ID号为三位数字, 第一位数字为1的许可全部属于ID号为100 (即系统管理模块的权限集) 的权限组, 其ID号从101依次向后排列。许可ID号首位为2的许可属于ID号为200的许可组, 依次类推。

2.2 ASP.NET安全扩展机制实现

A S P.N E T的安全机制是非常强大的, 它能够自动地在Context对象中生成一个名为User的属性, 该属性能够让我们访问各种信息, 包括用户是否已经验证、验证用户的类型和用户名等。不论程序是基于表单的验证还是Windows验证, 都可以使用Context对象表示当前HttpContext实例中的U e r s对象。

但是由于.N E T的安全实现没有提供一种从数据库获取许可级别的方式, 因此方案在利用.N E T已有的安全机制的基础上必须实现扩展。.N E T的安全机制基于负责人 (Principal) 的概念。Principal对象代表以其名义运行代码的用户的安全环境。低于负责人的级别是 (Identity) , 代表执行代码的用户。每一个负责人都有一个。这种通用的负责人和身份概念用于基于表单的验证、Windows验证和其他验证。方案在扩展时, 可以通过.NET提供的IPrincipal和Identity接口方便地使用此安全机制。

在方案实现中, 使用ASP.NET中基于表单的验证机制设置负责人的身份。将基于当前用户身份创建的SitePrincipal类的实例赋予Context.User属性, 在需要进行用户验证时, 只需判断当前Context对象中User属性的信息即可获得该用户的权限, 并通过权限的大小授予其相应的系统资源。