11:15 a.m.
(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.
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
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.
2. As an on premise admin, I would like to load 2 different "satcerts"
for 2 different owners.
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
"person with role can read resource"
and
"person with role can modify resource"
And such should be on GET vs PUT, POST, and DELETE.
Note that a course grained poicy can be built out of fine grained
permissions. Actions (as specified in the above diagram) map to HTTP
verbs, and Resources (specified above) map to the URL based Methods on
the Resource. We then bundle up groups of those permissions in roles,
as well as the ability to dynamically add and remove them from an owner.
1:56 p.m.
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.
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.
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.
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
2:45 p.m.
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.
>
> 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.
>
> 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?
>
>
> 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
3:42 p.m.
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
3:46 p.m.
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
>
4:24 p.m.
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=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.
-- bk
9:57 a.m.
New subject: Fleshing out the Specification for multi-owner tasks in the BrainBox
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
5160
days inactive
5162
days old
candlepin@lists.fedorahosted.org
6 comments
3 participants
participants (3)
-
Adam Young -
Bryan Kearney -
Dmitri Dolguikh