Open Stack

On 08/23/2012 12:38 PM, David Chadwick wrote:
> 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.

OK, that is a clear distinction.  IdP has a smaller scope.  I'm used to 
working with them integrated,  but I see the value of the distinction.  
I'll try to stick with it for the discussion. Keystone blends the two 
into one, of course.

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

OK,  Let me see if I can restate it.


The current implementation of Keystone is a degenerate case of a more 
complex solution space.  Currently, Keystone ties together the 
management of users and roles with the management of tenants.  It also 
lacks some higher level of distinction to group tenants,  which has been 
referred to as both Domains and Realms. In a Federated system, Keystone 
no longer directly manages Users, but instead delegates that to remote 
IdP systems.  The IdP is what determines the capabilites of a user, not 
the Keystone server.  Instead, the Keystone server plays an indirect 
role, merely determining whether a given IdP has the authority to 
delegate the requested action.

I think that there are two use cases that are at odds here.  Lets call 
them Cloud to Organization (C2O) and Cloud  to User (C2U). Federated as 
you state is an elegant solution to C2O. Keystone as it currently exists 
is targeted at C2U.  We need both, which means that an organization 
implementing Openstack will still need its own IdP, but will also need 
to support other, federated, IdPs as well.

I think there should be a conceptual one-to-one mapping between domains 
and IdPs, although in actuality one IdP could manage more than one domain.

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

Ah, I was too terse.  Let me explain.

Say two peer organizations have a setup where a user for one can modify 
resources owned by another.  Control of the permissions for the user has 
to be maintained under the control of the organization that owns the 
resources.  They cannot be modified by the other organization.  It is 
not a factor of the authentication mechanism, but of the authorization 
mechanism.


>
>   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"
I am not thrilled with that.  Say I am using my Facebook (really big 
organization) account to validate against a tenant managed by the IdP 
for MomAndPopsLaundry.  I can't get Facebook to modify its set of 
attributes for me.  Instead, I need MomAndPopsLaundry to enable my 
account in their 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

Yes, but it 100% cannot be a requirement.  Still, I don't think that is 
a big problem. It means that getting authenticated to a remote system 
has to be possible via a web service.  Shibboleth and SAML can both work 
that way.  What is done with redirects can be done explicitly.  Support 
for that can, potentially, go into the Openstack common client architecture.

One thing that this does not address is fetching the service catalog on 
behalf of the end user.  THis is done in the auth_token middleware 
during verification. With PKI tokens, it is signed and embedded in the 
token.  The Federated middleware would need a way to query that for a 
user, without that user actually being in the Keystone database.




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