Open Stack

On 08/22/2012 05:40 PM, David Chadwick wrote:
> 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?

Yes.  Identity Management (IdM) system.

>
> 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


Yes, but Domain is a Keystone concept.  A Domain is a top level grouping 
of tenants.  Each user belongs in exactly one Domain, but can 
potentially get access to tenants in other domains.

>> 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.

http://wiki.openstack.org/Domains

>
>  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.

If I understand this correctly, I don't this it is secure.  A user has 
to get a role to effect a change to a resource inside the tenant.  That 
role has to be assigned by the administrator of the tenant.  THat won't 
come out of the users Identity Management System, but out of the IdM for 
the Domain.


>
>
>>>
>>>
>>>> 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.

Kerberos does not.  PKI based system to do not.  SAML can be done 
without a Browser.  The browser, while a useful tool, cannot be a 
required part of the auth system.


>
> regards
>
> David
>
> (rest cut)