软件系统三基座包含:权限管理、组织架构、用户管理。
何为基座,即是有了这些基础,任一相关的“建筑”就能逐步搭建起来。
万丈高楼平地起
权限管理,一般指根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源。只要有用户和密码的系统,几乎全有权限管理。
产品经理的品质追求和项目的里程碑交互是矛盾的,让产品经理管项目,可能项目没有终结点;
程序员的逻辑严谨和市场的变化多端是矛盾的,让程序员去做市场销售,可能团队没有太多收益;
授予管理的权限,同时也是一份责任。费用的报销和预算消耗所剩无几是相关联的;打市场需要团队成员全员硬刚和请假审批松散导致身边无人可用是有前因后果的。
市场部的日常执行信息不断反馈给采购部,会极大地消耗采购部的精力;
战略规划部的规划调整随时更新给一线执行人员,会极大地摧毁公司整体的稳固度。
某某程序员删库跑路了;某某销售代表携客户资源跳槽了...此类事项屡屡出现,这总是前人血泪教训;
软件系统三基座包含:权限管理、组织架构、用户管理。按照系统管理的设计,交互如下图所示。
以用户管理为例,需要支持最基础的增删改查操作,即是添加用户、编辑用户、删除用户、查询用户。
以现实业务情况,系统用户的增加包含用户注册或管理员添加。对于其他系统用户来讲,用户管理这一块与自己无关,不必查看。就需要做权限管控。
权限管理和现实中的开锁相似。首先需要了解哪些地方需要加锁,公园就不需要加锁,即是权限点注册;其次是在需要加锁的地方放上锁,并给需要的人发放钥匙,即是授权;最后则是有钥匙的人拿着钥匙开锁,没有钥匙则在封锁区域之外,即是鉴权。
哪些地方加锁 = 权限点注册
上锁并发放钥匙 = 授权
拿钥匙开锁 = 鉴权
权限点注册是软件哪些功能需要做权限控制,就添加到权限控制的列表中。注册成功后,权限点树形结构展示,如下图所示。
权限点注册支持树形结构,也就是没有授权“用户管理”时,不能授权“删除用户”。权限点还可以细分按钮权限、URL权限,按钮权限控制页面上是否可见,URL权限控制按钮的交互是否能执行。一般的情况下,对同一个操作需要既授予按钮权限,又授予URL权限。若存在系统间接口数据交互的情况,不需要页面交互,就不必授予按钮权限。
权限管理作为底层支持,可扩展更多模块、更多应用的管理。在三基座授权管理的基础上,增加产品管理,则权限点注册后如下图所示。
授权管理就是针对不同的用户授予不同的权限,也就能让不同的用户看到不同的软件部分。
如图所示,给用户A授权“ 添加用户、编辑用户、删除用户、查询用户”权限;给用户B授权“查询用户”;两个用户相比较而言,用户B就只能查询用户,相当于获取用户信息,则不能进行用户信息的编辑、修改。
两个用户都没有授权“用户授权”,则两个用户都不能修改用户的权限信息。
用户授权信息均由系统超管员(一般为admin账户)授权分发下来。
用以上含产品管理的系统进行授权管理,则可授权两大类,一类是A:系统管理,有权限管理、角色管理、用户管理权限,适用于人事;一类是B:产品管理员,有产品管理权限,适用于市场部人员。
A 人事
B 产品管理员
鉴权则是应用自己的权限去打开对应的系统功能。如上面授权举例,系统管理员A、产品管理员B则看到不同的系统功能。
系统管理员 A
产品管理员 B
在实际业务中,常存在新人入职,或在岗人员调岗的情况。若依旧使用给人员授权的情况,让整个操作变的复杂。
用户直接授权
如图所示,需要新人入职授权,就需要给新人挨个去授权每个功能;需要调岗,就需要先删除原有的所有权限,然后再授予新的权限。
基于系统要能用、好用的原则,增加角色管理,如下图所示:
用户通过角色授权
如图所示,需要新人入职授权,就只需要勾选新人所属的角色;需要调岗,就只需要先去掉原先的角色,勾选上新的角色,整体操作简便更多。
随着人员变多,业务变复杂,系统功能更庞大,权限管理体系还需要调整。如上例,若新人是个特殊人才,除了通有角色的权限,还需要一个单独权限,就需要增加用户直接授权的能力。当然,也可以新建一个单独的角色,只有这一个特殊的权限来实现。这也正体现了现实业务的复杂性,没有最好的,只有最适合当前业务需要的。
在三基座的基础上,扩展了产品管理,但作为系统,功能远远不够。电商类的需要扩展,商品管理、订单管理、支付管理、活动管理、积分管理等等一系列的功能模块或应用。
权限系统具有以上能力,为系统扩展打好了基础。增加的应用,通过权限点注册,全部纳入权限管理的范围内。若权限系统把权限点注册、权限查询、权限校验开放成为OpenAPI,则能够兼容三方应用的权限管理。
支持三方应用的权限点管理,就能实现三方应用在较小的改造成本下,纳入系统下,为系统的融合扩展提供了支持。
权限点管理
添加权限点
天台十万八千丈,祥云送我上青天。
前行需要一架梯子,你在梯子上拉拉我,我在梯子上拉拉你。