Open Stack

On Thu, Mar 16, 2017 at 4:31 PM, John Dickinson <me at not.mn> wrote:

>
>
> On 16 Mar 2017, at 14:10, Lance Bragstad wrote:
>
> Hey folks,
>
> The reseller use case [0] has been popping up frequently in various
> discussions [1], including unified limits.
>
> 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.
>
> 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.
>
> Are you interested in reseller and willing to provide use-cases?
>
>
>
> [0] http://specs.openstack.org/openstack/keystone-specs/
> specs/keystone/mitaka/reseller.html#problem-description
>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>

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?

So, if I think about this conceptually...

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

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.

Feel free to reel me back in if I've gone off the deep end!


>
> --John
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170316/debb86e6/attachment.html>