所以首先:在UAA推出之前,Cloud Controll呃(简称CC)是单独进行身份验证,将用户存储在psql数据库中的。
不是以后他们想通了,CC应专注于应用/ Servcice管理和委托认证 /授权/ usermanagement到一个新的组件,它们命名为:用户帐户和身份验证(UAA)服务器
UAA主要是oauth2提供商,这意味着给予代币客户。但客户OAuth术语是像VMC/CC作用于代表用户(资源所有者OAuth术语)的应用程序
echo 'select client_id, scope from oauth_client_details;' | sudo psql -U root uaa
client_id | scope
------------------+--------------------------------------------------------------------
admin | uaa.none
vmc | cloud_controller.read,cloud_controller.write,openid,password.write
cloud_controller | uaa.none
UAA还能够身份管理即能够存储用户和他们的passord的。他们正在实施SCIM标准(跨域身份管理系统)。现在
echo 'select * from users;' | sudo psql -U root uaa
其实我VCAP所有用户都将通过cloud_controller的Postgres的数据库进行存储,无论cloud_controller.yml设置:默认情况下,它的使用的Postgres来存储用户。但要注意的是,CC - UAA连接重整容下,你可以在过去几天的Git修订看到:
在过去的几天我从git的几次拉最新的代码,有时新用户都进入CC的分贝,有时他们得的UAA的分贝。它也有时取决于vmc版本...
从你描述我猜你的用户在CC的分贝。你可以自己检查一下。 你可以列出cloud_controllers Postgres的用户数据库为:
echo 'select * from users;' | sudo -u postgres psql cloud_controller
注意活跃列。如果启用UAA,则两个数据库都存储用户,但其活动= true,UAAdb中active = false,CCdb
因此,最安全的方法是禁用CC的UAA代表团,如第77行所示。cloudfoundry /.deployments/devbox/config/cloud_controller.yml
uaa:
enabled: false
更改任何的ConfigurationFile后,必须重新启动在这种情况下,CC受影响的组件:当我使用VMC版本
~/cloudfoundry/vcap/dev_setup/bin/vcap_dev restart cloud_controller
实际上,现在所有用户都将存储在cloud_controller的postgres数据库中,而不管cloud_controller.yml设置如何。 – lalyos