Open Stack

Hi Adam


>> what do you mean by IDM provider? IDP?
>
> Yes.  Identity Management (IdM) system.

IDM and IDP are not the same.
IDP is an identity provider who authenticates users and asserts 
attributes about them (a combination of an Authentication Service and an 
Attribute Authority)
IDM is a system which comprises many different entities such as
Discovery Service
IDP
AA
Service Providers
Aggregation Service
and more which may still need to be defined such as
proxy IDP
gateway
etc.

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

I have read your Domains document. A lot of it is to do with managing 
users. But Keystone administrators should not be directly managing 
users. IDPs should be doing this. What keystone administrators should be 
doing is authorising users for their cloud resources, based on their IdP 
provided attributes. I will try to write an architecture document 
describing keystone with separate services with separate functionality 
(rather than integrated ones). In our federated keystone implementation 
the administrator does not manage users, rather he authorises them to 
use services through a set of rules (essentially attribute mappings ie. 
map their identity attributes from their IDPs into OpenStack attributes 
(tenant id, role etc), and permissions (through a PDP). In this way 
users are only managed (provisioned) once, by their IdPs. Keystone does 
not need to bother about authenticating users - the IDPs or 
Authentication services do this for keystone.

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

thanks for the pointer

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

you can design it with varying levels of security, ranging from bearer 
tokens (the least secure) to holder of key tokens (where the user has to 
prove possession of a private key).

   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.

It could come from attribute mappings (as stated above). The domain 
manager can have a rule which states "a user with this attribute from 
this IDP gets this role in this tenant"


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

I agree that it does not have to be. But it makes things a lot simpler 
if it is

regards

David

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