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

Bryan Kearney bkearney at redhat.com
Tue Mar 30 21:24:22 UTC 2010


On 03/30/2010 04:46 PM, Adam Young wrote:
> 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.


Dmitri:

Is this still the valid approach for roles:

http://git.fedorahosted.org/git/candlepin.git/?p=candlepin.git;a=blob;f=proxy/src/main/java/org/fedoraproject/candlepin/security/RoleInterceptor.java;h=0fa7a0e54a4e5c402832098c0ddcf8d49bdcfdf2;hb=aop-security

If so, and guice gives us hte magic, i would be all for a context which 
we pull the data such as username and owner from.

-- bk



More information about the candlepin mailing list