基于RBAC的saas权限系统设计

先说RBAC，我相信大家对RBAC都已经很熟悉了，这里再简单的介绍一下

基于角色的访问控制（Role-Based Access Control）作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。

ATM 机的一天

假设有一台 ATM（自动提款机）放在街边，我们来看看这个 ATM 度过的一天。

1.    早上，有一个家伙走到 ATM 面前，对着机器说：“芝麻开门，芝麻开门，给我 100 块！”。很显然 ATM 不会有任何动作。失望之余，这个家伙踢了 ATM 一脚走了。

2.    中午，一位漂亮的 Office lady 走到 ATM 机面前，放入她的信用卡，输入密码后，取出了 1200 块钱。当然，这些钱很快就会变成一件衣服或是化妆品。

3.    下班时分，银行的工作人员来到 ATM 机器面前，放入一张特制的磁卡，然后输入密码。从中查询到 ATM 机器内还有充足的现金，无需补充。所以他很高兴的开着车去下一台 ATM 机器所在地了。

现在我们要开发一台具有同样功能的 ATM 机，应该怎么做呢？

首先，我们的 ATM 机不能让人随便取钱，不然银行会破产的。接下来，ATM 机需要一个让人们放入磁卡并输入密码的设备。人们放入磁卡并输入密码后，ATM 机还要能够判断这张磁卡的卡号和密码是否有效，并且匹配。之后，ATM 机必须判断磁卡的卡号属于哪种类型，如果是信用卡，那么则显示查询账户余额和取款的界面。如果是特制的磁卡，则显示 ATM 机内的现金余额。

ATM 与 RBAC

上面的例子显得有点荒诞，但是却是一个典型的基于角色的访问控制。

1.    对于没有磁卡或者输入了错误密码的用户，一律拒绝服务，也就是不允许进行任何其他操作；

2.    如果输入了正确的密码，必须判断用户输入哪一种类型，并提供相应的服务界面；

3.    如果用户尝试访问自己不能使用的服务，那么要明确告诉用户这是不可能的。

这个流程中，一共出现了两种角色：信用卡用户和管理卡用户。而那些没有磁卡的用户，都属于没有角色一类。RBAC 要能够工作，至少需要两个数据：角色信息和访问控制表。

角色信息通常是指某个用户具有的角色，例如你持有一张信用卡，那么你就具有“信用卡用户”这个角色。如果你持有一张管理卡，那么你就具有“管理卡用户”这个角色。如果你既没有信用卡，又没有管理卡，那么你就没有上述两种角色。

有了角色信息，RBAC 系统还需要一个访问控制表。访问控制表（Access Control Table）是一组数据，用于指出哪些角色可以使用哪个功能，哪些角色不能使用哪个功能。例如在 ATM 机中，具有“信用卡用户”角色，就可以使用查询账户余额和取款两项功能；而具有“管理卡用户”角色，就可以使用查询 ATM 机内现金余额的动能。

我们来模拟一次 ATM 机的操作：

1.    唐雷有一张信用卡，他放入 ATM 机并输入了正确的密码。这时，他被 ATM 机认为具有“信用卡用户”角色。

2.    根据上面的判断结果，ATM 机显示了一个操作界面，上面有查询账户余额和取款两项操作按钮。

3.    唐雷按下了“查询账户余额”按钮，ATM 机的查询账户余额功能被调用。

4.    在查询账户余额功能中，再次检查用户的角色信息，确定他可以使用这个功能。

5.    进行一系列操作，然后将唐雷信用卡账户上的余额数字显示到屏幕上。

6.    唐雷很郁闷他的信用卡又透支了，悻悻然取出卡走人了。这时 ATM 自动清除当前的角色信息，为下一次操作做好准备。

从上面可以看出，RBAC 充当了系统的一道安全屏障。所有的操作都需要进过 RBAC 验证过后才能使用。这样充分保证了系统的安全性。

上面的例子很好的展示了RBAC的作用；

我看网上有一堆关于RBAC的说法，和实现方式，但是分析一下做一个业务系统，需不需要那么多的功能；其实并不需要这里我只需要用户，角色，权限，资源，企业；

上面就是我实现的RBAC模型设计；简单来说就是一个用户拥有多个角色，一个角色拥有多个权限，这样构成了用户对应多个角色对应多个权限的关系；

SAAS的隔离级别：

SaaS多租户数据隔离的三种方案 
多租户技术或称多重租赁技术，是一种软件架构技术，是实现如何在多用户环境下共用相同的系统或程序组件，并且可确保各用户间数据的隔离性。在当下云计算时代，多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍可以保障客户的数据隔离。目前各种各样的云计算服务就是这类技术范畴，例如阿里云数据库服务（RDS）、阿里云服务器等等。

多租户在数据存储上存在三种主要的方案，分别是：

1. 独立数据库

这是第一种方案，即一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本较高。 
优点： 
为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；如果出现故障，恢复数据比较简单。 
缺点： 
增多了数据库的安装数量，随之带来维护成本和购置成本的增加。 
这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的。

2. 共享数据库，隔离数据架构 
这是第二种方案，即多个或所有租户共享Database，但是每个租户一个Schema（也可叫做一个user）。 
优点： 
为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可支持更多的租户数量。
缺点： 
如果出现故障，数据恢复比较困难，因为恢复数据库将牵涉到其他租户的数据； 
如果需要跨租户统计数据，存在一定困难。

3. 共享数据库，共享数据架构 
这是第三种方案，即租户共享同一个Database、同一个Schema，但在表中增加TenantID多租户的数据字段。这是共享程度最高、隔离级别最低的模式。 
优点： 
三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。 
缺点： 
隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量； 
数据备份和恢复最困难，需要逐表逐条备份和还原。 
如果希望以最少的服务器为最多的租户提供服务，并且租户接受牺牲隔离级别换取降低成本，这种方案最适合。

这里我采用的是第三种隔离级别，因为成本低，维护比较方便；

所以我们的每张表都会有一个标识，即企业ID；在我们做所有操作的时候都会去过滤这个企业ID；

原始企业：

这里原始企业指什么啦，指我们卖saas产品的公司，这里的企业所有权限都有，而且里面必须有一个超级管理员，这个管理员也会拥有所有权限，来给其他公司授权；

第三方企业：

这里我们把入驻企业称为第三方企业，这个第三方企业有自己的权限，但是他的权限是原始企业授予他的，原始企业下面的角色最多也只能拥有该企业的权限。