Hi stackers,
We are moving to keystone v3, we want to the difference between keystone v2 and v3, what benefit can we get from keystone v3?
Thanks!
Besides domaiins, there are many things in authentication.
1) Authentication is totally pluggable. You can write our own custom auth method. Beause of this extensible auth method, now keystone supports oauth1, federation ( federation is not fully done) 2) Authorization : V2 is either "admin" or none. In v3 you can control who can call each method. ( Provided you diefine your own policy file ) 3) Separate drivers for assignments and identity 4) Rich set of APIs. There are lot more API available than v2.0. Also there are no vendor specic extension. If you check v2.0, most of the role apis are Rackspace extensions
Trust has been there from Grizzly. Some prefer Trust and others prefer OAUTH1. Both are trying to solve the similar usecase.
Your questions is mostly towards difference between v2 and v3. If you are planning to move to v3, you need to know few things.
1) None of the services support v3. 2) Keystone command line client is only v2. It is not going to support v3. Suggestion is to use openstack client. I don't think openstack client supports v3. So you have to use REST API to create domains/groups/users/ etc in v3 3) If you use keystone client to create users, then most likely it won't work with v3 api. ( you can use default domain to make it work) 4) I'm not sure about this, but horizon only supports v3 auth and not v3 user/domain creation 5) Username/Project names are unqiue only ...
Thanks again. One thing we have not figured out, there are two policy files in keystone source, Policy.json and Policy.v3cloudSample.json if we are moving to v3, should we use the policy.v3cloudsample only or we can still use the former policy file for backward compatibility?
Thanks!
You can use eiher one of them. It is preferable to use the second one for production deployment as it takes advantage of the domain concept. If you use the first one, then you need to be an "admin" to do everything. If you use policy.v3cloudsample.json, then you will get 1) cloudadmin who can do any operations on any domain (Similar to v2 admin ) 2) domain admin who can do any operation in his domain. He can't touch other's domain. A user can operate only on his domain
My suggestion is to go with policy.json and get comfortable with v3 apis and then explore the second policy file
Groups + Domains are two of the big ones. You'll be able to assign groups to projects instead of single users. With AD as the backend it's really useful. Assign groups to a project, then you can do user/group management on the AD server.
Domains make it easier to setup the idea of a Reseller.
Asked: 2014-04-08 05:21:12 -0500
Seen: 4,096 times
Last updated: Apr 08 '14
