接口访问控制
默认的接口访问
create(POST),update(PUT)和delete操作需要cloud_controller.admin的权限范围(scope)
read(GET)操作,需要cloud_controller.admin的权限范围或用户已经登录
权限验证流程
默认的权限验证
这里讨论的都是基本的权限验证,在基类中定义的。
每一个API接口调用时,在业务方法调用前先从header的auth_token中解析了用户信息,放在当前线程的context中。
接下来,做接口基本认证检查
先检查是否当前接口是否需要认证
在每一个model的controller类中定义了可以不需要认证即可调用的接口,如:buildpack_bits_controller定义了download方法不需要认证
如果需要认证,则检查是否从auth_token中解析出了user,如果连user都没有就无从谈认证了
最后验证当前用户是否能访问该接口
如:
对于拥有cloud_controller.admin权限范围的用户,都通过
这里的admin_user是看是否拥有cloud_controller.admin权限范围
查看是否拥有read权限则是查看是否拥有cloud_controller.read权限范围
查看是否拥有create/update/delete权限则是查看是否拥有cloud_controller.write权限范围
具体接口的权限验证
具体的接口还可以自定义权限验证。
这里以app为例
从代码可以看出,create/update/delete/read_env都用了同样的权限控制:用户拥有cloud_controller.admin或者是space developer角色
图示
下面的活动图更清晰的描述了创建应用的权限验证流程
重要的几个权限验证说明
注意这里没有提到的则是用默认的规则
组织更新
需要有cloud_controller.admin权限范围或者Organization Manager角色
空间
创建、删除
需要有cloud_controller.admin权限范围或者Organization Manager角色
更新
需要有cloud_controller.admin权限范围或Organization Manager角色或Space Manager角色
用户
用户API操作在CF这边,权限都是默认权限控制, 但用户很多信息的修改都要调用uaa的接口,需要有scim相关权限范围
关于安全
CF这边从HTTP头中取出token后,CF这边直接用jwt协议decode token,然后把其中的签名部分和uaa的签名对比,如果签名正确,则信任token的其他数据,并没有调用uaa接口去验证其他数据(如:用户名、权限范围等)。
如果在uaa修改了用户的权限范围,client则需要重新获取token,CF不会主动更新token除非token已经过期,CF会认为token非法。