【OpenStack】G版Keystone对象模型

本博客欢迎转发，但请保留原作者信息（@孔令贤HW）！内容系本人学习、研究和总结，如有雷同，实属荣幸！

Users：表示API的一个特定使用者，属于一个指定的domain。可以赋予user权限(role)，每一个user-domain或user-project都可以有一组权限。

Groups：表示一组拥有某权限的用户，属于一个指定的domain。可以赋予group特定的role，此时group内的user都自动具备该role表示的权限。

Credentials：与user关联的认证凭据。一个user可能有一个或多个credential，一个credential与某一个project关联。

Projects：在OpenStack中表示一组资源(也就Folsom版本的Tenants，Tenant概念在G版被废弃)，一个project属于某一个domain。

Domains：表示一组projects和users的集合。每一个project或user只能属于一个domain，但user可以属于多个projects。domain有命名空间的概念，即在一个命名空间内的名称是否是全局唯一。

Roles：角色，表示一组在project或domain范围内允许的操作。

Services：表示一类服务。

Endpoints：表示服务的URL。

Tokens：表示认证用户的标识，有认证服务生成。没有token的资源URL，token的使用是在X-Auth-Token和X-Subject-Token头部

对象之间的关系如下：


 本博客欢迎转发，但请保留原作者（@孔令贤HW）信息！内容系本人学习、研究和总结，如有雷同，实属荣幸！

评论

2 楼 lynnkong 2013-02-04  

lzy.je 写道

Just forward domain namespace explaining of Keystone v3 API from Henry Nash mail ([e-mail]):

Thanks for your addition. I just follow "https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md"

I think the design goal of components of OpenStack is more and more for public cloud, including "cell" that you told me in my last post. I'm a beginner, and just follow and learn.

1 楼 lzy.je 2013-02-03  

Just forward domain namespace explaining of Keystone v3 API from Henry Nash mail ([e-mail]):

So a few things are going on here:

1) Traditionally (in the pre-domain world), user name was "globally unique"....which really means unique within all openstack services sharing a keystone instance.  The same was true of tenant name.
2) In v3, if we kept this the same, then enterprises would find this restriction (particularly the one for tenants) unacceptable - some of them will expect free-rein over what they can call any names attribute (e.g. project name, user name etc.) inside the domain in which they are being hosted
3) So v3, optionally allows the creation of a domain with a private name space for user names and/or project names
4) For Users, when they are created, you can optionally specify the domain they are "owned by".  If you specify a domain (say, "Kent") which was created with a private user name space, then for that specific user, its name only has to be unique within that domain (i.e. there can be other "David"'s in other private user space domains as well as a "David" shared across all other non-private domains).   That is what the comment is trying to say.
5) To answer your other questions specifically:
- How do you tell if a user name is globally or domain-unique?  For a v3 api, the domain_id of the owning domain is in the user entity, look that up and see if it is has the 'private_user_namespace' flag set to True. 
- Who is the owner of a "globally unique username"?  It can be any domain that has 'private_user_namespace' flag set to False, including the default domain

On 26 Jan 2013, at 17:08, Dolph Mathews wrote:
- In your example of the two different domains, these would not be the same user in the current implementation that is underway - i.e. a user is either globally-unique or domain-unique.


As an aside, we had the discussion as to whether we should just say that all domains have private name spaces....although we are trying to balance (as usual) backward compatibility with adding new features.  For instance, one implication of a domain with a private user namespace is that, as Dolph says, you must either supply user_ID or username+domain in order to authenticate.  We wanted to keep that requirement to ONLY those domains that really needed it...not make it the norm for v3.  This would, for instance, allow a Folsom cloud provider, who hosts many individual or small enterprise accounts, to upgrade to Grizzly and


a) Continue to host all those existing accounts (by default the all users and projects will be in the default domain)
b) Start to add medium enterprises in domains (who perhaps are happy without private namespaces)...without affecting a)
c) Start to add some larger enterprises in domains with their own private namespaces...without affecting a) or b)


Henry