Open Stack

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.

The part of your document that I am most excited about is how it is 
designed to work with multiple authentication mechanisms.  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.

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."  Thus far, tenant creation is an explicit action, 
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.  On demand tenant creation would ariull need to tie in with such 
and accounting system.  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?  Is there anything in your design which would require 
on-demand tenant creation?

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.  Anything we 
build needs to work first and formost with curl.  Would that requirement 
impact your design?  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.  creating a 
specific Library to call that seems to work against the REST approach.  
I'd much rather see the set of URLs and actions specified IAW the way 
that the V3 API has been described.

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?  Does it matter?

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?  Is that for every time a new 
authentication is performed, or is it something that is done once and 
cached?

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.  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. It will greatly facilitate the discussion.

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


Adam