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非法。