On 03/30/2010 04:42 PM, Bryan Kearney wrote:
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?
So we have a few choices here. To enumerate:
A resource could be request scoped, and the owner gets passed to the
constructor
A resource could be (http) session scoped and the owner gets passed to
the constructor
A resource can be stateless (application scoped) and the owner is
fetched through a magic Global call that finds it in thread local storage
A resource can be stateless (application scoped) and the owner, if
needed, gets passed as a parameter to the method.
Out the gate I'd tend to favor the last option, as it involves the
fewest changes and the most flexibility to change our minds, but don't
know if our current API supports it.
>
>>
>>>
>>> 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
>