<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 4:31 PM, John Dickinson <span dir="ltr"><<a href="mailto:me@not.mn" target="_blank">me@not.mn</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>




<div>
<div style="font-family:sans-serif"><div><div class="h5"><div style="white-space:normal"><br><br><p dir="auto">On 16 Mar 2017, at 14:10, Lance Bragstad wrote:</p>
</div>
<blockquote style="border-left:2px solid #777;color:#777;margin:0 0 5px;padding-left:5px"><div id="m_7320799342527715146939F14A6-2B03-42B8-8B25-68E57268F0FD"><div dir="ltr">Hey folks,<div><br></div><div>The reseller use case [0] has been popping up frequently in various discussions [1], including unified limits.</div><div><br></div><div>For those who are unfamiliar with the reseller concept, it came out of early discussions regarding hierarchical multi-tenancy (HMT). It essentially allows a certain level of opaqueness within project trees. This opaqueness would make it easier for providers to "resell" infrastructure, without having customers/providers see all the way up and down the project tree, hence it was termed reseller. Keystone originally had some ideas of how to implement this after the HMT implementation laid the ground work, but it was never finished.</div><div><br></div><div>With it popping back up in conversations, I'm looking for folks who are willing to represent the idea. Participating in this thread doesn't mean you're on the hook for implementing it or anything like that. </div><div><br></div><div>Are you interested in reseller and willing to provide use-cases?</div><div><br></div><div><br></div><div><br></div><div>[0] <a href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html#problem-description" target="_blank">http://specs.openstack.<wbr>org/openstack/keystone-specs/<wbr>specs/keystone/mitaka/<wbr>reseller.html#problem-<wbr>description</a></div></div></div></blockquote>
</div></div><div style="white-space:normal"><blockquote style="border-left:2px solid #777;color:#777;margin:0 0 5px;padding-left:5px">
</blockquote><br><p dir="auto">This is interesting to me. It sounds very similar to the reseller concept that Swift has. In Swift, the reseller is used to group accounts. Remember that an account in Swift is like a bank account. It's where you put stuff, and is mapped to one or more users via an auth system. So a Swift account is scoped to a particular reseller, and an auth system is responsible for one or more resellers.</p>
<p dir="auto">You can see this in practice with the "reseller prefix" that's used in Swift's URLs. The default is "AUTH_", so my account might be "AUTH_john". But it's totally possible that there could be another auth system assigned to a different reseller prefix. If that other reseller prefix is "BAUTH_", then there could exist a totally independent "BAUTH_john" account. The only thing that ties some user creds (or token) to a particular account in Swift is the auth system.</p>
<p dir="auto">So this reseller concept in Swift allows deployers to have more than one auth system installed in the same cluster at the same time. And, in fact, this is exactly why it was first used. If you get an account with Rackspace Cloud Files, you'll see the reseller prefix is "MossoCloudFS_", but it turns out that when Swift was created JungleDisk was an internal Rackspace product and also stored a bunch of data in the same system. JungleDisk managed it's own users and auth system, so they had a different reseller prefix that was tied to a different auth system.</p>
<p dir="auto">From the Keystone spec, it seems that the reseller idea is a way to group domains, very much like the reseller concept in Swift. I'd suggest that instead of building ever-increasing hierarchies of groups of users, supporting more than one auth system at a time is a proven way to scale out this solution. So instead of adding the complexity to Keystone of ever-deepening groupings, support having more than one Keystone instance (or even Keystone + another auth system) in a project's pipeline. This allows grouping users into distinct partitions, and it scales by adding more keystones instead of bigger keystones.</p></div></div></div></blockquote><div><br></div><div>This is super interesting, I've never thought about it this way before. In your example was there information that was shared that both auth systems needed? If so, do you remember how that was done?</div><div><br></div><div>So, if I think about this conceptually...</div><div><br></div><div>Is it safe to assume that both identity systems have to share a subset of information (i.e. regions, services, endpoints, roles, etc.) or they have to duplicate data? Phrasing it as a question actually reminds me of a time when folks came to keystone asking if they could isolate the storage of users and groups from the rest of the deployment (i.e. the identity table of keystone database would be region specific and the rest of the database would be shared globally). Instead of performing that isolation, we've seen that as more of need to improve federated use-cases (because why couldn't that be solved with federation). </div><div><br></div><div>So, building on your separate identity systems idea. What if we had a way to redirect authentication requests to an identity provider based on the domain being operated in? The other identity system could be keystone, it could be something else, whatever serves up SAML assertions. If you wanted to provide a reseller environment for a customer you could do so by setting up a keystone-to-keystone federated environment, making the reseller's keystone the identity provider for that domain. I guess the real big hurdle now is what to do with projects, because the whole idea of reseller is to have the ability to create and manage my own subtrees. In today's world, projects and domains are left up to the service provider to manage.</div><div><br></div><div>Feel free to reel me back in if I've gone off the deep end!</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><span class="HOEnZb"><font color="#888888">
<br><p dir="auto">--John</p>
<br><br><br></font></span></div>
</div>
</div>

<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>