用户管理手册

用户管理手册

系统术语

用户

系统的使用者一般称为用户，用户登陆后，系统经过各类标识赋予用户操做和查看权限。

后台须要对用户帐户、操做权限和数据权限等进行管理。用户管理贯穿业务各个环节，是支撑业务运营的核心部分。

系统用户通常分为内部用户和外部用户。这种区分是从平台运维角度出发，平台运维公司的员工称为内部用户，其余用户称为外部用户。

外部用户

• 外部用户隶属关系比较复杂，有的挂靠在某公司之下，无需注册，由系统管理员分配帐户。

• 有的则以独立个体存在，例如：钉钉，以独立个体注册，公司邀请员工，员工赞成后才有了归属。

• 第三种状况是用户以独立个体注册时选择所属公司，这种方式存在两个问题：

1. 用户随意选择企业，不能保证准确性；

2. 是否要在后台维护企业基础数据，不维护的话，没法统一数据源，维护的话，不能覆盖所有注册用户的企业。

选择哪一种方式，须要根据实际业务状况进行设计。

例如

目前平台的服务对象是门店销售员，因为业务冲突，平台没法得到企业级的合做，前两种状况须要隶属公司在平台上进行操做，只能选择第三种方式，用户以独立个体注册平台，并填写所属企业。

为避免第三种方式存在的问题，作以下处理：

1. 用户注册填写企业，无需选择基础数据；

2. 后台维护企业基础数据；

3. 用户审核时，有平台客服人员选择企业基础数据。

这样既减小了用户操做的繁琐，平台又能得到精准的数据。

内部用户

内部用户也有归属，旧有的平台添加员工时选择归属，在员工管理菜单下展现为员工列表，这样作须要提早维护组织机构，频繁切换菜单。

像钉钉、企业微信等，在维护员工时，按照公司的组织架构进行维护，在同一页面完成部门和员工的添加，层级关系清晰（见下图）：

内部用户通常无需注册，由系统管理员分配。分配的帐户能够是字符串，也能够是员工的手机号码。

角色与权限

每一个帐号，都被赋予了特定的角色；而每一个角色的背后，都有其对应的权限信息。

经过RBAC权限管理模型，用户可按照实际业务的须要分配不一样的角色和权限，在共享一个软件平台的基础上，实现不一样用户的不一样功能。

权限的赋予分为自动赋权和手动赋权两种。

外部用户的自动赋权通常是帐户有默认的基础权限，要想得到更多的权限须要另外开通；内部用户的自动赋权，通常是把角色与行政关系下的部门创建绑定关系，用户进入到该部门后，帐户自动被加入到对应的角色中，而且拥有该角色全部的权限。

手动赋权没法经过用户行政关系自动绑定来实现，须要手动创建角色赋予给帐户。

例如：要求客服专员只能看分到本身名下的客户，上级领导看所有下级的客户，经过两种方式实现：

1. 一是经过组织机构的上下级归属自动赋予数据权限；

2. 另一种用数据角色，实现跨部门查看数据。

另外，角色能够继承，子帐户继承父系角色的权限。例如：赋予某企业级外部用户admin某些权限，该企业下的其余子帐户只能从admin权限中选择可用权限。

权限依据属性可分为操做权限和数据权限。

操做权限会从功能菜单、功能操做两方面考虑，角色勾选上菜单和功能，拥有该角色的帐户便可操做相应的菜单和菜单下的操做（例如新、增、改、查），分配操做权限页面见下图：

数据权限会从菜单、列表及数据字段三个颗粒度考虑：

1. 菜单是最粗颗粒度的数据权限，得到受权便可查看该菜单下的所有数据；

2. 列表是较细颗粒度的权限，不一样角色的用户进入同一菜单页后，查看的列表字段相同，但量级不一样，例如上面描述的员工看本身的数据，领导看所有员工数据；

3. 数据字段是最细颗粒度的权限，不一样角色的用户进入同一菜单页后，可见的数据字段有差别，这些字段共存在一个菜单页中，只是受限于不一样的角色权限。

单点登陆

平台会涉及多个应用系统，例如：合同管理、资金管理、小程序管理、兑换商城等，可经过单点登陆（SSO）。

在多个应用系统中，实现登陆一次就能够访问全部相互信任的应用系统。

应用系统加入了单点登陆协议，管理用户账号的负担就会减轻，实现应用系统的用户、角色和组织机构统一化管理。

要实现SSO，须要：

1. 统一集中的用户身份管理系统。全部应用系统共享一个身份认证系统，用户登陆时，信息和用户信息库相比较，对用户进行登陆认证；认证成功后，认证系统生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。

2. 全部应用系统可以识别和提取ticket信息。应用系统对ticket进行识别和提取，经过与认证系统的通信，自动判断当前用户是否登陆过，从而完成单点登陆功能。经过基于互联网协议的单点登陆、登出体系实现用户不一样应用系统间身份一致性，实现信息空间身份一致性。

不管是外部用户，仍是内部用户管理，都涉及到帐户、角色和权限的管理。

本文从自身经验出发，总结了各个环节须要注意的地方，另外单点登陆涉及到用户管理，贯穿整个平台，此部分技术人员参与的比较多，本文只作了简要的总结。

用户管理系统最难的是后续的维护，系统中每每会出现不少冗余的角色，这都须要慎重思考，和业务沟通清楚后再作调整。

用户系统模块架构

用户管理模块架构以下：

整个模块为用户管理，下分三块分别是：

• 部门组织架构：

  全部部门人员信息的在线展现以及对应的人员列表，此处同步公司域库数据，附加了当前在线状态的显示；

• 角色权限管理：

  此处分为角色组的创建以及对应权限的把控，角色组以及所属成员按需建立和添加，建完以后对应作权限的控制，包含功能权限、资源权限、数据权限、集成系统的访问权限；

• 权限申请管理：

  此处是针对权限管控后，用户对无权限资源进行的权限申请处理以及对应的权限赋予操做（权限批复结果会自动生成消息通知，与公告消息相通）。

用户管理

帐号管理，是管理员最经常使用到的功能。这一模块，须要设置相应字段，对内部人员的信息进行管理，首先应该具有“新增”、“删除”、“编辑”这三项基础的操做功能。另外一方面，考虑到部分企业存在内部奖惩机制， 对某项指标不合格或者行为违规的员工， 作出暂停使用帐号的处理结果，所以，在上述三项基础操做功能以外，能够再增长“禁用”和“启用”的功能。

帐号列表

帐号列表应该优先显示重要的字段，好比ID、用户名、真实姓名、部门、角色、帐号状态、注册时间等。固然，除了这些，后端还须要记录下用户的其余字段，好比最近登陆时间、登陆次数等等操做记录。以下图：

添加帐号

当管理员点击“新增”按钮时，当前页面能够跳转到填写帐号信息的页面， 也能够经过弹窗的方式出现。新增帐号的字段应当尽可能详细，以便未来对用户行为作统计分析。同时在这个阶段，咱们能够经过判断用户的身份，来给他赋予相应的角色。在这一步，不须要配置权限，由于角色自己就是带有权限的。以下图：

角色管理

角色管理部分，是用来管理内部用户的角色信息。角色，是对具备共同特征的某一类人群的身份概括，在这个模块里，咱们须要设置一些字段来描述角色信息，下降学习成本，让管理员可以轻松识别角色的特质，从而为不一样的用户赋予对应的角色身份。

角色列表

角色列表相似帐号列表，也是将一些重要字段展现出来，让管理员可以很快的了解角色的相应信息，好比角色ID、角色名称、基本权限、操做权限等。当基本权限和操做权限很是繁杂的时候，能够只显示重要的几类，其余的详情，能够点击查看。

在角色列表，只需保留“新增”和“删除”功能，“搜索”功能也能够不须要，由于角色的种类一般比较少，不然会给管理员增长负担。以下图：

新增角色

“新增角色”和“编辑角色”，都是给角色赋予相应的权限。过去我在给角色配置权限的时候，使用过下拉菜单的方式来选择。但若是碰到权限很是繁杂的状况，下拉菜单就不太适用了。这个时候，能够将权限都罗列出来，能够分组排序，也能够默认所有选中，而后让用户根据需求去勾选掉不须要的权限。以下图：

权限管理

权限管理这部分，是逻辑性最强的一块，须要提早准备好一份权限清单，将权限的名称、描述、性质（基本/操做）等信息梳理清楚。

权限列表

在作权限梳理以前，必定要与开发人员沟通好，肯定哪些权限是同类型的，能够归为一组，而哪些功能又必须是分开设置的。拿我以前作的这个项目为例，这个产品没有涉及工做流环节，但Boss想让不一样角色的用户，看到不同的界面，因此除了一般的操做权限划定以外，还有一些基础的菜单查看权限，也要细分。固然了，由于权限细分起来很是繁杂，因此权限列表还须要有分页的功能，也能够加上搜索功能。以下图：

新增权限

“新增权限”页面，是为开发人员设置的，开发人员能够在这里将代码内容录入。具体以下图：

以上介绍的用户管理三大模块，是专门针对后台系统设计的，面向的用户也是企业内部人员，从产品需求上来讲，追求的是规范、标准和流程化。

如何作好角色赋权

自动赋权：用户自动进入角色

若是角色与行政关系下的组织部门存在绑定关系，那么若是一个用户进入到该组织部门后，该用户会自动被加入到对应的角色中，而且拥有该角色全部的系统权限。如一个财务人员【小张】入职财务部后，那么该用户无需进行额外的受权便可在对应财务报表系统查看该部门员工可查看的财务数据报表和对应的操做权限（好比操做财务审批等）；

角色赋权：用户被添加进角色

业务是不断创新和发展的，随着业务的发展，会有愈来愈多的新的角色被设置和建立，好比公司新启动了一个企业团餐项目，项目部横向的从各个部门找了多个员工组建项目团队，而且该项目的业务权限也只是受权给这批员工可查看和操做，那么，在此项目中，会产生一个新的角色 “ 财务1 ”，系统高级管理员会把从财务部门选中的财务【小张】添加到“ 财务1 ”这个角色中，那么【小张】便可得到查看企业团餐项目业务数据报表和操做的权限。这种权限的授予没法经过用户行政关系的自动绑定来实现；

角色继承：角色权限的继承

权限能够是独有的，也能够是继承的。每一个角色都有本身的权限集，角色继承其实也就是继承父系角色的权限，通常角色在继承其父系角色的所有权限的基础上增长拥有一些本身的权限。而系统角色继承每每存在于用户分级管理比较明确的团队或者公司；

角色互斥：角色包含的权限互斥

角色互斥的业务背景：当一个业务流程因为风控的缘由，须要将其操做给划分红分开的几个步骤时，须要给这几个不一样的步骤受权不一样的角色，而且这些角色之间须要进行互斥。好比大额财务报销审批流程，财务人员【小张】拥有了审批人权限后，就没法将审核确认的权限再授予小张，以此来规避一我的完成大额报销而带来的财务风险；

临时角色：给特殊客户临时身份

临时角色每每是针对特殊群体设置的，好比公司有特殊访问团队莅临，须要给这些特殊的客户一些临时身份来体验某些功能操做。那么把这些人添加到部门的组织架构中显然是不合适的，由于这些人只是临时的摆放者，不是企业员工；其次，这些客户须要体验的功能操做每每是横跨多个业务模块和产品线的（比较繁杂），通常公司并无现成的固定角色符合拥有客户所需的所有操做权限，所以须要给这些客户开设临时角色，而且支持给临时角色最大的权限选择空间；

黑白名单：

如何作好权限系统

上述组织架构和权限申请部分基本很容易理解，逻辑相对复杂一些的当属角色权限管理这部分，先看一张关系图：

作好权限管理有如下几个重点：

1. 人员组成要灵活

这部分的人员组成不必定是按照岗位角色来的，有多是跨部门跨岗位造成的自定义角色组，所以不能直接套用以前的岗位角色，须要能够建立新的角色组，固然角色组多了还能够给角色组分大类，以便更清晰一些。

2. 权限覆盖要全面

权限常规来讲能够分为功能权限、数据权限、资源权限，固然根据产品不一样也可能有更多的权限分类。大到每一个顶部导航模块，小到页面上每一个功能按钮，都属于权限的范围。与此同时资源内容的全量呈现仍是部分呈现就涉及到资源权限的管控；有的数据我能访问，你不能访问，这种权限的区分把控在于数据权限的设置。

在上述案例中，咱们的数据权限采起的是黑名单制，顾名思义就是我选择谁不能看到哪些数据，默认状况下是全部人能够看到全部数据，这个能够根据具体状况进行正反向设计。

好比大部分都是可看的，不可看的是少数，那么就用黑名单方便一些；若是大部分都是不公开的，只有少数是公开的，那么白名单会更方便一些，因状况而异。

3. 权限把控要灵活

正常来讲角色权限管理对于一个须要此方面把控的产品来讲就像空气同样不可或缺，虽然咱们不常注意它的存在，可是用的时候必定要确保其规范、安全、可靠。

以前咱们在作的过程当中有过这样的一次经历，通常被赋予了某个角色的人员具备把私有表转为公共可见表的权限，而对应的删除操做，当时开发则作成了谁建的表谁删除，其他人即便有一样权限也不能进行删除这样的模式。

在一次不经意操做中咱们发现共同拥有这个权限的人删除不了别人建的公共表，我跑去告诉同事说这张表是他建的，须要他删除，而后我就去了洗手间，但顿时感受这样的逻辑存在问题，假使十我的建了十张表而后都转为公共表了，那么若是这十我的离职了，这些表还非这些帐号不能进行删除操做了吗？（不包含开发同事从数据库删除的状况，由于咱们设计产品的最终目的就是减小进行数据库的操做，最大化方便使用而且逻辑合理）

所以意识到这一问题后，咱们小组当即进行了讨论而且及时作了更新。虽然这样也存在不是表的主人删除他人表的可能性，但一般来讲：

第一，这样的状况相对较少；第二，对应的解决方案是能够经过把删除表的功能只赋予一个最高管理员，其他角色不能随意操做，这样来管控。总之要保证权限把控的灵活性，这是第一原则。

实际状况其实更复杂一点，由于咱们还涉及私有表可删除（全部人都有的功能）、可移动到公共表（部分被赋予权限的人员具备的功能，无权限人员不显示此操做按钮）；公有表的查看（全部人都具备的功能）、公有表的删除（部分被赋予权限的人员具备的功能，无权限人员不显示此操做按钮）等，那天原本约了人，但为了调这个并和开发讲清楚，赴约都临时取消了（捂脸）。

4. 权限申请要智能

权限申请其实和以前的权限把控是对应的，有的权限是把控以后，相应用户看不见被屏蔽的痕迹，也没有申请入口，而有的能够作成暂无权限的提示，同时提供申请入口。

在上述案例中，咱们在部分屏蔽场景中提供了权限申请的入口，当用户点击申请后，会自动在后台接收一条权限申请的消息，上面显示申请人基本信息、申请源、申请时间以及批复操做（经过/拒绝），具体的申请处理流程以下图：

在这块令我比较欣慰的一点是咱们的技术同事把权限开通作的相对智能化了一些，即在经过权限申请的时候，相继会产生2条动做：

• 一个是在上述的角色权限模块自动开申请用户开通相应权限（包含功能权限、数据权限和资源权限）；

• 另外一个则是在开通流程走完以后把申请反馈通知发送到该用户的消息帐户，这两个任务完成后，即权限申请“经过”，整个流程基本在1秒内完成。固然即便开放后的权限将来也有可能被收回，因此这块的灵活性是毋庸置疑的。

外部用户管理

用户信息管理是客户关系管理的底层基础。

用户接触一款新产品，从开始了解，深度使用，最后到流失，整个过程会产生大量的数据信息流动，经过对这些用户信息的高效管理，能够指导用户分群、个性化消息推送、生命周期管理和关联推荐等一系列运营策略。用户信息的最大化的合理利用，可以更精细为用户提供服务，有效的达成业务目标。

在用户信息中包含了用户从注册到注销在平台产生的数据，包含用户的基本信息，帐号信息，订单信息，统计信息，收货地址信息，等其余信息。

基本信息：包含用户的帐号ID，注册来源，手机号码，性别，会员级别，城市地区，头像，昵称等

基础信息是描述客户基本属性的静态数据，主要来源于用户注册和使用时录入的信息。用户基础信息通常经过电商CRM系统的会员信息库进行存储和管理，会员信息库就比如存放着平台每一位用户的名片夹。

用户的基础信息字段繁多，大体能够归为六大类：

1. 人口属性信息：用户的姓名、性别、年龄、生日、所在省市区街道、婚姻状况；

2. 平台属性信息：昵称、注册时间、会员类型、会员等级；

3. 联系信息：手机号、邮箱、QQ、微信、微博、其余第三方关联帐号；

4. 收货信息：默认与非默认收货姓名、收货地址、收货电话；

5. 卡与支付信息：会员卡信息、银行卡信息；

6. 认证信息：在校认证信息、营业执照认证信息、消费贷认证信息等。

帐号信息：帐号信息包含用户的支付帐号信息若平台自有支付系统，则能够展现用户绑定的银行卡信息（隐藏部分）

订单信息：订单信息包含用户全部的订单，好比用户历史订单，待支付订单等等，在订单列表中须要将该用户下的全部拉取出来。

收货地址信息：收货地址信息则显示用户的收货地址，收货人，联系方式等。

行为信息是用户使用产品时产生的动态数据，主要来源于系统的事件埋点与后台日志：

· 事件埋点对用户的行为事件进行了全流程的记录，再经过各类页面来源（source）进行相互关联，能够详细记录用户的行为路径。

· 后台日志记录了交易信息，包括订单id、商品id、货号、单价、颜色、尺码等记录、经过“时间戳”来证实发生时间。

经过用户完整的行为信息，咱们能够还原最完整、真实的交易场景：

· 用户是谁：目标用户、用户画像、是否源于其余用户分享；

· 买了什么：商品品类、风格、件数、颜色、尺码、价格、上市时段；

在哪发生：线上的模块、页面、路径；线下的城市、商圈、地址、店名。

行为信息能够间接反映用户的行为偏好和决策路径，经过自建数据分析平台或第三方分析工具进行系统化的管理，能够为具体业务方案提供可靠的数据依据，带来可量化的指导。

基于行为信息的生命周期管理

基于用户在平台的消费记录，能够按照用户是否使用过产品来划分为新用户与老用户；老用户还能够根据用户使用产品的状况，按生命周期划分为留存用户、沉默用户和流失用户，举一个简单划分方式：

· 未激活新客：注册了产品以后，尚未正式使用（如电商的首次下单）的用户；

· 留存用户：在指定一段时间周期（如30天）内有使用过产品的用户；

· 沉默用户：对使用产品的积极性降低，连续一段时间周期（如30~60天）未使用产品的用户；

· 流失用户：曾经使用过产品，如今已经连续很长一段时间（如61天以上）没有再使用过产品的用户。

会员权益模块

在会员权益模块展现了会员权益的获取与注销的规则及会员权益规则的修改与新增。由于不一样业务形态不一样用户层因此会员模块的设计具备较高的灵活性，本文不作展开。

会员权益设置：包含会员级别设置，升级设置，降级设置等等。

会员权益展现：这里则是设置好的会员权益展现。好比会员升级条件等等。

RBAC权限设计模型

（Role-Based Access Control，基于角色的访问控制），就是用户经过角色与权限进行关联，从而得到某些功能的使用权限。权限被赋予给角色，而不是用户，可是一个用户能够拥有若干个角色，当一个角色被赋予给某一个用户时，此用户就拥有了该角色所包含的功能权限。简单地说，一个用户拥有若干角色，每个角色拥有若干功能权限。这样，就构形成“用户-角色-权限”的受权模型。在这种模型中，用户与角色之间，角色与权限之间，通常者是多对多的关系。以下图：

· 用户：成功认证并登陆系统的操做员（主体：who）

· 权限：访问资源的许可（how）

· 角色：权限的集合体

· 资源：引入这第四个概念，包括系统菜单、页面、按钮等（what）

4A模型

4A模型

是指：认证Authentication、帐号Account、受权Authorization、审计Audit，中文名称为统一安全管理平台解决方案。即将身份认证、受权、审计和帐号（即不能否认性及数据完整性）定义为网络安全的四大组成部分，从而确立了身份认证在整个网络安全系统中的地位与做用。

附录

1. 一个用户拥有多个角色，多角色之间若是存在互斥关系如何处理？

若是一个用户已经被添加到某一角色范围下，那么，当给该用户添加一个与当前角色存在权限互斥关系的角色时，系统会进行互斥性判断，后面的角色就没法给该用户添加成功；

2. 业务发展过程当中，如何保证不一样角色之间权限拆分清晰？

随着业务的快速发展，必定会不断新增不一样的角色和更多的功能模块，并且这些角色和功能权限之间的关系也会日益混乱，这个时候须要产品经理和业务方一块儿，及时的面对业务的发展变化，及时、快速的梳理业务调整范围，做出对应的改变；

3. 用户权限管理系统核心难点是前期的产品设计吗？

用户权限管理系统核最难的不是前期的产品设计，而是后续的运营维护，由于权限系统的结构每每不会随意变动，可是随着业务发展快速出现的角色和功能模块，为了防止角色和功能权限之间的关系变得混乱，在创建新的角色和分配权限的时候须要思路清晰且慎重调整。