Open Stack

Hi Adam

On 22/08/2012 21:33, Adam Young wrote:

--- BIG CUT
>
> The phrase "Who is allowed to be a tenant" suggests to me that you
> understand tenants differently than they are implemented.  A Tenant is
> not a user, but rather a grouping of users ,  virtual machines,
> networks, images, etc.

this is OK and fits with our model. I think of a tenant as being 
equivalent to a keystone account. The model we have used is as follows

1. There is a many to many mapping between users and tenants.
2. A user is identified by a set of attributes from one or more IDPs (we 
support attribute aggregation in our model and software but we have not 
specifically dealt with this in our documentation so far).
3. A subset of the user's attributes maps into a tenant/account in 
Keystone. This is specified by the CSP administrator in the config file
4. A user could be the "owner" of several tenant accounts after 
authentication by virtue of the set of attributes that are presented.
5. There is no need to pre-create tenants. They can be created dynamically.

An example might help.
Say the administrator configures keystone to create tenants for each 
user who can provide a kentID attribute, and another tenant for the 
role=professor, org=kent attributes. Note that in the first rule the 
attribute type only is specified, and no attribute value.

Say a user authenticates and has the following identity attributes
KentID=1243
role=professor
org=kent
age=45

The last attribute is ignored since it is not in the config file.
The first attribute causes a tenant to be created which is unique for 
this user. He is only user who will ever be able to access it
The next two attributes cause a tenant to be created for kent 
professors. This tenant will be "owned" by maybe a hundred or more staff 
at kent who can show they are professors.

Say another user authenticates has the following attributes
KentID=1456
role=professor
org=kent
The middleware will create a new tenant for the kentID but will use the 
existing tenant for the kent professor role.

It is the basic ownership grouping of Openstack,
> and I think they need to be pre created.  The IdM provider

what do you mean by IDM provider? IDP?

can indicate
> that a given user is a member of a tenant,

It is surely the cloud provider or keystone that controls the creation 
of tenants isnt it?

  and that the user has a given
> role in the tenant, but there needs to be some differentiation between
> the providers.  In the Federation doc
> http://wiki.openstack.org/Keystone  I suggest that a IdM is allowed to
> control one or more  domains.

what do you mean by domain? I think of domain as a group of entities 
under the same administrative control. So a Fed IDM (FIM) contains lots 
of domains, but does not control them as each domain has its own 
administrator. Usually each SP and each IDP is in its own domain. 
Federation means that they are joining together for mutual benefit. The 
FIM administrator will set rules for the FIM system as a whole, and each 
domain administrator will agree to abide by them.

  In order to get access to the tenants in
> that domain,

I dont understand what you mean  by the tenants in that domain.

  a user uses the auth mechanism for that domain, possible
> using a mechanism like cross realm support from Kerberos.

the Kerberos cross realm support should not be part of the Keystone 
design. This is a feature of how the user authenticates with the IDP. 
Keystone is acting as a SP, and it has trust relationships with IDPs. 
The cross realm (or cross domain) support comes from the SP trusting a 
remote IDP ie. keystone being configured to trust one or more remote IDPs.


>>
>>
>>> and often one that is done in conjunction with an exchange of funds, or
>>> at least the intialization of a contract with the end user to be billed
>>> later.
>>
>> Agreed. We also assume that this has been done beforehand. E.g. The
>> CSP enters into a contract with my university to allow all staff to
>> store 3 GB of data in its cloud. The rule will say "if the user can
>> prove he is a member of staff from the University of Kent" then create
>> a new tenant for him. How is this achieved. Easy. The user
>> authenticates via the Kent IDP, then the Kent IDP send a signed
> assertion to Keystone (via the client) saying "I have authenticated
>> this user. His PID is 1234556678, his role is staff member and his
>> organisation is University of Kent" signed by University of Kent IDP.
>> Only people with staff login credentials at the Kent IDP will be able
>> to obtain this signed assertion.
>>
>>
>>   On demand tenant creation would ariull need to tie in with such
>>> and accounting system.
>>
>> not sure what you were trying to say here
> Me neither.
>>
>>  I understand that different implementations have
>>> different requirements.   Would it be correct to say that this is
>>> something that should be a policy decision on the part of the
>>> implementation?
>>
>> Yes policy decision by the implementation. Policy specification by the
>> CSP administrator.
>>
>>  Is there anything in your design which would require
>>> on-demand tenant creation?
>>
>> Yes, we dont know who the tenants are beforehand. And we dont want to
>> know. We must keep the cloud dynamic and responsive to the customers
>> (clients) needs. Consider the unnecessary overhead if Kent had to
>> configure 2000 users and their credentials into the CSP's system, as
>> well as into their own systems at kent. It duplicates the effort,
>> gives rise to errors, and is simply a costly waste of time.
> Tenant != User.  Tenant ~ group.
>>
>>
>>>
>>> You mention the client library.  I think that we want to go the other
>>> way:  straight REST implementation.  While it is true that the CLI has a
>>> lot of power, what we have found is that a huge number of
>>> implementations are using the Web APIs as the primary access to
>>> Openstack, and they need to be the first class citizen.
>>
>> Now this is interesting. Because at the summit in Boston last year I
>> gave a presentation entitled My Private Cloud where I demonstrated
>> that we had built a browser based federated interface to an Amazon S3
>> like service, and the main criticism given of it by the audience was
>> "most Open Stack users use a command line interface, not a browser
>> based one, so your system would not work well for our users". So this
>> time around we built onto the command line interfaces. Now you seem to
>> be saying exactly the opposite!
>
> Ah, not quite.  I am saying that we have found a lot of our users are
> using the direct APIs as opposed to the CLIs that Openstack provides.
> Not browser based.  For those using the tools we provide, it is still
> CLI over Browser as well.

this is where we will have potential problems, because all the IDPs I 
know of today use browsers to authenticate their users. And the 
authentication protocol between the IDP and the user is not standardised 
by any of the identity management systems. So the IDP can do anything it 
wants. There is no IDM API for this. And there probably never will be as 
it defeats the purpose of having IDM and allowing freedom in the choice 
of authentication mechanism.

regards

David

(rest cut)