[almighty] Multitenancy

Fri Sep 23 01:32:36 UTC 2016

On Thu, Sep 22, 2016 at 9:21 PM, Todd Mancini <tmancini at redhat.com> wrote:

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

I'm still a bit unclear as to whether Accounts from 2 different
Organizations can collaborate on the same Project.

My vote is for, yeah, any account on the system can be granted access to
any Project.  By that measure we don't couple Projects to Organizations.

I'm hoping to avoid the Slack model whereby a user has to sign in
separately to each of their channels.

S,
ALR

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

-- 
Red Hat Developer Programs Architecture
@ALRubinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160922/ce243d98/attachment.htm>