UAA 和login-server

概述

UAA的设计理念是要实现一个统一的用户认证和权限管理中心，设计思想和全部API见官方的UAA文档

下图说明了各种组件在UAA中的配合关系

详细的去看文档。在这里仅仅提一下怎么给cloudfoundry加上自定义的权限验证，比如ldap

安装和配置

天生的跨平台JAV，安装上应该不会有问题。

至于UAA的配置 参见这里

实践LDAP登录

UAA有实现用户认证的逻辑，但如果需要自定义登录比如使用LDAP登录，并不需要修改UAA的代码。

之前在cloud controller中提到，cloud controller对请求的验证是通过解密在Authorization header中的token来实现的。 UAA可以仅仅起一个token分发者的作用，然后将用户认证的部分委托出去。cloudfoundry已经替我们考虑到了这一点。 只需要在cloud controller的配置项里配置到login这个配置为自己的登录服务器（假设叫login-server） 再使用cf或者cfoundry api 进行登录都会使用login-server来进行登录验证。

官方的有个login-server ，我们fork下来然后:

1. 给login-server加上ldap的登录逻辑
2. 当用户第一次登录时，login-server使用admin权限调用CC提供的api，给用户创建一个默认的space和org,分配一个domain。 相当于login-server替代了上图中的 Monitoring web app

这一部分实现的并不完美，其实登录请求分两种，一种是implicit登陆，即使用命令行客户端登陆的方式，另一种是专门给浏览器使用的登陆逻辑。 为了图省事我们浏览器和客户端都是用了同样的implicit登陆接口，直接把token存在cookie里，仅仅为了测试而已，实际使用这样肯定是不安全的。