Fleshing out the Specification for multi-owner tasks in the BrainBox

Bryan Kearney bkearney at redhat.com
Tue Mar 30 18:56:38 UTC 2010


On 03/30/2010 12:15 PM, Adam Young wrote:
> (E2) Candlepin should support a multi-owner (multi-org/multi-tenant) model
>
>
>   From a data modle perspecitive, we need some way of representing an
> organization, and the ability to delegate authority down the tree, as
> well as revoke that authority.

Here was my high level assumption. Comments welcome:

I had assumed that the owner table in the data model was the org. We 
would need to be able to go out (directly or indirectly) to the user 
service to get the owner id. Since we are no longer using Jaas (which 
maybe we should put back) it can not be on the principal... but maybe 
there is another model we look at.

>
> I'm going to state the obvious:  a system like this will, at some point,
> have to tie in with a directory server(DS). We'll need to determine what
> set of information we cache from the DS as well as tree traversal strategy
>       do we read the whole tree on demand or read it up front...
>       do we register for events that change the tree

Allow the user service to deal with this.

>
> Assuming that we need to continue to run in stand alone (no LDAP) mode
> for the most part, we want to have an analogue for each of the classes in
>
> http://admiyo.fedorapeople.org/PartyPattern.png
>
> I know that we have some work being done in the authentication side of
> things, and I'd like to avoid duplicating effort there.
>
> 1. As a client, I would like to create the consumer for a specified owner.
>
> This says to me that a person in an organiztion higher in the tree needs
> to create one for an organization at the same level or lower in the tree.

I think a user ties to a single owner. So.. if the owner id is not 
specified in the POST, it could be inferred from that.

>
> 2. As an on premise admin, I would like to load 2 different "satcerts"
> for 2 different owners.
>

This may be a simple change to the data model and the upload logic.

>
>
> 3. As a security person, I want to ensure a user from owner 1 can not
> access data for owner.
> 4. As a security person, I want to ensure that a consumer from one owner
> can not access the subscriptions from another owner
>
>
>       To do this, we need to filter the enumeration of certain entities
> based on the organization of a given user.  THis is a specific
> application of the Role-Action-Resource portion of the linked diagram.
> Actions should mostly map to

This goes back to auth, so I will look for Dmitri to comment here.

-- bk



More information about the candlepin mailing list