On 11/02/13 18:06, Mike Heath wrote:Actually the login server *does* do the authentication, and (as you have pointed out elsewhere) the Cloud Controller should be sending clients like vmc to the Login Server not to the UAA. The Login Server actually only calls the UAA for authentication in "default", "native" or "legacy" mode if you will, which we were more or less forced to do by the fact that we need to support CF.com with it's native user account data. In general a login server is free to do authentication any way it likes. It's pretty easy to strategise for browser clients. For vmc you need to be able to accept authentication parameters as key=value pairs, but that hopefully isn't too strict a constraint.
If a login server is present, it should do the authentication and UAA should make calls to login. Currently login calls UAA.
That's a possibility. Instead we have gone with a whitelabel UAA, which works, but is ugly and contains a message with a link saying something like "If you see this page you are probably in the wrong place". We don't wan t to prevent the UAA from being used as an authentication source for native user accounts, but we want to discourage client apps from trying to use it for SSO. You should see that coming out in UAA 1.4 pretty soon.
Also, when a browser goes to uaa for authentication, the browser should be redirected to login.
Agree, and we are definitely going to have to support that pattern. But it goes beyond authentication, which is what we are focused on currently with several internal and external deployments. Your experience might be valuable when we get to the groups and scopes. My sense is that the UAA will always need a database with that information in it, but it might be automatically provisioned by the login server.
In the future, it would a be a really nice feature to allow the login server to specify OAuth scopes whether that comes from LDAP groups or some other source. The ability to easily customize this is what's most important to me.
Hello James,
It would have helped me in the beginning if I knew I just had to replace the authz manager by my own ldap manager. It took me some research in the code to find that out. It would be nice to have a quick overview of the main configuration components, and what they do.
Then, another sticking point would be the use of UaaUser in UaaTokenServices. It takes a UaaUser to encrypt the token, and my LdapUser is nowhere close to a UaaUser. Therefore I created another UaaUserDatabase implementation to return a stubbed “UaaUser”… This is the only bit of code I had to write to make the whole thing work (except adapting the config files of course), and it’s more of a “hack” than an actual real business implementation. Oh and that’s right, I also had my LdapUser class implement the Security interface to avoid a ClassCastException. In the UaaUser I return, I also have to add an imaginary “modifiedDate” (which I don’t have in my ldap), otherwise an exception is thrown since I create a new User and uaa thinks the password has changed, but not the access token.
Finally, I struggled to use the ‘user authorities’ from my ldap to filter security access, but I guess that is a gap of spring security/oauth knowledge on my side. However, a reference to “UaaAuthorizationRequestManager” would have saved me some time in terms of comprehension with roles/groups.
>Are there things we can document about what you've learned to make it better for someone else wanted to do LDAP integration and passing LDAP groups as OAuth scopes?
If all I said was documented, I’m sure it would help :)
>Is the work you did custom to your specific directory integration or is there reusable code for this part?
It’s mainly configuration so far… I use the cloudfoundry-common jar, and adapt the config files.
But if your goal is for us to use the uaa jar as-is, I think a small rework in UaaTokenServices is necessary to avoid the “hack” I had to do… Hence having a “User” interface instead of a “UaaUser” class, and a documentation that states “you need to replace the UserDatabase with your own in the spring config files”.
>Do you think a sample would help?
It surely wouldn’t hurt, but in the end, the integration of LDAP was not so hard. With a good documentation and some LDAP-spring config knowledge, no problem !
so you spooke-because of
guestfs find out fstab is empty, and add an echo after the debootstrap in
stemcell builder base_debootstrap stage will fix the error.