当前位置:文档之家› 用户权限设计(二)——用户认证管理设计方案

用户权限设计(二)——用户认证管理设计方案

用户权限设计(二)——用户认证管理设计方案
用户权限设计(二)——用户认证管理设计方案

用户认证管理设计方案

1 设计思路

为了设计一套具有较强可扩展性的用户认证管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。

1.1 用户

用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。

用户通常具有以下属性:

ü编号,在系统中唯一。

ü名称,在系统中唯一。

ü用户口令。

ü注释,描述用户或角色的信息。

1.2 角色

角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性:

ü编号,在系统中唯一。

ü名称,在系统中唯一。

ü注释,描述角色信息

1.3 权限

权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、修改和删除功能,通常具有以下属性:

ü编号,在系统中唯一。

ü名称,在系统中唯一。

ü注释,描述权限信息

1.4 用户与角色的关系

一个用户(User)可以隶属于多个角色(Role),一个角色组也可拥有多个用户,用户角色就是用来描述他们之间隶属关系的对象。用户(User)通过角色(Role)关联所拥有对某种资源的权限,例如

l用户(User):

UserID UserName UserPwd

1 张三xxxxxx

2 李四xxxxxx

……

l 角色(Role):

RoleID RoleName RoleNote

01 系统管理员监控系统维护管理员

02 监控人员在线监控人员

03 调度人员调度工作人员

04 一般工作人员工作人员

……

l 用户角色(User_Role):

UserRoleID UserID RoleID UserRoleNote

1 1 01 用户“张三”被分配到角色“系统管理员”

2 2 02 用户“李四”被分配到角色“监控人员”

3 2 03 用户“李四”被分配到角色“调度人员”

……

从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。

1.5 权限与角色的关系

一个角色(Role)可以拥有多个权限(Permission),同样一个权限可分配给多个角色。例如:l 角色(Role):

RoleID RoleName RoleNote

01 系统管理员监控系统维护管理员

02 监控人员在线监控人员

03 调度人员调度工作人员

04 一般工作人员工作人员

……

l 权限(Permission):

PermissionID PermissionName PermissionNote

0001 增加监控允许增加监控对象

0002 修改监控允许修改监控对象

0003 删除监控允许删除监控对象

0004 察看监控信息允许察看监控对象

……

l 角色权限(Role_Permission):

RolePermissionID RoleID PermissionID RolePermissionNote

1 01 0001 角色“系统管理员”具有权限“增加监控”

2 01 0002 角色“系统管理员”具有权限“修改监控”

3 01 0003 角色“系统管理员”具有权限“删除监控”

4 01 0004 角色“系统管理员”具有权限“察看监控”

5 02 0001 角色“监控人员”具有权限“增加监控”

6 02 0004 角色“监控人员”具有权限“察看监控”

……

由以上例子中的角色权限关系可以看出,角色权限可以建立角色和权限之间的对应关系。

1.6 建立用户权限

用户权限系统的核心由以下三部分构成:创造权限、分配权限和使用权限。

第一步由Creator创造权限(Permission),Creator在设计和实现系统时会划分。利用存储过程CreatePermissionInfo(@PermissionName,@PermissionNote)创建权限信息,指定系统模块具有哪些权限。

第二步由系统管理员(Administrator)创建用户和角色,并且指定用户角色(User-Role)和角色权限(Role-Permission)的关联关系。

1) 具有创建用户、修改用户和删除用户的功能:Administrator

l 存储过程CreateUserInfo(@UserName,@UserPwd)创建用户信息;

l 存储过程ModifyUserInfo(@UserName,@UserPwd)修改用户信息;

l 存储过程DeleteUserInfo(@UserID)删除用户信息;

2) 具有创建角色和删除角色的功能:Administrator

l 存储过程CreateRoleInfo(@RoleName,@RoleNote)创建角色信息;

l 存储过程DeleteRoleInfo(@RoleID)删除角色信息;

3)Administrator具有建立用户和角色、角色和权限的关联关系功能:

l 存储过程GrantUserRole(@UserID,@RoleID,@UserRoleNote)建立用户和角色的关联关系;l 存储过程DeleteUserRole(@UserRoleID)删除用户和角色的关联关系;

l 存储过程GrantRolePermission(@RoleID,@PermissionID,@RolePermissionNote)建立角色和权限的关联关系;

l 存储过程DeleteRolePermission(@RolePermissionID)删除角色和权限的关联关系;

第三步用户(User)使用Administrator分配给的权限去使用各个系统模块。利用存储过程GetUserRole(@UserID, @UserRoleID output),GetRolePermission(@RoleID,@Role-

-PermissinID output)获得用户对模块的使用权限。

1.7 用户认证实现

当用户通过验证后,由系统自动生成一个128位的TicketID保存到用户数据库表中,建立存储过程Login(@UserID,@UserPwd,@TicketID output)进行用户认证,认证通过得到一个TicketID,否则TicketID为null。其流程图如下:

图1 Login流程图

得到TicketID后,客户端在调用服务端方法时传递TicketID,通过存储过程JudgeTicketPermission(@TicketID,@PermissionID)判断TicketID对应的用户所具有的权限,并根据其权限进行方法调用。

当用户退出系统时,建立存储过程Logout(@UserID)来退出系统。当用户异常退出系统时,根据最后的登陆时间(LastSignTime)确定用户的TickeID,建立存储过程ExceptionLogout (@UserID,@LastSignTime)处理用户的异常退出。

图2 Logout流程图

WebService可以采用SoapHeader中写入TicketID来使得TicketID从客户端传递给服务端。.Net Remoting可以采用CallContext类来实现TicketID从客户端传递给服务端。

2 数据库设计

2.1 数据库表

图3 数据库关系图

2.2 数据库表说明

2.2.1 用户表(Static_User)

Static_User

Static_User字段名详细解释类型备注

UserID 路线编号varchar(20) PK

UserName 用户名称varchar(20)

UserPwd 用户密码varchar(20)

LastSignTime 最后登陆时间datatime

SignState 用户登陆状态标记int

TickeID 验证票记录编号varchar(128)

2.2.2 角色表(Static_Role)

Static_Role

Static_User字段名详细解释类型备注

RoleID 角色编号varchar(20) PK

RoleName 角色名称varchar(20)

RoleNote 角色信息描述varchar(20)

2.2.3 用户-角色表(Static_User_Role)

Static_User_Role

Static_User字段名详细解释类型备注

UserRoleID 用户角色编号varchar(20) PK

UserID 用户编号varchar(20) PK

RoleID 角色编号varchar(20) PK

UserRoleNote 用户角色信息描述varchar(20)

2.2.4 权限表(Static_Permission)

Static_Permission

Static_User字段名详细解释类型备注

PermissionID 编号varchar(20) PK PermissionName 权限名称varchar(20)

PermissionNote 全息信息描述varchar(20)

2.2.5 角色-权限表(Static_Role_Permission)

Static_Role_Permission

Static_User字段名详细解释类型备注RolePermissionID 角色权限编号varchar(20) PK

RoleID 角色编号varchar(20) PK

PermissionID 权限编号varchar(20) PK RolePermissionNote 角色权限信息描述

3 .net技术概要

3.1 WebService SoapHeader

对SQL 数据库执行自定义身份验证和授权。在这种情况中,应向服务传递自定义凭据(如用户名和密码),并让服务自己处理身份验证和授权。将额外的信息连同请求一起传递给XML Web 服务的简便方法是通过SOAP 标头。为此,需要在服务中定义一个从SOAPHeader 派生的类,然后将服务的公共字段声明为该类型。这在服务的公共合同中公开,并且当从WebServiceUtil.exe 创建代理时可由客户端使用,如下例所示:

using System.Web.Services;

using System.Web.Services.Protocols;

// AuthHeader class extends from SoapHeader

public class AuthHeader : SoapHeader {

public string Username;

public string Password;

}

public class HeaderService : WebService {

public AuthHeader sHeader;

...

}

服务中的每个WebMethod 都可以使用SoapHeader 自定义属性定义一组关联的标头。默认情况下,标头是必需的,但也可以定义可选标头。SoapHeader 属性指定公共字段的名称或者Client 或Server 类的属性(本标题中称为Headers 属性)。在为输入标头调用方法前,WebService 设置Headers 属性的值;而当方法为输出标头返回时,WebService 检索该值。[WebMethod(Description="This method requires a custom soap header set by the caller")]

[SoapHeader("sHeader")]

public string SecureMethod() {

if (sHeader == null)

return "ERROR: Please supply credentials";

else

return "USER: " + https://www.doczj.com/doc/4c7971487.html,ername;

}

然后,客户端在调用要求标头的方法之前,直接在代理类上设置标头,如下面的示例所示:HeaderService h = new HeaderService();

AuthHeader myHeader = new AuthHeader();

https://www.doczj.com/doc/4c7971487.html,ername = "username";

myHeader.Password = "password";

h.AuthHeader = myHeader;

String result = h.SecureMethod();

3.2 .Net Remoting的安全认证方式

CallContext提供与执行代码路径一起传送的属性集,CallContext是类似于方法调用的线程本地存储的专用集合对象,并提供对每个逻辑执行线程都唯一的数据槽。数据槽不在其他逻辑线程上的调用上下文之间共享。当CallContext 沿执行代码路径往返传播并且由该路径中的各个对象检查时,可将对象添加到其中。当对另一个AppDomain 中的对象进行远程方法调用时,CallContext 类将生成一个与该远程调用一起传播的LogicalCallContext 实例。只有公开ILogicalThreadAffinative 接口并存储在CallContext 中的对象被在LogicalCallContext 中传播到AppDomain 外部。不支持此接口的对象不在LogicalCallContext 实例中与远程方法调用一起传输。

CallContext.SetData方法存储给定对象并将其与指定名称关联,CallContext.GetData方法从CallContext 中检索具有指定名称的对象。

下面的代码示例说明如何使用SetData 方法将主体和标识对象传输到远程位置以进行标识。

public class ClientClass {

public static void Main() {

GenericIdentity ident = new GenericIdentity("Bob");

GenericPrincipal prpal = new GenericPrincipal(ident,

Newstring[] {"Level1"});

LogicalCallContextData data =

new LogicalCallContextData(prpal);

//Enter data into the CallContext

CallContext.SetData("test data", data);

Console.WriteLine(data.numOfAccesses);

ChannelServices.RegisterChannel(new TcpChannel());

RemotingConfiguration.RegisterActivatedClientType( typeof(HelloServiceClass), "tcp://localhost:8082");

HelloServiceClass service = new HelloServiceClass();

if(service == null) {

Console.WriteLine("Could not locate server.");

return;

}

// call remote method

Console.WriteLine();

Console.WriteLine("Calling remote object");

Console.WriteLine(service.HelloMethod("Caveman"));

Console.WriteLine(service.HelloMethod("Spaceman"));

Console.WriteLine(service.HelloMethod("Bob"));

Console.WriteLine("Finished remote object call");

Console.WriteLine();

//Extract the returned data from the call context

LogicalCallContextData returnedData =

(LogicalCallContextData)CallContext.GetData("test data");

Console.WriteLine(data.numOfAccesses);

Console.WriteLine(returnedData.numOfAccesses);

}

}

下面的代码示例说明如何使用GetData 方法将主体和标识对象传输到远程位置以进行标识。

using System;

using System.Text;

using System.Runtime.Remoting.Messaging;

using System.Security.Principal;

public class HelloServiceClass : MarshalByRefObject {

static int n_instances;

int instanceNum;

public HelloServiceClass() {

n_instances++;

instanceNum = n_instances;

Console.WriteLine(this.GetType().Name + " has been created.

Instance # = {0}", instanceNum);

}

~HelloServiceClass() {

Console.WriteLine("Destroyed instance {0} of HelloServiceClass.", instanceNum);

}

public String HelloMethod(String name) {

//Extract the call context data

LogicalCallContextData data =

(LogicalCallContextData)CallContext.GetData("test data");

IPrincipal myPrincipal = data.Principal;

//Check the user identity

if(https://www.doczj.com/doc/4c7971487.html, == "Bob") {

Console.WriteLine("\nHello {0}, you are identified!", https://www.doczj.com/doc/4c7971487.html,);

Console.WriteLine(data.numOfAccesses);

}

else {

Console.WriteLine("Go away! You are not identified!");

return String.Empty;

}

// calculate and return result to client

return "Hi there " + name + ".";

}

}

4 详细代码设计

4.1 WebService代码设计

WebService端代码主要进行对数据库的操作,建立起Client操作数据库所需要的方法,供Client的端调用。

1)class UserInfoMng() 用户信息管理类,其中包括方法:

l CreateUserInfo(string UserName string UserPwd) 建立用户信息,调用存储过程CreateUserInfo(@UserName,@UserPwd)

l ModifyUserInfo(string UserName string UserPwd) 修改用户信息,调用存储过程ModifyUserInfo(@UserName,@UserPwd)

l DeleteUserInfo() 删除用户信息,调用存储过程DeleteUserInfo

(@UserID)

2)class UserAuthentication() 用户认证类,用来实现用户角色、权限的设置,包括方法:l CreatePermissionInfo(string PermissionName string Permissi-

-onNote) 建立权限信息,调用存储过程CreatePermissionInfo

(@PermissionName,@PermissionNote)

l CreateRoleInfo(string RoleName string RoleNote) 建立角色信息,调用存储过程CreateRoleInfo(@RoleName,@RoleNote)

l DeleteRoleInfo() 删除角色信息,调用存储过程DeleteRoleInfo

(@RoleID)

l GrantUserRole(string UserID string RoleID string UserRoleNote) 授予用户角色,调用存储过程GrantUserRole(@UserID,@RoleID,

@UserRoleNote)

l DeleteUserRole() 删除用户角色,调用存储过程DeleteUserRole

(@UserRoleID)

l GrantRolePermission(string RoleID string PermissionID string RolePermissionNote) 授予角色权限,调用存储过程GrantRolePermission(@RoleID,@PermissionID,@RolePermissionNote) l DeleteRolePermission() 删除授予的角色权限,调用存储过程

DeleteRolePermission(@RolePermissionID)

4.2 用户认证代码设计(Client端)

Client端调用WebService方法来进行数据库访问,Client端代码设计主要实现界面的功能,包括:权限设置、用户管理、用户授权管理和用户认证管理

1)权限设置

class PermissionInfoMng() 用户权限信息管理类,包括方法:

l CreatePermissionInfo() 建立权限信息

2)用户管理

class UserInfoMng() 用户信息管理类,包括方法:

l CreateUserInfo() 建立用户信息

l ModifyUserInfo() 修改用户信息

l DeleteUserInfo() 删除用户信息

3)用户授权管理

class RoleInfoMng() 角色信息管理类,包括方法:

l CreateRoleInfo() 建立角色信息

l DeleteRoleInfo() 删除角色信息

class UserRoleMng() 用户角色管理类,包括方法:

l GrantUserRole() 授予用户角色

l DeleteUserRole() 删除用户角色

class RolePermissionMng() 角色权限管理类,包括方法

l GrantRolePermission() 授予角色权限

l DeleteRolePermission() 删除角色权限

4)用户认证管理

class Authentication() 用户认证类,包括方法:

l Login(string UserName string UserPwd) 用户登陆认证,用户认证通过分配给用户一个TicketID,否则TicketID则为null

l Logout() 用户正常退出

l ExceptionLogout() 用户异常退出

本文来自CSDN博客,转载请标明出处:https://www.doczj.com/doc/4c7971487.html,/yifeiyuann/archive/2006/11/21/1401065.aspx

系统权限管理设计方案(优选.)

OA系统权限管理设计方案 l 不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 l 可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 l 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。 l 满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。 针对OA系统的特点,权限说明: 权限 在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。

角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限,有4种方式(参考飞思办公系统) A. 通过职位 a) 在职位中,职位成员的权限继承当前所在职位的权限,对于下级职位拥有的权限不可继承。 b) 实例中:如前台这个职位,对于考勤查询有权限,则可以通过对前台这个职位设置考勤查询的浏览权,使他们有使用这个对象的权限,然后再设置个,考勤查询权(当然也可以不设置,默认能进此模块的就能查询),则所有前台人员都拥有考勤查询的权利。 B. 通过项目 a) 在项目中,项目成员的权限来自于所在项目的权限,他们同样不能继承下级项目的权限,而对于项目组长,他对项目有全权,对下级项目也一样。 b) 实例中:在项目中,项目成员可以对项目中上传文档,查看本项目的文档,可以通过对项目设置一个对于本项目的浏览权来实现进口,这样每个成员能访问这个项目了,再加上项目文档的上传权和查看文档权即可。

用户权限设计

用户角色权限设计 实现业务系统中的用户权限管理 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计,而是从程序流程以及数据库结构开始入手。为了实现需求,数据库的设计可谓及其重要,无论是“组”操作的概念,还是整套权限管理系统的重用性,都在于数据库的设计。 我们先来分析一下数据库结构: 首先,action表(以下简称为“权限表”),gorupmanager表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图:

统一认证系统_设计方案

基础支撑平台

第一章统一身份认证平台 一、概述 建设方案单点登录系统采用基于Liberty规范的单点登录ID-SSO系统平台实现,为数字化校园平台用户提供安全的一站式登录认证服务。为平台用户以下主要功能: 为平台用户提供“一点认证,全网通行”和“一点退出,整体退出”的安全一站式登录方便快捷的服务,同时不影响平台用户正常业务系统使用。用户一次性身份认证之后,就可以享受所有授权范围内的服务,包括无缝的身份联盟、自动跨域、跨系统访问、整体退出等。 提供多种以及多级别的认证方式,包括支持用户名/密码认证、数字证书认证、动态口令认证等等,并且通过系统标准的可扩展认证接口(如支持JAAS),可以方便灵活地扩展以支持第三方认证,包括有登录界面的第三方认证,和无登录界面的第三方认证。 系统遵循自由联盟规范的Liberty Alliance Web-Based Authentication 标准和OASIS SAML规则,系统优点在于让高校不用淘汰现有的系统,无须进行用户信息数据大集中,便能够与其无缝集成,实现单点登录从而建立一个联盟化的网络,并且具有与未来的系统的高兼容性和互操作性,为信息化平台用户带来更加方便、稳定、安全与灵活的网络环境。 单点登录场景如下图所示:

一次登录认证、自由访问授权范围内的服务 单点登录的应用,减轻了用户记住各种账号和密码的负担。通过单点登录,用户可以跨域访问各种授权的资源,为用户提供更有效的、更友好的服务;一次性认证减少了用户认证信息网络传输的频率,降低了被盗的可能性,提高了系统的整体安全性。 同时,基于联盟化单点登录系统具有标准化、开放性、良好的扩展性等优点,部署方便快捷。 二、系统技术规范 单点登录平台是基于国际联盟Liberty规范(简称“LA”)的联盟化单点登录统一认证平台。 Liberty规范是国际170多家政府结构、IT公司、大学组成的国际联盟组织针对Web 单点登录的问题提供了一套公开的、统一的身份联盟框架,为客户释放了使用专用系统、不兼容而且不向后兼容的协议的包袱。通过使用统一而又公开的 Liberty 规范,客户不再需要为部署多种专用系统和支持多种协议的集成复杂度和高成本而伤脑筋。 Liberty规范的联盟化单点登录SSO(Single Sign On)系统有以下特点: (1). 可以将现有的多种Web应用系统联盟起来,同时保障系统的独立性,提供单点 登录服务;

汾酒集团信息管理系统设计方案

山西杏花村汾酒集团信息管理系统设计方案 系统整体架构 整个系统结构如下图所示: 1.各个计量参数通过无线传输的方式发送往中控室。一个车间或者几个车间内 的计量信息汇集到一个从电台,从电台发送数据至中控室内的主电台,中控机负责对数据的处理和存储。电台采用日精ND250数传电台,该电台为进口电台,性能安全可靠。同时,采用无线传输,能节约布线成本和人工维修检查成本。 2.车间内计量信息传输采用两种方式,便于相关人员检查。第一种方式,对于 便于直接观察表头数据的流量计,直接通过485总线把计量信息传输到从电台。第二种方式,对于安装在高处或者危险环境下的流量计,不便于直接观察流量计表头数据,可通过485把一块或者几块流量计信息集成并存储到到一个安装在安全地点的积算仪,然后再通过485总线传输到从电台。采用第二种方式的好处有两个,第一,通过观察积算仪数据就可以检查流量计工作情况,而不必到危险的地方观察流量计,从而确保工作人员的安全。第二,第一种传输方式和第二种能统一连接到485总线,便于布线。 3.多个客户端能同时观察计量信息,从而便于各个部门有效监控相关生产情况, 从而实现节能减排,提高生产效率。 客户端设计 为应对企业在现代化社会中对信息的管理和监测,以保持企业对信息的及时处理和管理,本软件除具有一般软件的通用功能外还具有以下功能: 1.支持多节点实时数据动态刷新显示,使用户第一时间可以观察各节点工作状 态。 2.支持多种模式的曲线显示,既有历史曲线显示,也可进行实时曲线显示,使

用户有更多直观感受。 3.支持多种模式报表打印,既可以选择报表类型,也可以对节点分类后实时各 种数据类型的打印,从而方便用户查看各种数据统计。 4.支持多客户端实时监控,集团各个部门办公室可同时检测相关计量数据,进 而更好地管理生产过程。 软件总体功能简介: 1.用户登陆功能:只有合法的注册账号才能登录到本系统中,在该功能中用户可以设置服务器所在的IP地址。如图1 图1 系统登陆界面 2. 用户管理功能:在通过登陆界面后用户将登录到本机安装的主窗体界面(如图2),当在主窗体中单击左上角的用户管理按钮时将进入到用户管理窗体(如图3)在该窗体上部显示了当前登录的用户名以及该用户名的权限,在窗体下部当勾选上修改密码复选框时将可以进行当前用户的密码修改功能,当勾选上添加用户复选框时,根据当前用户的权限进行新用户的添加。

JAVA用户角色权限数据库设计

实现业务系统中的用户权限管理 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。 就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计,而是从程序流程以及数据库结构开始入手。为了实现需求,数据库的设计可谓及其重要,无论是“组”操作的概念,还是整套权限管理系统的重用性,都在于数据库的设计。 我们先来分析一下数据库结构: 首先,action表(以下简称为“权限表”),gorupmanager表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图:

RBAC用户角色权限设计方案(非常好)

扩展RBAC用户角色权限设计方案 RBAC (Role-Based Access Control ,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系。(如下图)

角色是什么?可以理解为一定数量的权限的集合,权限的载体。例如:一个论坛系统,“超级管理员”、“版主”都是角色。版主可 管理版内的帖子、可管理版内的用户等,这些是权限。要给某个用户授予这些权限,不需要直接将权限授予用户,可将“版主”这个 角色赋予该用户。 当用户的数量非常大时,要给系统每个用户逐一授权(授角色),是件非常烦琐的事情。这时,就需要给用户分组,每个用户组内有 多个用用户表 用户ID 範加刖 用户名 VAKCJUJG GO) 角邑表 疣Jg KU ■郦 行恳 律邑朽VABOW^O) 权眼表 用戶角色吴说 用/Tnf NUM 血氏 宦色 m MUMPER 权限捺识VARCKAR2(5O)

户。除了可给用户授权外,还可以给用户组授权。这样一来,用户拥有的所有权限,就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。(下图为用户组、用户与角色三者的关联关系)

用户亀 用,口?血 IF 用尸廻名称 则G01 敦用户绢茗称imiEEH 用尸角色关联表 SPTB mBER <£kl> 角色IE ?0EIt <£k2> 用户组TD2 MJWBER <£kt> 用 FID2 HUMBER ]甬户蛆帽色关联炭 用尸注D IBIBER 甬色ID mWER FK 瀏 EEF USn 用戶表 ^.PlD 利町四 fflPa ¥血诙应伽] 箱 felD NW 耶 yk ; 隹色客 mCHkR2UU J FK UE EEf SOLE 用户鉅与用户关朕表 y. rK_SR_ta_CRDUF 角色董 FK_UR_ USER

信息资产管理系统设计方案

? ?

XXX 信息资产管理系统 设 计 方 案

2011年9月目录

一项目设计概述 1.1项目现状及需求分析 项目现状 在目前的人工管理状态下,存在着对人为操作的严重依赖,服务质量难以监控,需要一套先进可靠的管理系统,避免给IT 系统带来更多的运行维护管理风险。 ?没有合理的服务级别评估机制,导致项目运营时无法实现服务承诺。 ?开展运营外包无法评估服务级别所需资源和成本,投入与收益难以量化。 ?服务质量不稳定。更多原因是现场服务标准不够明确,服务质量大多依赖于个人的技能和知识水平、态度。 ?服务管理不细致,导致服务质量影响信息系统运维目标难以达成。 上述的管理风险常常困扰信息化深入推进时,因此需要进一步提升IT 服务管理的科学性、规范性、标准化,为高速发展的业务经营提供有力的支撑。 1.2项目目标 引入IT 服务管理的国际最佳实践理论ITIL,提升管理创新能力;建立一套基于国际ISO20000 服务管理标准的ITSM 体系和ITSM平台工具,固化相应的IT 服务管理流程,提高工作效率,降低IT 服务风险。 ?实现IT服务管理的信息化,规范IT服务管理流程,提高IT服务管理的工作效率和服务质量,降低IT服务成本,提高用户对IT服务的满意度。 ?通过服务台为IT服务的用户提供一个单一联系点,协调IT部门和用户之间的关系,为IT 服务的运作提供支持。 ?通过事件管理流程,在给用户和公司的正常业务活动带来最小影响的前提下,使IT系统能

够尽快地返回到正常工作状态;保留事件的有效记录,以便能够权衡并改进处理流程,同时给其他的服务管理流程提供合适的信息,以及正确报告进展情况等。 通过资产管理功能及其相关流程,对单位的所有IT资产的基本资料进行登记和维护,为资产相关的运维服务管理提供必要的信息基础,并对资产的配置变化进行跟踪,基本实现IT 资产的配置管理。 1.3系统功能设计 1.3.1服务台 对服务请求信息提供必要的初始支持,根据需要启动相应的服务流程,支持自动派单和人工派单,并对服务流程跟踪监督,同时向服务请求方反馈服务结果信息。 服务台的基本要求如下: 1)为用户提供IT服务窗口,用户可以通过该窗口填写故障申诉和服务申请记录。 2)能够支持用户通过电子邮件的方式提交投诉和服务申请。 3)能够提供预定义故障和申请服务的类别,自动激活不同的处理流程。 4)用户能够通过电话咨询、网站查询等方式了解自己提交的投诉和服务申请的处理结果。 5)支持对故障和服务申请的跟踪督办,确保所有的故障和服务申请能够以闭环方式结束。 1.3.2事件管理 事件管理包含以下功能:

最经典用户权限管理模块设计

实现业务系统中的用户权限管理--设计篇 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便 的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致 的人员编入同一组,然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套 管理系统,就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统 之间,功能权限是可以重用的,而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计,而是从程序流程以及数据库结构开始入手。为了实现需求,数据库的设计可谓及其重要,无论是“组”操作的概念,还是整套权限管理系统的重用性,都在于数据库的设计。 我们先来分析一下数据库结构: 首先,action表(以下简称为“权限表”),gorupmanager表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图:

统一认证平台的设计方案(XXXX互联网接入平台建设方案)

XXXX互联网接入平台建设方案为落实公司业务互联网化的发展规划,推动实现公司办公、管理等相关业务的互联网化和移动化,我部拟开展互联网接入平台系统的建设,建立互联网和公司内部网络的唯一通道,在安全风险可监、可控、可承受的前提下,为公司员工提供更加顺畅、更为便捷的互联网接入服务,满足公司员工利用PC、移动终端等客户端通过互联网灵活访问公司内网业务系统的需求。 一、需求分析 (一)覆盖范围 员工通过PC、移动终端等客户端能够访问公司办公网及交易网内的相关业务系统。 (二)接入终端需求 1、PC终端 员工能够使用PC、笔记本电脑等终端访问公司内网系统,并确保员工PC终端自身的安全性不会影响到公司内网的信息系统。 2、移动终端 员工能够使用基于Android系统和iOS系统的移动终端,以企业APP的方式访问公司内网系统,访问期间,移动终端系统的其他程序无法获取相关数据等信息。互联网接入平台能够对移动终端的安全性进行检测和管理,不符合安全策的移动终端不允许接入内部网络。 (三)多运营商接入需求

公司员工通过联通、电信、移动等多个运营商接入互联网访问公司内部业务系统,因此互联网接入平台需支持上述各运营商,并能够选取最优访问路径以保障访问速度。 (四)身份认证及单点登录需求 由于互联网接入平台面向互联网开放,用户身份认证必须采取强身份认证方式,除需设置一定复杂度的登录口令外,必须支持RSA动态令牌认证,可扩展支持短信、数字证书、指纹等高强度认证方式。 互联网接入平台具备单点登录功能,用户身份验证通过后,互联网接入平台将向用户开放其权限范围内的所有业务系统,且用户访问其中任何业务系统均不需要再次认证。对B/S、C/S、APP 形态的业务系统均采用票据方式实现单点登录功能,不可使用密码代填的实现方式。 (五)安全防护需求 1、数据安全传输要求 PC终端、移动终端通过互联网访问公司内部网络的数据需采取加密措施,防止公司相关数据的泄露。 2、边界访问控制 互联网接入平台应采取安全区域划分、访问控制、入侵检测/防御、APT检测/防御等安全防护措施,有效保障互联网接入平台后部的公司信息系统的安全性。 二、方案设计

用户管理模块设计

用户管理模块设计 用户管理模块提供对用户信息的管理,包括用户注册、用户登录、用户权限管理、用户信息修改以及用户等级修改。 1、用户注册 根据用户表,设计相应的注册页面,注册页面包括用户名、密码、邮箱、部门、电话等信息,当用户进行注册时,填写这些信息,用户名是不能与已注册的用户名相同,填写完成后,提交注册请求,后台相应的Action会响应该动作,首先获取到页面发来的参数,然后将这些参数通过Session 对象写入到数据库中,最后向用户提示注册成功与否。 2、用户登录 用户注册之后,就可以通过账户和密码登陆至平台。当用户提交登陆请求,后台相应的Action 会响应该动作,首先获取到页面发来的用户名和密码,然后通过Query对象查询该用户是否存在且密码正确,最后将根据结果给用户发送跳转页面,如果用户存在且密码正确,则可进入平台主页面,否则,提示登陆错误信息。 3、用户权限管理 用户权限管理将用户分为普通用户和管理员,他们具有不同的权限,他们各自的权限如表1所示。此平台首次使用时,会内置一个超级管理员,有修改用户等级的权限。 表1 不同用户权限授权

定义一个权限拦截器,它的功能是用来检验用户类型,对每一个需要管理权限的操作均进行拦截,同时检验用户类型,判断该用户类型是否可执行该操作,即可达到权限管理的作用。如果某操作在当前用户等级对应的操作范围内,则可正常访问,否则跳转到提示页面,提示用户权限不足。 4、用户信息修改 用户管理模块提供用户修改自己信息的功能。当进入信息修改界面,首先会获取Session中当前用户信息,供用户在当前信息基础上进行信息修改。当用户填写完修改信息,并发送修改请求后,后台将响应用户的请求,首先得到所有用户修改参数,然后将修改的信息设置到该对象中,最后更新数据库,将更新结果发送给用户。 青山埋白骨,绿水吊忠魂。

教务管理信息系统实施设计方案

我院教务管理信息系统实施设计方案

目录 1 教务管理系统 (1) 1.1 教务管理信息系统软件情况介绍 (1) 1.2 系统的硬件组成 (1) 1.3 系统建设中的一些注意点 (2) 1.4 系统的特色介绍 (2) 2 系统参考标准和规范 (3) 2.1 引言 (3) 2.2 系统概述 (3) 2.2.1 设计目标 (3) 2.2.2 运行环境 (3) 2.2.3 需求概述 (4) 2.3 系统总体设计 (4) 2.3.1 总述 (4) 2.3.2 系统维护子系统 (7) 2.3.2.1 功能模块 (8) 2.3.2.2 数据流程 (8) 2.3.2.3 功能实现设计 (9) 2.3.3 学籍管理子系统 (12) 2.3.3.1 功能模块 (12) 2.3.3.2 数据流程 (13) 2.3.3.3 主要界面设计 (13) 2.3.3.4 主要功能实现 (14) 2.3.4 教学计划管理子系统 (21) 2.3.4.1 功能模块 (21) 2.3.4.2 教学计划数据及操作流程图 (21) 2.3.4.3 功能实现设计 (22) 2.3.5 智能排课子系统 (30) 2.3.5.1 功能模块 (31) 2.3.5.2 工作流程图 (31) 2.3.5.3 排课的数学模型与算法 (31) 2.3.5.4 功能实现设计 (35) 2.3.6 选课管理子系统 (36) 2.3.6.1 系统功能模块 (36) 2.3.6.2 功能实现设计 (36) 2.3.7 成绩管理子系统 (40) 2.3.7.1 功能模块 (40) 2.3.7.2 系统数据流程 (41) 2.3.7.3 主要界面设计 (41) 2.3.7.4 主要功能实现 (42) 2.3.8 教材管理子系统 (48)

一个用户权限管理模块的设计思路

一个用户权限管理模块的设计思路: 1. 权限资源(功能资源) 系统的所有权限信息。权限具有上下级关系,是一个树状的结构。如下: 系统管理 单位管理 查看单位 添加单位 修改单位 删除单位 部门管理 查看部门 添加部门 修改单位 删除单位 对于每个权限,又存在两种情况:1可访问;2可授权,部分表中采用拥有类型做判断(0可访问,1即可访问也可授权) 2. 用户 系统的具体操作者,用户可以自己拥有权限信息,可以归属于0~n个角色,可属于0~n 个组。他的权限集是自身具有的权限+所属的各角色具有的权限+所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。 3. 角色 为了对拥有相似权限的用户进行分类管理,因此定义角色,例如:超级管理员,一般管理员、一般用户等角色。在这里同时也让角色具有上下级关系,形成树状视图,父级角色的权限是自身及它的所有子角色的权限的综合。 4. 组 为了更好地管理用户,对用户进行分组归类,简称为用户分组。组也具有上下级关系,可以形成树状视图。在实际应用中,我们知道,组也可以具有自己的角色信息、权限信息。 就好比是javaeye中的圈子,一个圈子可以拥有多个会员,同时一个会员也可以加入多个圈子,对于不同的圈子又有不同的权限信息。(组的解释:例如一个公司中,不同的部门即可划分不同的组来进行权限的分配) 针对以上描述,结构关系如下: 整个模块分为组权限管理、角色权限管理、用户权限管理。 其中组权限管理:组权限 = 所属角色的权限合集 + 组自身的权限。

角色权限管理:角色权限 = 角色自身权限。 用户权限管理:用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。 注意:因为组和角色都具有上下级关系,所以下级的组或角色的权限只能在自己的直属上级的权限中选择,下级的组或者角色的总的权限都不能大于直属上级的总权限。 欢迎大家拍砖,给点建议。

多系统权限设计

多系统权限设计 1.多系统基于角色的权限设计 这种方案是最常见也是比较简单的方案,不过通常有这种设计已经够了,这种方案对于每一个操作不做控制,只是在程序中根据角色对是否具有操作的权限进行控制;这里我们就不做详述.此处采用角色关联模块的方式。 2.多系统基于操作的权限设计 这种模式下每一个操作都在数据库中有记录,用户是否拥有该操作的权限也在数据库中有记录,结构如下:

但是如果直接使用上面的设计,会导致数据库中的_SysUserFuncOperate这张表数据量非常大,所以我们需要进一步设计提高效率,请看方案3 3.多系统基于角色和操作的权限设计

如上图所示,我们通过采用角色分配操作的方式,这样子就可以减少操作权限表(_SysRole FuncOperate)中的记录,并且使设计更灵活一点。 但是这种方案在用户需求的考验之下也可能显得不够灵活够用,例如当用户要求临时给某位普通员工某操作权限时,我们就需要新增加一种新的用户角色,但是这种用户角色是不必要的,因为它只是一种临时的角色,如果添加一种角色还需要在收回此普通员工权限时删除此角色,我们需要设计一种更合适的结构来满足用户对权限设置的要求。 4.2,3组合的权限设计,其结构如下: 我们可以看到在上图中添加了_SysUserFunc和_SysUserFuncOperate表,使用此表来添加特殊用户的权限。这样在应用程序中我们就需要通过_SysUserFuncOperate和_SysRoleFuncOperat e两张表中的记录判断权限。 当然,有可能用户还会给出这样的需求:对于某一种Operate所操作的对象某一些记录会有权限,而对于其他的记录没有权限,比如说一个内容管理系统,对于某一些频道某个用户有

用户权限设计(二)——用户认证管理设计方案

用户认证管理设计方案 1 设计思路 为了设计一套具有较强可扩展性的用户认证管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。 1.1 用户 用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。 用户通常具有以下属性: ü编号,在系统中唯一。 ü名称,在系统中唯一。 ü用户口令。 ü注释,描述用户或角色的信息。 1.2 角色 角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性: ü编号,在系统中唯一。 ü名称,在系统中唯一。 ü注释,描述角色信息 1.3 权限 权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、修改和删除功能,通常具有以下属性: ü编号,在系统中唯一。 ü名称,在系统中唯一。 ü注释,描述权限信息 1.4 用户与角色的关系 一个用户(User)可以隶属于多个角色(Role),一个角色组也可拥有多个用户,用户角色就是用来描述他们之间隶属关系的对象。用户(User)通过角色(Role)关联所拥有对某种资源的权限,例如 l用户(User): UserID UserName UserPwd 1 张三xxxxxx 2 李四xxxxxx …… l 角色(Role): RoleID RoleName RoleNote 01 系统管理员监控系统维护管理员 02 监控人员在线监控人员 03 调度人员调度工作人员 04 一般工作人员工作人员 …… l 用户角色(User_Role): UserRoleID UserID RoleID UserRoleNote 1 1 01 用户“张三”被分配到角色“系统管理员”

信息管理系统实施方案设计.doc

信息管理系统实施方案设计1 信息管理实施方案 一、信息管理体系 (一)本项目信息体系的主要内容 1、项目招投标、勘察设计、施工、交付使用、维修等项目生命期或某个阶段中与项目代建有关的内容。 2、法律法规、企业规章制度、财政资金、市场、风险、客户、采购、合同、质量、安全、费用、进度、劳务、物资、机械信息等。 3、信息管理数据库系统、通讯系统、应用软件系统;形成若干相互作用、相互联系的,有机结合起来、有一定系统结构和功能且能表达一种管理行为的整体。 (二)建立项目信息管理体系的步骤 1、规划项目代建信息系统; 2、建立项目信息管理模式和制度; 3、选择适用的辅助管理项目信息的软件系统。 二、信息管理的措施方法 (一)硬件配置完善 1、现场将配备电脑、适当的通讯工具,以便信息传递。通

讯工具包括手机、座机、对讲机; 2、现场将配置信息记录设备,如照像机、摄像机等,对重要施工现场的情况进行拍照记录,以便查询。 (二)项目信息分类 本项目的项目信息按信息来源可分为项目公共信息和项目个体信息。公共信息包括各种国家法规和政府部门规章、市场价格信息、自然条件信息、供应商信息、勘察、设计、监理和施工单位信息等。项目个体信息则包括工程概况、施工记录、施工技术资料、工程协调、过程进度计划及资源计划、成本、商务、质量检查、安全文明施工及行政管理、竣工验收等信息。上述所有信息都将纳入本项目的信息管理系统范围,实施规范管理。 (三)项目信息管理的组织及制度保证 本工程项目代建方将设立专职的项目信息主管,隶属工程统筹工程师,专门负责制定本项目的信息管理办法和建立项目信息管理系统,实施信息管理工作。并在项目代建方其他专业工程师下属人员中指定兼职的项目基层信息员,负责收集各管理职能范围内的信息。兼职信息员受直属专业工程师及项目信息主管的双重领导,形成上通下达的项目信息资源管理组织体系。 项目代建方制订项目信息管理办法,将对项目信息主管的职责、信息分类方法、信息收集和处理、信息传递要求、传递渠道、传递形式、传递内容、传递审核及信息储存要求等作出详细规定。 (四)项目信息管理流程

用户权限管理系统需求分析

软件需求分析报告目录 1.引言 1.1 项目简介 本文档对通用用户权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。 1.2 编写说明 1.3参考资料 《通用权限管理系统需求规格说明书》 《通用权限管理系统数据库设计说明书》

2.目标 2.1概述 权限系统一直以来是我们应用系统不可缺少的一个部分,若每个应用系统都重新对系统的权限进行设计,以满足不同系统用户的需求,将会浪费我们不少宝贵时间,所以花时间来设计一个相对通用的权限系统是很有意义的。 本系统的设计目标是对应用系统的所有资源进行权限控制,比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。2.2系统目标 系统的目标包括如下三点: (1)对应用系统的所有资源进行权限控制,比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控; (2)完善用户、角色、组织、资源、操作的管理功能,其中的组织管理模块只提供组织视图,不参与权限的控制管理。 (3)开发人员开发新的系统功能,通过资源和角色模块进行操作管理。使用系统管理员身份登陆,直接将访问路径作对角色资源授权给操作,实现资源访问控制管理。 2.2.1 总目标 本系统提供一个调用简单、可复用性高、满足一般需求的权限管理模块,并为需要对权限管理的系统节省开发本。 2.2.2 性能目标 1、要求下载和安装速度快,响应时间快。

2、要求系统可适用于不同操作平台。 3、要求系统的可维护性和实用性强。 4、要求系统有一定的检错能力。 5、要求系统支持多用户同时操作,但管理者与用户不能同时操作。 2.2.3 功能目标 本系统的设计目标是对应用系统的所有资源进行权限控制,比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。 2.3 目标说明 3.结构 3.1系统需求结构 系统采用B/S架构模式,基于 BNFW开发,服务封装了对后台数据操纵的细节,并提供安全调用接口. WEB 应用程序通过接口访问系统服务,执行用户操作并返回结果。系统采用SQL SERVER数据库和tomcat web应用服务器开发,部署在 Linux和windows服务器下运行。 3.2 需求结构的说明 用户权限管理系统概貌如图所示:

权限设计方案

权限管理设计一 ?博客分类: ?设计 设计模式数据结构 应用程序权限设计 我们在开发系统的时候,经常会遇到系统需要权限控制,而权限的控制程度不同有不同的设计方案。 1.基于角色的权限设计 这种方案是最常见也是比较简单的方案,不过通常有这种设计已经够了,所以微软就设计出这种方案的通用做法,这种方案对于每一个操作不做控制,只是在程序中根据角色对是否具有操作的权限进行控制;这里我们就不做详述 2.基于操作的权限设计 这种模式下每一个操作都在数据库中有记录,用户是否拥有该操作的权限也在数据库中有记录,结构如下:

但是如果直接使用上面的设计,会导致数据库中的UserAction这张表数据量非常大,所以我们需要进一步设计提高效率,请看方案3 3.基于角色和操作的权限设计 如上图所示,我们在添加了Role,和RoleAction表,这样子就可以减少UserAction中的记录,并且使设计更灵活一点。 但是这种方案在用户需求的考验之下也可能显得不够灵活够用,例如当用户要求临时给某位普通员工某操作权限时,我们就需要新增加一种新的用户角色,但是这种用户角色是不必要的,因为它只是一种临时的角色,如果添加一种角色还需要在收回此普通员工权限时删除此角色,我们需要设计一种更合适的结构来满足用户对权限设置的要求。 4.2,3组合的权限设计,其结构如下: 我们可以看到在上图中添加了UserAction表,使用此表来添加特殊用户的权限,改表中

有一个字段HasPermission可以决定用户是否有某种操作的权限,改表中记录的权限的优先级要高于UserRole中记录的用户权限。这样在应用程序中我们就需要通过UserRole 和UserAction两张表中的记录判断权限。 到这儿呢并不算完,有可能用户还会给出这样的需求:对于某一种action所操作的对象某一些记录会有权限,而对于其他的记录没有权限,比如说一个内容管理系统,对于某一些频道某个用户有修改的权限,而对于另外一些频道没有修改的权限,这时候我们需要设计更复杂的权限机制。 5.对于同一种实体(资源)用户可以对一部分记录有权限,而对于另外一些记录没有权限的权限设计: 对于这样的需求我们就需要对每一种不同的资源创建一张权限表,在上图中对Content 和Channel两种资源分别创建了UserActionContent和UserActionChannel表用来定义用户对某条记录是否有权限;这种设计是可以满足用户需求的但是不是很经济, UserActionChannel和UserActionContent中的记录会很多,而在实际的应用中并非需要记录所有的记录的权限信息,有时候可能只是一种规则,比如说对于根Channel什么级别的人有权限;这时候呢我们就可以定义些规则来判断用户权限,下面就是这种设计。 6.涉及资源,权限和规则的权限设计

企业信息化建设管理设计方案.doc

企业信息化建设管理设计方案1 企业信息化建设管理方案 一、信息化建设规划 公司信息化建设需要涉及整个业务流程和管理过程,它包括公司的的经营、计划、合约、技术、质量、安全、施工、材料、设备、人力资源以及成本管理等各个重要环节,几乎涉及公司所有人员。因此,这将是一个非常庞大的工程。 公司信息化建设的目标是达到“一个中心、两级管控、三个集中、四控三管一协调”的目的。为此,需要建立以项目管理系统为核心,结合合同管理、计划管理、质量管理、材料管理、采购管理、设备管理、客户关系管理、人力资源管理、财务管理、行政办公管理、文档管理等功能的统一的企业管理信息平台。建立这样一个涉及公司方方面面的系统,工作量将十分巨大,绝不可能一蹴而就。 为了有效地完成公司的信息化工作,建议采取统一规划、分步实施的建设方式。一次性进行公司信息化建设的整体规划,完成需求分析和系统的整体涉及;实施过程则按照业务的重要程度和对信息化要求的紧迫程度和准备完善程度排序,逐步进行实施,保证实施一块成功一块。一方面可以保证信息化实施的有效性,同时也可以避免一次性投入过大,从而尽可能减少信息化建设对资金的压力。 根据目前公司的现有系统情况:财务部已采用了网络版的用友财务系统,实施了部门级的信息化;合同部则采用广联达造价

软件作为业务应用,但均为桌面系统,尚未做到联 网,数据、信息没有实现共享;其他部门均没有任何针对性的应用。因此,公司的信息化可初步分为几大部分: (一)企业级办公自动化系统(OA) 建设覆盖全公司(含子分公司和各项目部)的办公自动化管理系统。以此将日常的事务性工作先行纳入系统,并建立各级领导与员工使用网络和电脑进行事务管理的习惯。将各种日常工作的流程进行科学的梳理和合理的规划,通过系统的建立和使用的过程,逐步改善工作流程、规范管理、提高效率。 OA系统是处理公司内部的事务性工作,辅助管理,提高办公效率和管理手段的系统。公司需要建立的协同办公(OA)系统就是基于现代网络技术,以“工作流”为引擎、以“知识文档”为容器、以“信息门户”为窗口,使公司内部人员方便快捷地共享信息,高效地协同工作;改变过去复杂、低效的手工办公方式,实现迅速、全方位的信息采集、信息处理,为企业的管理和决策提供科学的依据。公司的OA应包括一些基本的功能模块:管理工作流程、知识目录架构、信息门户框架,以更便捷、更简单、更灵活、更开放的满足日常OA办公需求 公司应用协同OA系统,总体具备以下几大价值点: (1)落实管理制度、工作流程自动化 这牵涉到流转过程的实时监控、跟踪,解决多岗位、多部门之间的协同工作问题,实现高效率的协作。目前的企业和单位都存在着大量的工作流程,例如公文的处理、收发文、

系统权限管理设计方案.doc

OA系统权限管理设计方案7 OA系统权限管理设计方案 数据库2010-02-2310:09:25阅读13评论0字号:大中小 OA系统权限管理设计方案 l不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 l可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 l权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。 l满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。 针对OA系统的特点,权限说明: 权限

在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。 角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限,有4种方式(参考飞思办公系统) A.通过职位 a)在职位中,职位成员的权限继承当前所在职位的权限,对

统一身份认证系统建设方案

统一身份认证系统建设方案 发布日期:2008-04-01 1.1 研发背景 随着信息技术的不断发展,企业已逐渐建立起多应用、多服务的IT 架构,在信息化建设中起到十分重要的作用。但是各信息系统面向不同管理方向,各有其对应的用户群体、技术架构、权限体系,限制了系统之间的信息共享和信息交换,形成的信息孤岛。同时,每一个信息系统的用户拥有不同的角色(职能),需要操作不同的系统,难以对其需要和拥有的信息和操作进行综合处理,限制信息系统效率的发挥。在这种背景下企业准备实施内网信息门户系统。其中统一身份管理系统是内网信息门户系统的一个重要组成部分。 统一身份管理将分散的用户和权限资源进行统一、集中的管理,统一身份管理的建设将帮助实现内网信息门户用户身份的统一认证和单点登录,改变原有各业务系统中的分散式身份认证及授权管理,实现对用户的集中认证和授权管理,简化用户访问内部各系统的过程,使得用户只需要通过一次身份认证过程就可以访问具有相应权限的所有资源。 1.2 组成架构 汇信科技与SUN公司建立了紧密合作关系,汇信科技推出的统一身份认证解决方案基于SUN公司的Sun Java System Identity Manager和Sun Java System Access Manager以及Sun Java System Directory Server实现。主要包括受控层、统一访问控制系统(统一认证服务器)、统一身份管理系统(统一身份管理服务器)、目录服务器。 受控层位于各应用服务器前端,负责策略的判定和执行,提供AGENT和API两种部署方式。 统一认证服务器安装统一身份认证系统(AM),主要提供身份认证服务和访问控制服务。 统一认证服务器安装统一身份管理系统(IM),主要实现身份配给、流程自动化、委任管理、密码同步和密码重置的自助服务。 目录服务器部署Sun Java System Directory Server,是整个系统的身份信息数据中心。 1.1 功能描述 1.1.1 实现“一次鉴权”(SSO) “一次鉴权(认证和授权)”是指建立统一的资源访问控制体系。用户采用不同的访问手段(如Intranet、PSTN、GPRS等)通过门户系统

相关主题
文本预览
相关文档 最新文档