[almighty] Multitenancy

[Todd Mancini]

First, I think I read 'domain' differently than you intended, Max -- my bad.

In any event, we'll evolve a proper multi-tenancy definition, one that
matches market need but is also grounded in technical feasibility.

My sort-of-off-the-top-of-my-head-view is that there is a notion of an
"Account," which you could easily call an "Organization." Let's call it an
"Organization" for the moment, because I think people will grok that better.

An Organization has people in it (at least one). Organizations can be
defined entirely within ALMighty, or they can be mapped to some external
identification authority (e.g. SAML SSO). That's what I was getting at when
I said the 'gmail model', which is really the Google App model -- you can
either sign up as an individual (which, arguably, defines an organization
with a single person in it), or you can make a whole 'domain' of people. In
fact, the most common way to do that with Google is via SAML. Hence, in
gmail/Google Drive/etc., there is a notion of the "redhat.com"
organization, and Google defers the authentication for that over to
saml.redhat.com.

Within an organization (which may simply be a single individual), there can
be infinite projects. Only members of the org with sufficient rights can
create new projects.

People can be given rights to a project -- however, this extends out to
*all* persons, not just those within the organization. With sufficient
permissions, I should be able to invite anyone to be a part of my project.
I should be able to have a completely public project, permitting anyone to
view it/create new work items/etc. Eventually we'll want a strong
permission model on this. (e.g., let me set it up so that anyone can create
a new 'issue' in project Foo, but only 'project admins' can change the
status of an 'issue' from 'New' to 'Verified').

 Similarly, we need a notion of teams. A team is just a collection of
people. Although I may want to restrict a team to members of my
organization, I should also be able to have teams which include people
outside my organization.

As such, it would be convenient to also have security "groups" (which,
honestly, may simply be teams...I'm not 100% sure if it's needed to have
two different concepts), with some predefined such as "Everyone in my
organization" or "Any anonymous user." With just a few building blocks such
as these, it should be possible to build out most commonly desired access
models.

We've discussed Areas before, so I believe the combination of Projects +
Organizations + Users + Teams + Areas, with applicable control of access
rights at the Org, Project, and Area levels, provides an incredibly rich
security model.

Do we need ALL of that right now? No. But it's worth planning for it.

I think our primary focus today should be on Users, Projects and Areas. Let
a user sign in, let them make one or more Projects, let them define some
Areas, and let them give access to other Users as appropriate (with at
least some notion of an 'All Users' user, so I can make some projects
'public').

   Thoughts?
   -Todd

On Thu, Sep 22, 2016 at 6:47 PM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> On 23 Sep 2016, at 0:37, Todd Mancini wrote:
>
> It's not clear to me what URLs have to do with multi-tenancy. The VSTS
>> approach (which is actually one "org" per FQDN, but with infinite
>> projects per org) was chosen for technical reasons, not product
>> management ones.
>>
>
> it was more that VSTS by default seem to create much more separation
> between projects/orgs than
> anything else I've seen - if that is just pure perception then all good :)
>
> So, do you have a technical preference?
>>
>
> I'll let Aslak respond to that.
>
> The GitHub model seems to work well. But since we also plan to handle
>> enterprise SSO (via SAML, for example), the Gmail model also works well
>> (as far as PM is concerned). I'm not married to particular URL schemes.
>>
>
> gmail model ? you mean the separation of the gmail community offering vs
> the google product offerings
> where you get your own domain if you want to be truly separate ?
>
> /max
>
>
> Sent from my phone, so anticipate hilarious autocorrectsFrom: Max
>> Rydahl Andersen
>> Sent: ‎9/‎22/‎2016 6:24 PM
>> To: Andrew Lee Rubinger
>> Cc: ALMighty-public
>> Subject: Re: [almighty] Multitenancy
>> On 22 Sep 2016, at 21:08, Andrew Lee Rubinger wrote:
>>
>> On Thu, Sep 22, 2016 at 3:07 PM, Baiju Muthukadan
>>> <bmuthuka at redhat.com>
>>> wrote:
>>>
>>> Hi,
>>>>
>>>> ALMighty architecture is going to support Multitenancy, right?
>>>>
>>>> To the bone, yes.
>>>
>>
>> what is unclear though is how the multi tenancy will work.
>>
>> i.e. is it like github/jira where one instance under one url has many
>> projects with shared users/orgs
>> or is it more like VSO where each domain has one project with users
>> shared across many domains.
>>
>> Eagerly waiting for some of the "new project" PDD/UX stories to actually
>> start getting that settled down.
>>
>> /max
>>
>>
>>> Regards,
>>>> Baiju M
>>>>
>>>> _______________________________________________
>>>> almighty-public mailing list
>>>> almighty-public at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>>>
>>>>
>>>>
>>> --
>>> Red Hat Developer Programs Architecture
>>> @ALRubinger
>>>
>>
>> _______________________________________________
>>> almighty-public mailing list
>>> almighty-public at redhat.com
>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>>
>>
>> /max
>> http://about.me/maxandersen
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>
>
> /max
> http://about.me/maxandersen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160922/e975f795/attachment.htm>