【微思探索】【实战】账号的身份设计和权限的主体设计

账号系统是一个网站不可或缺的系统，一个账号标识了一个用户。权限系统主要用于控制该用户拥有哪些权限，能访问到网站的哪些资源。

从另外一个角度讲，账号的主要概念是身份，权限的主要概念是主体。

什么是身份？

举个例子，一个人只有一个身份证，但是他会有多种身份identity存在，比如他的邮箱可以代表他的身份，他的手机和微信号也可以代表他的身份，某一时刻，他往往只会以其中一种身份存在。也就是说，多种身份其实对应的是同一个人。

什么是主体？

主体principal是一个赋权的概念，是权限的直接载体。我们赋权的形式有几种：

1.选择某个用户直接赋权；

2.选择某个组（比如班级组，或者兴趣群等等），对这个组进行赋权，然后将某个用户加入这个组；

3.创建一个角色，对该角色进行赋权，然后将这个角色赋给某个用户。

可以这么理解，主体其实就是上述的个人，组，或者角色的一个抽象。换一种说法，个人，组，或者角色都是主体。

强调这两个概念的主要目的是，账号系统的设计和权限系统的设计密不可分，有了这两个核心概念之后，其实我们的思路已经有些明朗，以后如果你要对账号系统和权限系统独立分开部署，我们的主要工作就是怎么关联身份和主体，用户和权限自然就连接在了一起。就算你的权限系统对接的是第三方的账号系统，思路也是很显然的，就是获取到第三方系统的身份信息，将其跟权限系统的主体关联起来就可以了。

由于一个用户会有多种身份，也就是说他可以手机登录，可以微信登录，可以邮箱登录，也可以其它很多方式登录，但最后对应的都是同一个人，同一个人只会有一个名字，一个身份证号码。但是不同的身份也会有不同的用户信息，比如微信号是微信这个身份特有的，邮箱地址是邮箱这个身份所特有的信息。从数据库表的设计考虑，identity(身份表)往往包含了以下几个核心字段，其它字段已省略：

所谓“login_id”，就是通常的手机号，微信号，邮箱地址等等；“realm”是login_id所在的范围，往往代表的是某种类型的身份。比如PHONE，WECHAT等等，"provider"是提供者，比如微信账号，realm可能是PHONE，也可能是WECHAT_NUMBER,但provider始终是WECHAT。

不同的身份会有不同的用户信息，所以设计用户信息表时往往会有一个owner_id:

每一个owner_id都对应一种不同的身份，相应的user_info记录就是该身份的信息。

权限中的主体principal表，是与identity的一个身份关联的，你可以对该用户的手机账号赋权，同时对他的邮箱账号作另外的不同的赋权，也就是说用户以不同的身份登录，他的权限是不同的。当然，你可以给用户设置一个主身份，只要针对主身份赋权，其它身份可以自动继承该主身份的所有权限，这样对用户来讲，所有登录账号的权限都是一致的。

以下是主体principal表的核心字段：

主键id是principal的id，identity_id是某个身份的id。

后续权限的其它表，比如权限表，组表，角色表其实都是跟principal表关联的，这里就不再阐述。

文章已收录在此：