Open Stack

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.


> 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

  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.


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



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