CF权限控制

接口访问控制

默认的接口访问

create（POST），update（PUT)和delete操作需要cloud_controller.admin的权限范围（scope）

read（GET）操作，需要cloud_controller.admin的权限范围或用户已经登录

权限验证流程

默认的权限验证

这里讨论的都是基本的权限验证，在基类中定义的。

每一个API接口调用时，在业务方法调用前先从header的auth_token中解析了用户信息，放在当前线程的context中。

 

参考：front_controller.rb

before do auth_token = env[ "HTTP_AUTHORIZATION" ] # 获取auth_token VCAP::CloudController::Security::SecurityContextConfigurer. new ( @token_decoder ).configure(auth_token) # 解析token并设置到当前线程的context中 validate_scheme end

接下来，做接口基本认证检查

先检查是否当前接口是否需要认证

在每一个model的controller类中定义了可以不需要认证即可调用的接口，如：buildpack_bits_controller定义了download方法不需要认证

allow_unauthenticated_access only: :download

如果需要认证，则检查是否从auth_token中解析出了user，如果连user都没有就无从谈认证了

最后验证当前用户是否能访问该接口

如：

validate_access(:create, obj, user, roles)

对于拥有cloud_controller.admin权限范围的用户，都通过

 

参考：base_access.rb

def read_with_token?(_)   admin_user? || has_read_scope? end def create_with_token?(_)   admin_user? || has_write_scope? end def update_with_token?(_)   admin_user? || has_write_scope? end def delete_with_token?(_)   admin_user? || has_write_scope? end

这里的admin_user是看是否拥有cloud_controller.admin权限范围

参考：roles.rb

def admin?   @scopes .include?(CLOUD_CONTROLLER_ADMIN_SCOPE) end

查看是否拥有read权限则是查看是否拥有cloud_controller.read权限范围

参考：base_access.rb

def has_read_scope?   VCAP::CloudController::SecurityContext.scopes.include?( 'cloud_controller.read' ) end

查看是否拥有create/update/delete权限则是查看是否拥有cloud_controller.write权限范围

参考：base_access.rb

def has_write_scope?   VCAP::CloudController::SecurityContext.scopes.include?( 'cloud_controller.write' ) end

具体接口的权限验证

具体的接口还可以自定义权限验证。

这里以app为例

参考：app_access.rb

module VCAP ::CloudController    class AppAccess < BaseAccess      def create?(app)        return true if admin_user?        return false if app.in_suspended_org?        app.space.developers.include?(context.user)      end      def update?(app)        create?(app)      end      def delete?(app)        create?(app)      end      def read_env?(app)       return true if admin_user?       app.space.developers.include?(context.user)      end      def read_env_with_token?(app)        read_with_token?(app)      end    end end

从代码可以看出，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非法。