<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/26/2012 07:17 PM, Henry Nash
wrote:<br>
</div>
<blockquote
cite="mid:9F88DB3C-B7BE-4ECF-A7E6-D1E1575DDDE0@linux.vnet.ibm.com"
type="cite">So to pick up on a couple of the areas of contention:
<div><br>
</div>
<div>a) Roles. I agree that role names must stay globally unique.
One way of thinking about this is that it is not actually
keystone that is creating the "role name space" it is the other
services (Nova etc.) by specifying roles in their policy files.
Until those services support domain specific segmentation, then
role names stay global.</div>
<div><br>
</div>
<div>b) Will multi-domains make it more complicated in terms of
authorisation - e.g. will the users have to input a Domain Name
into Horizon the whole time? The first thing I would say is
that if the cloud administrator has create multiple domains,
then the keystone API should indeed require the domain
specification. However, that should not mean it should be
laborious for a Horizon user. In the case where a Cloud
Provider has created domains to encapsulate each of their
customers - then if they want to let those customer use horizon
as the UI, then I would think they want to be able to give each
customer a unique URL which will point to a Horizon that "knows
which domain to go to".</div>
</blockquote>
Yes, I think that this is the solution. It will involve HTTPD
virtual hosts, and horizon can then get an additional config
parameter "keystone_domain" as part of the wsgi config.<br>
<br>
<br>
<blockquote
cite="mid:9F88DB3C-B7BE-4ECF-A7E6-D1E1575DDDE0@linux.vnet.ibm.com"
type="cite">
<div> Maybe the url contains the Domain Name or ID in the path,
and Horizon pulls this out of its own url (assuming that's
possible) and hence the user is never given an option to chose a
domain. A Cloud Admin would use a "non domain qualified url" to
get to Horizon (basically as it is now) and hence be able to see
the different domains. Likewise, in the case of where the Cloud
Provider has not chosen to create any individual domains (and is
just running the cloud in the default domain), then the "non
domain qualified url" would be used to a Horizon that only
showed one, default domain and hence no choice is required.</div>
<div><br>
</div>
<div><br>
</div>
<div>Henry</div>
<div><br>
<div>
<div>On 26 Oct 2012, at 17:31, heckj wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space; ">Bringing
conversation for domains in Keystone to the broader
mailing lists.
<div><br>
</div>
<div><br>
<div>
<div>On Oct 26, 2012, at 5:18 AM, Dolph Mathews <<a
moz-do-not-send="true"
href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>>
wrote:</div>
<blockquote type="cite">I think this discussion would
be great for both mailing lists.<br clear="all">
<div><br>
</div>
-Dolph<br>
<br>
<br>
<div class="gmail_quote">On Fri, Oct 26, 2012 at
5:18 AM, Henry Nash <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:henry.nash@mac.com"
target="_blank">henry.nash@mac.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap:break-word">Hi
<div><br>
</div>
<div><Not sure where best to have this
discussion - here, as a comment to the v3api
doc, or elsewhere - appreciate some guidance
and will transfer this to the right
place></div>
<div><br>
</div>
<div>At the Summit we started a discussion on
whether things like user name, tenant name
etc. should be globally unique or unique
within a domain. I'd like to widen that
discussion to try and a) agree a direction,
b) agree some changes to our current spec.
Here's my view as an opening gambit:</div>
<div><br>
</div>
<div>- When a Keystone instance is first
started, there is only one, default, Domain.
The Cloud Provider does not need to create
any new domains, all projects can exist in
this default domain, as will the users etc.
There is one, global, name space. Clients
using the v2 API will work just fine.</div>
</div>
</blockquote>
<div><br>
</div>
<div>+1</div>
</div>
</blockquote>
<div><br>
</div>
<div>Very much what we were thinking for the initial
implemenation and rollout to make it backwards
"compatible" with the V2 (non-domain) core API</div>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px
0px 0px 0.8ex; border-left-width: 1px;
border-left-color: rgb(204, 204, 204);
border-left-style: solid; padding-left: 1ex;
position: static; z-index: auto; ">
<div style="word-wrap:break-word">
<div>- If the Cloud Provider wants to provide
their customers with regions they can
administer themselves and be self-contained,
then they create a Domain for each customer.
It should be possible for users/roles to be
scoped to a Domain so that (effectively)
administrative duties can be delegated to
some users in that Domain. So far so good -
all this can be done with the v3 API.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Not clear on if you're referring to endpoint
regions, or just describing domain isolation?</div>
</div>
</blockquote>
<div><br>
</div>
<div>I believe you're describing the key use cases
behind the domains mechanism to begin with - user
and project partitioning to allow for administration
of those to be clearly "owned" and managed
appropriately.</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px
0px 0px 0.8ex; border-left-width: 1px;
border-left-color: rgb(204, 204, 204);
border-left-style: solid; padding-left: 1ex;
position: static; z-index: auto; ">
<div style="word-wrap:break-word">- We still
have work to do to make sure items in other OS
projects that reference tenants (e.g. Images)
can take a Domain or Project ID, but we'll get
to that soon enough</div>
</blockquote>
<div><br>
</div>
<div>Everything will continue to work with
projects, but once middleware starts providing a
DOMAIN_ID and DOMAIN_NAME to the underlying
service, it'll be up to them to take advantage
of it. Images per domain is an excellent example
use case.</div>
</div>
</blockquote>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div> </div>
</div>
</blockquote>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px
0px 0px 0.8ex; border-left-width: 1px;
border-left-color: rgb(204, 204, 204);
border-left-style: solid; padding-left: 1ex;
position: static; z-index: auto; ">
<div style="word-wrap:break-word">
<div>- However, Cloud Providers want to start
enabling enterprise customers to run more
and more of the workloads in OpenStack
clouds - over and above, the smaller sized
companies that are doing this today. For
this to work, the encapsulation of a Domain
need, I think, to be able to be stricter -
and this is where the name space comes into
play. I think we need to allow for a Domain
to have its own namespace (i.e. users,
roles, projects etc.) as an option. I see
this as a first step to allowing each Domain
to have its own AuthZ/N service (.e.g
external ldap owned and hosted by the
customer who will be using the Domain)</div>
<div><br>
</div>
<div>Implementation:</div>
<div><br>
</div>
<div>- A simplistic version would just allow a
flag to specified on Domain creation that
said whether this a "private" or "shared"
Domain. Shared would use the current global
name space (and probably be the default for
compatibility reasons).</div>
</div>
</blockquote>
<div><br>
</div>
<div>I like the direction of this -- need to
digest implications :)</div>
</div>
</blockquote>
<div><br>
</div>
<div>I like the idea conceptually - but let's be clear
on the implications to the end users:</div>
<div><br>
</div>
<div>Where we're starting is preserving a global name
space for project names and user names. Allowing a
mix of segregated and global name spaces imposes a
burden of additional data being needed to uniquely
place authentication and authorization.</div>
<div><br>
</div>
<div>We've been keeping to 2 key pieces of info
(username, password) to get authenticated - and then
(via CLI or Horizon dashboard) you can choose from a
list of protential projects and carry on. In most
practical circumstances, any user working primarily
from the CLI is already providing 3-4 pieces of
information:</div>
<div><br>
</div>
<div>* username</div>
<div>* password</div>
<div>* tenant name</div>
<div>* auth_url</div>
<div><br>
</div>
<div>to access and use the cloud.</div>
<div><br>
</div>
<div>By allowing domains to be their own namespaces,
we're adding another element that will be absolutely
required to identify the person authenticating:</div>
<div> * domain name</div>
<div><br>
</div>
<div>implying a cascade of changes to the user
experience all the way down through horizon.</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>- A more flexible approach would be to
allow the specification of where the various
sub-services of Keystone (e.g. AuthN/Z,
Service Catalogue, Resources (i.e Users,
Projects)) are hosted. The defaults would
all point back to the default domain (i.e.
are global and shared), but instead could be
specified as "self" (I.e. the new Domain),
or, in the future, some other external
location, e.g. for a remote ldap.</div>
<div>- As an aside, this multi-name space
model could also allow the Cloud Provider
their own name space, separate from their
customers - i.e. they will have a need to
create admins who can just create domains
and on-board customers into those domains.
These users & roles could exist in the
default domain, while all the customers'
users/roles exist solely within their own
domains.</div>
<div>- One potential problem I do see is with
roles. Today, the role name is, if I
understand it correctly, a kind of shared
secret between, other services and Keystone
- e.g. it is the actual name of a given
role, say "ProjectAdmin" , that must match
in, say, the Nova policy file and the role
assignment in Keystone (please correct me if
I have this wrong).</div>
</div>
</blockquote>
<div><br>
</div>
<div>You're 100% correct.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap:break-word">
How would that work if the role names were not
unique across Domains?</div>
</blockquote>
<div><br>
</div>
<div>Not that we would want admins to ever see
Role ID's, or edit policy files with role ID's,
but they provide a potential solution.</div>
</div>
</blockquote>
<div><br>
</div>
<div>The different role names would need to be
accounted for in the policy files the way they're
set up today - the enforcement there is all at the
service level. There's no current provision for
evaluating policy differently based on domain. While
that's possible, it sounds like a tremendous cascade
of additional complication, as the policy, and
roles, are all set up and managed by deployers.</div>
<div><br>
</div>
<div>I think this might be an interesting addition in
the future, but want to keep the initial
implementation and roll-out of the policy mechanisms
and domains consistent and simple for a first
roll-out iteration.</div>
<div><br>
</div>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px
0px 0px 0.8ex; border-left-width: 1px;
border-left-color: rgb(204, 204, 204);
border-left-style: solid; padding-left: 1ex;
position: static; z-index: auto; ">
<div style="word-wrap:break-word">
<div>What is the desired functionality for a
Cloud Provider wanting to give their
enterprise customers this level of
flexibility - will they have dedicated Nova
endpoints anyway? Sounds too rigid. This
might tie into another bp we are working on
at IBM in terms of using Availability zones
to allow Cloud Providers to divide up their
compute resources in a more flexible way.</div>
<div>- Finally, I wanted to raise the subject
of whether we should make it a goal to
remain compatible with the v2 API <i>once
the cloud provider starts creating
additional domains</i>.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Joe and I briefly discussed this at the
summit. As a migration to v3, we'd obviously be
creating the default domain and mapping all
existing users/projectse/etc to it. I'd be fine
if the v2 implementation ONLY interacted with
resources in that default domain; i.e. if you
want to use domains, upgrade to a v3 client.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>As stated above, if just the default
domain is being used, then fine. And while
I agree that, technically, the v2 API should
still work with the above if all the other
domains point back to the default domain for
their sub-services - it feels overly
flexible (and maybe wrong conceptually) to
support v2 semantics across a multi-domain
installation.</div>
</div>
</blockquote>
<div><br>
</div>
<div>+1</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><br>
</div>
<div>Interested in everyone else's view.</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>Henry</div>
<div><br>
</div>
</font></span></div>
</blockquote>
</div>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>