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

Bryan Kearney bkearney at redhat.com
Tue Mar 30 20:42:38 UTC 2010


On 03/30/2010 03:45 PM, Adam Young wrote:
> On 03/30/2010 02:56 PM, Bryan Kearney wrote:
>> 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.
>
> Not completely. Right now, the user service just says yea or ny to a
> given auth attempt, and then sets the username. If we are going to map
> user names to roles within organizations, where those organizations are
> represented in cp_owner, we need to hold on to some information. At a
> minimum, we'll have to expand the user service API to somehow indicate
> the org that the user belongs to.

Agreed.. we would have to enhance the UserService to do 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.
>
> When I auth, the username attribute is added to my request via a filter.
> From that username, I can infer what organization the user is in,
> provided I have the info I specified above.

But in the resources, I dont see the request data. So.. is it on a 
thread local some place? Or, another context type object?

>
>>
>>>
>>> 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.
>
> You mean add an 'owner' field to the upload URL?

As an attribute to the consumer object.. yes.

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