web业务系统权限控制

在以往的系统设计中，要么缺乏权限控制，要么就是权限控制很简单，，要么权限控制功能虽然丰富，但是跟业务紧密结合，下面提供一种权限控制模型，将权限控制按功能划分为彼此独立的最小依赖的功能模块，通过合理的部署这些模块，完成权限控制、单独登陆等功能。 系统划分为业务逻辑、权限管理、权限验证、登陆代理、登陆服务、用户管理、业务逻辑数据库、业务权限数据库和用户数据库。     业务逻辑是业务本身。     权限管理负责权限的增、删、查、改，角色的增、删、查、改，用户权限分配，角色权限分配，用户的角色分配。权限管理通过用户管理的用户查询服务来查询用户凭证。     权限验证提供用户权限查询服务。     登陆代理转发登陆请求，保存登陆用户凭据。     登陆服务接收登陆请求，验证用户身份，返回登陆用户凭据。     用户管理负责用户的增、删、查、改，用户组织结构的增、删、查、改。     业务逻辑数据库保存业务数据。     业务权限数据库保存权限数据、角色数据、角色权限数据、用户权限数据、用户角色数据。     用户数据库保存用户数据、用户组织结构数据。   什么是用户凭证？     用户凭证就是唯一识别用户的标识，通常是用户ID，用户凭证要求任何相同的用户有相同的用户凭证，任何不同用户有不同的用户凭证，用户凭证一旦生成不能重用。使用UUID作为用户凭证是一种可靠的方法，数据库的Sequence也是不错的选择。        权限管理如何独立于业务逻辑？     以往的设计中权限管理都是与业务逻辑密切联系的，并且经常作为一个整体来设计，权限管理之所以能独立于业务逻辑，得益与RBAC权限管理理论，参考 http://csrc.nist.gov/rbac/     在RBAC中，权限的四个主体是用户、角色、资源、操作，他们之间的关系为：     用户隶属某几个角色，资源和操作成对组成权限，权限分配给角色实现权限控制。     业务系统的所有功能可以分解为操作-资源集合，也就是权限集合，权限管理只需要管理这个集合，而不再需要理解业务逻辑本身，所以权限管理可以独立于业务逻辑。     权限管理既然独立于业务逻辑，所以可以灵活部署权限管理。     通常有集中式和分布式两种。 集中式部署将权限管理部署在一个独立的地方，所有业务逻辑共用一个权限管理，因为权限由资源和操作组成，所以通过的不同业务附加资源和操作前缀，可以避免业务系统间权限混淆，集中部署能集中管理，提高管理效率，但是当存在大量的业务系统时，需要很好的分类设计才能区分各个业务系统，增加设计难度。     分布式部署将权限管理同业务逻辑一起部署，这样每个业务系统有单独的权限管理系统，有业务系统增加时，通过增加一个入口连接可以方便转向权限管理，当业务系统分布在各个地域时，这种方式比较有效，但是权限管理本身程序有更新时，要同步到各个系统需要很大的开销。     不管何种部署方式，因为权限管理程序都相同，唯一不同的是权限数据库，所以更改部署方式只要改变数据库指向，开销很小。   业务逻辑如何实现权限控制？     业务逻辑可以分为受保护资源和不受保护资源两种，不受保护资源不需要权限控制，用户访问受保护资源时，需要先确定用户身份，然后验证用户权限，流程图如下：     访问保护资源时，业务逻辑先询问登陆代理是否当前存在登陆凭证，如果不存在，则要求登陆代理定向到登陆服务验证用户，获取用户凭证。业务逻辑得到用户凭证后，要求权限验证验证该用户是否具有访问权限，如果有，则允许用户访问该保护资源。   权限管理如何实现权限控制？     权限管理本身也是一种特殊的业务逻辑，所以具有与业务逻辑相似的权限控制流程。   用户管理如何实现权限控制？     用户管理本身也是一个业务系统，所以具有一般业务系统的结构，不过业务逻辑数据库和业务权限数据库合并成了用户数据库，而权限管理直接引用用户管理的业务逻辑。     用户管理的权限控制流程类似一般业务系统权限控制流程。   如何实现SSO（单点登陆，Single Sign On）？     单点登陆在用户切换到其他业务逻辑的时候不需要重复登陆，改善用户体验感。     如果将登陆服务独立部署成一个web应用程序，登陆代理随业务逻辑一起部署，多个业务逻辑共用一个登陆服务，即可实现单点登陆。     因为登陆服务共用，所以多个业务逻辑共享一个用户数据库，在一个业务系统上能登陆的用户，在其他业务系统上依然能登陆，并且任何用户登陆过程最后都是在同一个登陆服务器上验证用户信息，所以可以把已经登陆的用户状态通过COOKIE等方式保存起来，下次其他业务系统请求登陆时，可以首先检查COOKIE，如果已经登陆则不在要求用户输入验证信息。     用户先访问业务逻辑1，通过登陆代理1登陆，登陆代理1转发到登陆服务，登陆服务发现COOKIE没有登陆信息，则提示用户输入验证信息，核对成功后返回用户凭据到登陆代理1并且附带COOKIE标志用户已经登陆。     然后用户访问业务逻辑2，通过登陆代理2登陆，登陆代理2转发到登陆服务，登陆服务发现COOKIE有登陆信息，表明用户已经登陆，直接返回用户凭证到登陆代理2。     使用SSO方式以后，用户管理同登陆服务一样单独部署，这样另一个好处是管理方便。   如何实现企业联合认证？     企业联合是指用户在企业合作伙伴的业务系统间切换时，不用重新登陆，并且各个合作伙伴保存自己的用户，这些用户能在其他合作伙伴的业务系统上登陆。     首先企业合作伙伴要能区别各自企业的用户凭证，使用UUID或数据库Sequence表示用户凭证可能会导致不同企业的用户凭证冲突，所以应该把企业标识作为用户凭证的一部分。     其次企业合作伙伴间要相互信赖对方的用户凭证，需要使用企业证书对用户凭证进行数字签名。     最后是用户登陆验证的转发，因为企业标识作为用户凭证的一部分，所以如果用户是首次登陆，登陆服务可以通过企业标识转发登陆请求到对应的合作伙伴的登陆服务器，如果用户已经登陆，通过COOKIE等方式获取经过签名的用户凭证后，使用企业标识的企业证书验证该用户凭证，验证通过即可信赖该用户的登陆状态而不用再转发到合作伙伴的登录服务器。