9:57 a.m.
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=p...
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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
-d