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