Open Stack

On 08/22/2012 03:00 PM, David Chadwick wrote:
> On 22/08/2012 02:46, Adam Young wrote:
>> David,
>>
>> I went through the docs you posted on dropbox in a bit more detail. I
>> really appreciate the amount of effort that went into this design so
>> far.  I have a few questions about how your current design aligns with
>> some of the assumptions that Openstack is built on.  These assumptions
>> may not be explicit anywhere, so pulling them out into the open here
>> might be the best starting point.  I might not be the best person to do
>> that, but I can get the conversation rolling.
>
> Yes I think that OpenStack/Keystone currently lacks sufficient 
> documentation. A lot of it seems to be down to reading the code.
>
>>
>> The part of your document that I am most excited about is how it is
>> designed to work with multiple authentication mechanisms.
>
> We have to accept that in todays world there is no one size fits all, 
> and there probably never will be. Furthermore as technologies evolve, 
> you need to be able to seamlessly incorporate them.
>
>   I personally
>> have been thinking more along the lines of PKI and Kerberos, and I think
>> that your document supports SAML and numerous other mechanisms provides
>> a smart and logical extension to Keystone's authentication story.
>
> This is how the current federations work today. The way the user 
> authenticates to the IDP is "out of scope", so the IDP can use 
> whatever mechanism it deems to be appropriate. The only limitation 
> usually is that the online protocol part is transferred via http and 
> the user's browser. You can add 2 factor authn to this by using an 
> offline mechanism such as OTP with hardware, but this does not effect 
> the overall federation architecture or online protocol.
>
>>
>> I suspect that the most controversial aspect you have written up is " If
>> the permitted tenants are not in keystone they will be created and
>> linked to the user."
>
> Not really. Perhaps we should have added "providing they are 
> authorised by the administrator, via the configuration file". I guess 
> this implicit statement was not obvious to you on first reading, but 
> if you read carefully it says "permitted tenants" and not "anyone as 
> tenant"
>
>  Thus far, tenant creation is an explicit action,
>
> Its an indirect explicit action in our case. Its rule based. The 
> administrator explicitly sets the rule for who is allowed to be a 
> tenant, and then the software enforces this rule when an unknown user 
> tries to login. If his identity matches one of the rules, then he is 
> allowed to be created, if not, he is rejected.


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.  It is the basic ownership grouping of Openstack, 
and I think they need to be pre created.  The IdM provider can indicate 
that a given user is a member of a tenant, 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.  In order to get access to the tenants in 
that domain, a user uses the auth mechanism for that domain, possible 
using a mechanism like cross realm support from Kerberos.
>
>
>> 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.

>
>
>
>   Anything we
>> build needs to work first and formost with curl.  Would that requirement
>> impact your design?
>
> Not really. We could substitute a browser for the command line 
> interface as the protocol is Http in both cases.
>
> How hard would it be for a third party to implement
>> the handshakes that you describe between getting the endpoint list etc?
>> For example, on the client connection API: getScopedToken and
>> getUnscopedToken are already implemented in the REST API.
>
> We use these "as is". They are only in our documentation so that the 
> full story can be written. It gives the reader the complete picture 
> rather than half of one.
>
> The other design criteria was that the keystone middleware would 
> create binary blobs to give to the client (command line or browser) 
> with instructions to pass these unaltered to the IDP. And the IDP 
> would do likewise passing its responses to keystone. In this way we 
> can change SAML to OpenID or FlavourOfTheYear2020 without altering the 
> design or the clients.
>
>
>   creating a
>> specific Library to call that seems to work against the REST approach.
>
> Not sure what you are getting at here. Keystone can tell the IDP to 
> use a different URL in its response (as part of the binary blob) so 
> that it is relatively easy to have different URLs for different 
> keystone states.
>
>> I'd much rather see the set of URLs and actions specified IAW the way
>> that the V3 API has been described.
>
> Not had chance to fully digest the V3 API at the moment, but what I 
> can say is that the documentation is very sparse, it is missing a 
> conceptual design section, it is missing the overall architecture, and 
> if you cannot read/understand the code snippets, then the 
> documentation is not that much use to anyone to understand what it is 
> trying to say. If the documentation does exist somewhere else, then 
> the API ought to point to it.
>
>
>>
>> There has been a Blueprint for Domains published for some time. It took
>> a lot of work to get consensus on it. http://wiki.openstack.org/Domains
>> They seem to be the analogue of Realms as you've specified.  The APIs
>> for them are in the V3 API document.  We had hoped to get that in to
>> Folsom.
>>
>> The user guide states  "The user logs into the IdP via his browser."
>> While Horizon is a browser based app, we expect far more integration
>> with non-browser use.  Is your implementation expecting to be
>> predominantly driven from the browser?
>
> Not predominantly browser based, but we found that integrating the 
> browser for just the login part was essential
>
>  Does it matter?
>
> Yes, since there are a number of problems in not using a browser to do 
> the actual authentication, which are these
>
> 1. Different IDPs use different auth mechanisms, but browsers have the 
> intelligence and code to handle them all
> 2. Different IDPs who use the SAME authn mechanism still have 
> different page layouts, call fields different names etc, which human 
> eyes and brains can easily interpret, they can follow instructions, 
> but software would find more difficult to process.
> 3. IDPs (and the federation authn mechanism) can dynamically introduce 
> new features, such as routing via a proxy, or identity aggregation, 
> which human users and browsers can very easily follow, but code could 
> not without being re-written.
>
>
>
>>
>> The discovery service finds the endpoint for the Realm.  This means that
>> a call to Keystone has to kick the whole thing off.  How often is that
>> discovery service used, and by whom?
>
> this is an extension point in order to cater for scalability. In the 
> simplest of cases (i.e. the same IDP for everyone) it is not needed 
> since you can configure in the endpoint of the IDP. But this is 
> neither scalable nor realistic in today's identity world.
>
>  Is that for every time a new
>> authentication is performed, or is it something that is done once and
>> cached?
>
> This is a client issue. An intelligent client could cache the info. 
> But in our initial prototypes we call it each time the user wants to 
> authenticate.
>
>
>>
>> It would be really useful if you could post the documents in a format in
>> which we could link to individual lines or at least sections.  I
>> personally don't care for Google docs, and am fine with the Wiki.
>
> I looked at google docs but it would cause a lot of wasted time 
> re-formatting the pictures and the text etc. We wanted to get the docs 
> to you fast, without wasting our precious time. Internally we use Word 
> with track changes since this works very well. Certainly we can create 
> any new docs using the preferred methods.
>
>
>  But
>> to be honest,  a text version of your documents checked in to Github
>> would be sufficient.  I think that format is really secondary to content
>> at this point.
>
> Agreed
>
>> It will greatly facilitate the discussion.
>
> Agreed. But pictures also tell a thousand words, and are indispensable 
> to me. A text version would preclude the pictures, which is a problem.
>
>>
>> Again, thanks to you and your team for moving this topic along. I see
>> it as the next big step for Keystone, and I think I speak for all of us
>> when I say "lets get it right."
>
> I agree. This means quality metrics must include extensibility, 
> flexibility, scalability, since there is no single world standard for 
> identity management, and there wont be in my life time. So support (at 
> the conceptual and architectural level) for multiple protocols should 
> be built in, with the aim of supporting billions of users.
>
> regards
>
> David
>
>>
>>
>> Adam
>>
>>
>>
>>