# presentable授权业务逻辑实现过程

# C端消费者授权流程

1.授权服务检测用户是否与presentable签订合约,并且合约设置为默认执行态.

2.如果授权服务检测结果为否,则遍历当前presentable的授权策略,如果有任意策略能通过免费策略授权检测,则系统自动隐式为消费者创建合约.否则终止授权,返回未找到可用合约错误码.

3.如果授权服务检测结果为是,授权服务则继续检测当前默认执行合约是否依然满足合约的身份限制部分.如果不满足,则终止授权,返回身份授权失败错误码

4.授权服务继续检测当前默认执行合约的状态机部分,如果合约当前状态未获得active授权.则终止授权,返回合约未激活错误码

5.以上4条检测通过,则C端消费者合约获得授权,授权服务会进行presentable与源资源之间的授权.

6.特别说明:如果当前不存在登录用户,则授权服务直接遍历检测presentable的授权策略中是否存在免费的授权策略,如果存在,则通过消费者合约部分授权.

流程图如下: avatar

# 节点资源授权流程

1.授权服务根据presentable检索得到presentable的授权树数据(数据结构后面说明).然后把授权树数据分为节点-资源合约和资源-资源合约两部分

2.授权服务遍历节点-资源合约的当前状态,检测是否获得active授权,如果有任意合约未获得active授权,则终止授权,返回节点与资源的合约未激活错误码

3.授权服务遍历节点-资源合约的身份限制部分(节点是否符合身份限制).如果有任意合约不满足身份授权.则终止授权,返回节点与资源的合约未获得身份授权

4.授权服务遍历资源-资源合约的当前状态,检测是否获得active授权,如果有任意合约未获得active授权,则终止授权,返回资源与资源的合约未激活错误码(此错误节点已经无法处理,属于上游违约)

5.授权服务遍历资源-资源合约的身份限制部分(合约的乙方是否符合身份限制).如果有任意合约不满足身份授权.则终止授权,返回资源与资源的合约未获得身份授权(此错误节点已经无法处理,属于上游违约)

6.以上检测如果通过,则整个presentable授权链通过授权.

流程图如下: avatar

# 授权方案详细说明

1.根据freelog的业务设计原则,每一个资源都允许存在多个授权方案.

2.每个授权方案主要包含声明部分,上抛部分以及策略部分.

3.声明部分和上抛部分的数据来源于其主体所依赖的资源的授权方案.在创建授权方案的过程中,由资源作者主动选择处理与不处理的部分.依赖树也是在这个时候逐步转变成授权树.

4.授权方案选择不同的声明与上抛,则对应的授权树也会发生变化.但是授权方案对应的主体资源的依赖树则在资源创建时就已经确定.

5.依赖树主要是体现出资源的实际依赖物理结构,授权树主要体现的是依赖树上不同的节点之间的合约授权关系.

6.依赖树上的各个节点由多个不同角色和身份的用户各自承担部分授权,从而完成整个依赖树的授权.用来记录不同节点之间的授权部分的数据,称之为授权树

# 授权树演变过程说明

下图所示为资源的依赖树: avatar

A.假设所有的资源的资源都有且只存在一个名为AN1的授权方案,并且授权方案中全部处理掉所有依赖,零上抛资源.则所有复合资源的AN1授权方案对应的授权树与其依赖树结构一致.

B.假设以后A1资源新建一个名为A1-AN2的授权方案,并且授权方案选择声明处理A2,上抛B2和C2. 然后A资源也新建一个名为A-AN2的授权方案,并且在依赖处理上选择A1-AN2,B1-AN1,B2-AN1,C2-AN1,C1-AN1(零上抛),则A-AN2的授权树结构如下 avatar

C.假设以后D2资源新建一个名为D2-AN2的授权方案,并且声明处理A3,上抛C2. 然后B1资源也选择新建一个B1-AN2的授权方案.并且在依赖上选择了A2-AN1,D2-AN2,C2-AN1(零上抛),则B1-AN2的授权树结构如下 avatar

D.假设以后A资源新建一个名为A-AN3的授权方案.并且在依赖处理上选择了A1-AN2,B1-AN2,B2-AN1,C2-AN1,C1-AN1(零上抛),则A-AN3的授权树结构如下 avatar

E.假设资源B1以后新建一个名为B1-AN3的授权方案,并且在依赖处理上选择了A2-AN1,D2-AN2,然后上抛了资源C2,然后资源A也新建了一个名为A1-AN4的授权方案,并且在依赖处理上选择了A1-AN2,B1-AN3,B2-AN1,C2-AN1,C1-AN1(零上抛),则A-AN4的授权树结构如下 avatar 此时我们发现资源A1-AN4在依赖上存在重复的依赖C2,然后系统进行了合并处理.只需要签约一次即可.

F.为了方便查看演变过程,上面图例中授权树使用的是资源名称作为标记.真实的授权树其实标记的是资源的授权方案.因为只有授权方案中的上抛才会发生变动.条件E的实际授权结果为 avatar

G.授权树的实际数据结构即把F的图例转变成数据存储.授权服务根据授权树结构中的授权方案ID获得当前方案下声明以来时绑定的合约.然后对合约授权即可.大概数据结构如下

[{
		"authSchemeId": "A1-AN2",
		"resourceId": "A1",
		"parentAuthSchemeId": "A-AN4",
		"deep": 0
	},
	{
		"authSchemeId": "B2-AN1",
		"resourceId": "B2",
		"parentAuthSchemeId": "A-AN4",
		"deep": 0
	},
	{
		"authSchemeId": "C2-AN2",
		"resourceId": "C2",
		"parentAuthSchemeId": "A-AN4",
		"deep": 0
	}, {
		"authSchemeId": "B1-AN3",
		"resourceId": "B1",
		"parentAuthSchemeId": "A-AN4",
		"deep": 0
	}, {
		"authSchemeId": "C1-AN2",
		"resourceId": "C1",
		"parentAuthSchemeId": "A-AN4",
		"deep": 0
	}, {
		"authSchemeId": "A2-AN1",
		"resourceId": "A2",
		"parentAuthSchemeId": "A1-AN2",
		"deep": 1
	}, {
		"authSchemeId": "A2-AN1",
		"resourceId": "A2",
		"parentAuthSchemeId": "B1-AN3",
		"deep": 1
	}, {
		"authSchemeId": "D2-AN2",
		"resourceId": "D2",
		"parentAuthSchemeId": "B1-AN3",
		"deep": 1
	}, {
		"authSchemeId": "A3-AN1",
		"resourceId": "A3",
		"parentAuthSchemeId": "D2-AN2",
		"deep": 2
	}
]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49