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

Dmitri Dolguikh dmitri at redhat.com
Thu Apr 1 14:57:39 UTC 2010


On 03/30/2010 06:24 PM, Bryan Kearney wrote:
> 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
>>>        
a couple of notes/comments: my understanding (Bryan, pls. correct me if 
I'm wrong) our roles don't quite follow a typical organizational 
hierarchy: we have consumers, org-admins (someone who can perform 
operations on any consumer within an organization) and super-admins 
(complete control). I think there was another role at the organization 
level.

We have two points of authorization: the first one UserService, the 
other one is SSLAuthFilter (only for consumer role, only when a client 
cert is present).


>>>        
>>>>          
>>>>>            
>>>>>> 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.
>>      
I would suggest introducing an object similar to JAAS' Prinicipal that 
contains both username, a list of roles, and possibly the organization 
id? If we put this object into HttpServletRequest (or in a ThreadLocal 
variable), it will be available for anybody to use (including aop 
interceptors).

>
> 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.
>    
Mostly valid. We are not relying on JAAS anymore, so there is no 
principal in the request, but we can implement a similar concept (as 
sketched out above) ourselves. Also, keep in mind that we'll need to do 
an actual check here, which may require a trip to db.

> -- bk
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>    

-d



More information about the candlepin mailing list