You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/10/24 19:29:48 UTC
[Triplesec] [AuthZ] Environments and Groups
Environments and Groups
-------------------------------------
When releases are ready for deployment, systems and applications must be put
into
some operating environment. Within any environment identities will exist;
some
will be users, some services and some will be specific hosts. These
principals for
the sake of manageability are often categorized together into logical
associations.
By grouping identities together, administrators can handle them as a single
entity
where the same set of tasks may apply to the group whatever those management
operations may be.
Although groups are designed by administrators to simplify and reduce their
workload,
it's no coincidence that these groups are highly dependent on an
organization's structure
or the processes within an organization. General groups may exist for the
entire
organization. More specific groups will exist for the departments of an
organization.
When processes drive the creation of groups, membership is a based on
similar functions
required of a group's members. Sometimes processes are isolated to a
division, but more
often than not, processes span across divisions leading to the creation of
cross
divisional groups.
We extract more glossary definitions:
Group:
A set of distinctly identifiable entities which are categorically alike
within an
organization, organizational unit or with respect to some organizational
process.
Re: [Triplesec] [AuthZ] Environments and Groups
Posted by Emmanuel Lecharny <el...@gmail.com>.
Comments at the end...
David Jencks wrote:
>
> On Oct 30, 2007, at 9:19 PM, Alex Karasulu wrote:
>
>> Hi David,
>>
>> On 10/30/07, *David Jencks* <david_jencks@yahoo.com
>> <ma...@yahoo.com>> wrote:
>>
>>
>> On Oct 24, 2007, at 10:29 AM, Alex Karasulu wrote:
>>
>> > Environments and Groups
>> > -------------------------------------
>> >
>> > When releases are ready for deployment, systems and applications
>> > must be put into
>> > some operating environment. Within any environment identities will
>> > exist; some
>> > will be users, some services and some will be specific hosts. These
>> > principals for
>> > the sake of manageability are often categorized together into
>> > logical associations.
>> > By grouping identities together, administrators can handle them as
>> > a single entity
>> > where the same set of tasks may apply to the group whatever those
>> > management
>> > operations may be.
>> >
>> > Although groups are designed by administrators to simplify and
>> > reduce their workload,
>> > it's no coincidence that these groups are highly dependent on an
>> > organization's structure
>> > or the processes within an organization. General groups may exist
>> > for the entire
>> > organization. More specific groups will exist for the departments
>> > of an organization.
>> > When processes drive the creation of groups, membership is a based
>> > on similar functions
>> > required of a group's members. Sometimes processes are isolated to
>> > a division, but more
>> > often than not, processes span across divisions leading to the
>> > creation of cross
>> > divisional groups.
>> >
>>
>> I think this says that there's a set of Users (or principals?) we
>> need to keep track of and that if there are more than a few users we
>> will want to treat lots of them the same way.
>>
>>
>> Yes I was referring specifically to groups of users.
>>
>> But not suggesting that "we" store group definitions and their
>> members in Triplesec
>> necessarily. Users might do so with a Triplesec only solution if
>> external systems are not
>> to be utilized. Most likely we will be dealing with the mixed case
>> where users and groups
>> are defined in Triplesec and within external systems. Triplesec will
>> need to use some
>> techniques we can discuss later to refer to these externally defined
>> entities.
>>
>> Since we are
>> discussing authorization here I think this means that there are sets
>> of users we want to grant the same permissions with a single simple
>> operation.
>>
>>
>> Well I'm just talking about the purpose of grouping in general. I
>> think we can get
>> into this aspect in the role assignments thread. For now groups are
>> just sets of
>> objects although I refer to user groups specifically above.
>>
>> > We extract more glossary definitions:
>> >
>> > Group:
>> > A set of distinctly identifiable entities which are
>> > categorically alike within an
>> > organization, organizational unit or with respect to some
>> > organizational process.
>> >
>> I'm not sure what this means beyond "a group is a set of users".
>>
>>
>> Well you can group many things besides just human users. We can group
>> printers, processes, even organizations and their divisions etc.
>>
>> I'm sure everyone agrees that we need an easy way to take users who
>> need to do the same kind of stuff and treat them all in the same
>> way.
>>
>>
>> Yes! That's it. This is all we need to agree on in this thread.
>>
>> Even though "groups" are in most or all existing systems I'm
>> not sure our model or our discussion needs a separate concept from
>> "roles" to handle them.
>>
>>
>> No! It was going so well then this :). Groups have no security
>> connotation associated
>> with them. They're just sets or collections of objects. Some groups
>> may have a
>> uniqueness requirement so they're sets of objects. Others don't so
>> they're collections
>> of objects.
>>
>> Groups can be extended in several ways and we can talk about that
>> later but as a teaser
>> we have the following concepts/extensions:
>>
>> o nested groups
>> o static groups
>> o dynamic groups
>>
>> To me it seems that conceptually when you
>> start with users and ask "who does the same kind of job" you think
>> "group" but when you start with permissions and ask "what permissions
>> do we need to group together to get a useful task done" you think
>> "role".
>>
>>
>> You're mixing concepts here. I will state what I consider to be some
>> pretty concrete
>> and simple facts about groups and you can refute or agree with them:
>>
>> (1) A group is a set or collection of objects.
>
> I don't mean to quibble and I don't see how it makes any difference to
> meaning but what is the difference?
>
>> (2) A group does not have any security connotation associate with
>> it's definition. It's
>> merely an amalgamation.
>
> <flame>In that case why are we talking about it in the context of an
> authz manager?</flame>
>> (3) Groups are often defined to reduce the amount of management
>> overhead by enabling
>> administrators to apply one operation to a group of N members,
>> instead of N
>> operations on each member. The drive to maximize this benefit
>> over time brings about
>> different kinds of groupings that naturally align with processes
>> and organizational structures.
>> (4) A group need not be homogeneous.
>
> Not sure what you mean by this.
>
> I don't argue with any of this but don't see how it relates to whether
> "group" is an appropriate concept for an RBAC discussion. I've never
> denied that existing systems have groups defined in them and we have
> to work with these existing systems. Just because data is stored in
> something called a "group" doesn't, to me, mean we need to call it a
> group in our model or code.
>>
>> Not sure about the value #3 provides to the discussion but it sounds
>> good to say :-D.
>
> I like #3 the best myself :-)
>
> thanks
> david jencks
>
>>
>> Alex
>>
>
Well, I see there are two different visions about what 'groups' are and
how usefull they are in a Authz scope and how they can be seen as
'roles' in this scope.
My personal opinion is that normal humans just simply have it hard to
see all the servers of building A as a role. They usually point them as
'the bloody group of servers in building A are randomly rebooting every
day ' ... Or 'the group of printers in building B which roles is to
print payroll are totally outdated'.
Seriously, I would favor the 'group' usage when it comes to real life
entities (like users, printers, hosts) because this is what admin are
manipulating. It's not a concept, it's a collection of existing devices
(and humans :).
We can abstract those entities and say they are just defined by their
role (a DBA admin, a J2EE developper, a cost-killer, etc), but it's
easier to see them as part of groups (the developpers, the
admininstrators, the cost-killers, etc ...) with specific roles (A J2EE
developper, a DBA admin etc ...)
IMHO, of course :)
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Triplesec] [AuthZ] Environments and Groups
Posted by Alex Karasulu <ak...@apache.org>.
Hi David,
Again I am condensing down the content removing things we agree on.
On 10/31/07, David Jencks <da...@yahoo.com> wrote:
>
> (2) A group does not have any security connotation associate with it's
> definition. It's
> merely an amalgamation.
>
>
> <flame>In that case why are we talking about it in the context of an authz
> manager?</flame>
>
I am not doing that yet. You are failing to divide and conquer by doing
that yourself.
This thread is about applications and groups. Look at my original
definitions which
no where mentions an authorization manager.
That's the whole point.
I intend to start discussing these in the context of an authorization
manager later so we don't
get tunnel vision and mix concepts together into on big heap.
(3) Groups are often defined to reduce the amount of management overhead by
> enabling
> administrators to apply one operation to a group of N members,
> instead of N
> operations on each member. The drive to maximize this benefit over
> time brings about
> different kinds of groupings that naturally align with processes and
> organizational structures.
> (4) A group need not be homogeneous.
>
>
> Not sure what you mean by this.
>
> I don't argue with any of this but don't see how it relates to whether
> "group" is an appropriate concept for an RBAC discussion. I've never denied
> that existing systems have groups defined in them and we have to work with
> these existing systems. Just because data is stored in something called a
> "group" doesn't, to me, mean we need to call it a group in our model or
> code.
>
Well this is where I feel we have a complete disconnect. Yes we can call a
group a role
and mix concepts together. This IMO is poor design. Define the entities you
wish to model.
Then start modeling them. The point is a group exists and to 99% of the
developers, users,
and policy makers out there it is not equivalent to a role.
I don't want to code or maintain this and have to contort my mind to
translate a
natural representation into this model. The translation costs extra
energy. The number
of thoughts that can go through anyones mind in a day is finite. Say we
have a
slew of users, contributors, and committers and so now integrate that wasted
effort
over 99%. That amounts to a lot of collective energy wasted to conform to
this model
you propose.
Alex
Re: [Triplesec] [AuthZ] Environments and Groups
Posted by David Jencks <da...@yahoo.com>.
On Oct 30, 2007, at 9:19 PM, Alex Karasulu wrote:
> Hi David,
>
> On 10/30/07, David Jencks <da...@yahoo.com> wrote:
>
> On Oct 24, 2007, at 10:29 AM, Alex Karasulu wrote:
>
> > Environments and Groups
> > -------------------------------------
> >
> > When releases are ready for deployment, systems and applications
> > must be put into
> > some operating environment. Within any environment identities will
> > exist; some
> > will be users, some services and some will be specific hosts. These
> > principals for
> > the sake of manageability are often categorized together into
> > logical associations.
> > By grouping identities together, administrators can handle them as
> > a single entity
> > where the same set of tasks may apply to the group whatever those
> > management
> > operations may be.
> >
> > Although groups are designed by administrators to simplify and
> > reduce their workload,
> > it's no coincidence that these groups are highly dependent on an
> > organization's structure
> > or the processes within an organization. General groups may exist
> > for the entire
> > organization. More specific groups will exist for the departments
> > of an organization.
> > When processes drive the creation of groups, membership is a based
> > on similar functions
> > required of a group's members. Sometimes processes are isolated to
> > a division, but more
> > often than not, processes span across divisions leading to the
> > creation of cross
> > divisional groups.
> >
>
> I think this says that there's a set of Users (or principals?) we
> need to keep track of and that if there are more than a few users we
> will want to treat lots of them the same way.
>
> Yes I was referring specifically to groups of users.
>
> But not suggesting that "we" store group definitions and their
> members in Triplesec
> necessarily. Users might do so with a Triplesec only solution if
> external systems are not
> to be utilized. Most likely we will be dealing with the mixed case
> where users and groups
> are defined in Triplesec and within external systems. Triplesec
> will need to use some
> techniques we can discuss later to refer to these externally
> defined entities.
>
> Since we are
> discussing authorization here I think this means that there are sets
> of users we want to grant the same permissions with a single simple
> operation.
>
> Well I'm just talking about the purpose of grouping in general. I
> think we can get
> into this aspect in the role assignments thread. For now groups are
> just sets of
> objects although I refer to user groups specifically above.
>
> > We extract more glossary definitions:
> >
> > Group:
> > A set of distinctly identifiable entities which are
> > categorically alike within an
> > organization, organizational unit or with respect to some
> > organizational process.
> >
> I'm not sure what this means beyond "a group is a set of users".
>
> Well you can group many things besides just human users. We can group
> printers, processes, even organizations and their divisions etc.
>
> I'm sure everyone agrees that we need an easy way to take users who
> need to do the same kind of stuff and treat them all in the same
> way.
>
> Yes! That's it. This is all we need to agree on in this thread.
>
> Even though "groups" are in most or all existing systems I'm
> not sure our model or our discussion needs a separate concept from
> "roles" to handle them.
>
> No! It was going so well then this :). Groups have no security
> connotation associated
> with them. They're just sets or collections of objects. Some
> groups may have a
> uniqueness requirement so they're sets of objects. Others don't so
> they're collections
> of objects.
>
> Groups can be extended in several ways and we can talk about that
> later but as a teaser
> we have the following concepts/extensions:
>
> o nested groups
> o static groups
> o dynamic groups
>
> To me it seems that conceptually when you
> start with users and ask "who does the same kind of job" you think
> "group" but when you start with permissions and ask "what permissions
> do we need to group together to get a useful task done" you think
> "role".
>
> You're mixing concepts here. I will state what I consider to be
> some pretty concrete
> and simple facts about groups and you can refute or agree with them:
>
> (1) A group is a set or collection of objects.
I don't mean to quibble and I don't see how it makes any difference
to meaning but what is the difference?
> (2) A group does not have any security connotation associate with
> it's definition. It's
> merely an amalgamation.
<flame>In that case why are we talking about it in the context of an
authz manager?</flame>
> (3) Groups are often defined to reduce the amount of management
> overhead by enabling
> administrators to apply one operation to a group of N members,
> instead of N
> operations on each member. The drive to maximize this benefit
> over time brings about
> different kinds of groupings that naturally align with
> processes and organizational structures.
> (4) A group need not be homogeneous.
Not sure what you mean by this.
I don't argue with any of this but don't see how it relates to
whether "group" is an appropriate concept for an RBAC discussion.
I've never denied that existing systems have groups defined in them
and we have to work with these existing systems. Just because data
is stored in something called a "group" doesn't, to me, mean we need
to call it a group in our model or code.
>
> Not sure about the value #3 provides to the discussion but it
> sounds good to say :-D.
I like #3 the best myself :-)
thanks
david jencks
>
> Alex
>
Re: [Triplesec] [AuthZ] Environments and Groups
Posted by Alex Karasulu <ak...@apache.org>.
Hi David,
On 10/30/07, David Jencks <da...@yahoo.com> wrote:
>
>
> On Oct 24, 2007, at 10:29 AM, Alex Karasulu wrote:
>
> > Environments and Groups
> > -------------------------------------
> >
> > When releases are ready for deployment, systems and applications
> > must be put into
> > some operating environment. Within any environment identities will
> > exist; some
> > will be users, some services and some will be specific hosts. These
> > principals for
> > the sake of manageability are often categorized together into
> > logical associations.
> > By grouping identities together, administrators can handle them as
> > a single entity
> > where the same set of tasks may apply to the group whatever those
> > management
> > operations may be.
> >
> > Although groups are designed by administrators to simplify and
> > reduce their workload,
> > it's no coincidence that these groups are highly dependent on an
> > organization's structure
> > or the processes within an organization. General groups may exist
> > for the entire
> > organization. More specific groups will exist for the departments
> > of an organization.
> > When processes drive the creation of groups, membership is a based
> > on similar functions
> > required of a group's members. Sometimes processes are isolated to
> > a division, but more
> > often than not, processes span across divisions leading to the
> > creation of cross
> > divisional groups.
> >
>
> I think this says that there's a set of Users (or principals?) we
> need to keep track of and that if there are more than a few users we
> will want to treat lots of them the same way.
Yes I was referring specifically to groups of users.
But not suggesting that "we" store group definitions and their members in
Triplesec
necessarily. Users might do so with a Triplesec only solution if external
systems are not
to be utilized. Most likely we will be dealing with the mixed case where
users and groups
are defined in Triplesec and within external systems. Triplesec will need
to use some
techniques we can discuss later to refer to these externally defined
entities.
Since we are
> discussing authorization here I think this means that there are sets
> of users we want to grant the same permissions with a single simple
> operation.
Well I'm just talking about the purpose of grouping in general. I think we
can get
into this aspect in the role assignments thread. For now groups are just
sets of
objects although I refer to user groups specifically above.
> We extract more glossary definitions:
> >
> > Group:
> > A set of distinctly identifiable entities which are
> > categorically alike within an
> > organization, organizational unit or with respect to some
> > organizational process.
> >
> I'm not sure what this means beyond "a group is a set of users".
Well you can group many things besides just human users. We can group
printers, processes, even organizations and their divisions etc.
I'm sure everyone agrees that we need an easy way to take users who
> need to do the same kind of stuff and treat them all in the same
> way.
Yes! That's it. This is all we need to agree on in this thread.
Even though "groups" are in most or all existing systems I'm
> not sure our model or our discussion needs a separate concept from
> "roles" to handle them.
No! It was going so well then this :). Groups have no security connotation
associated
with them. They're just sets or collections of objects. Some groups may
have a
uniqueness requirement so they're sets of objects. Others don't so they're
collections
of objects.
Groups can be extended in several ways and we can talk about that later but
as a teaser
we have the following concepts/extensions:
o nested groups
o static groups
o dynamic groups
To me it seems that conceptually when you
> start with users and ask "who does the same kind of job" you think
> "group" but when you start with permissions and ask "what permissions
> do we need to group together to get a useful task done" you think
> "role".
You're mixing concepts here. I will state what I consider to be some pretty
concrete
and simple facts about groups and you can refute or agree with them:
(1) A group is a set or collection of objects.
(2) A group does not have any security connotation associate with it's
definition. It's
merely an amalgamation.
(3) Groups are often defined to reduce the amount of management overhead by
enabling
administrators to apply one operation to a group of N members, instead
of N
operations on each member. The drive to maximize this benefit over
time brings about
different kinds of groupings that naturally align with processes and
organizational structures.
(4) A group need not be homogeneous.
Not sure about the value #3 provides to the discussion but it sounds good to
say :-D.
Alex
Re: [Triplesec] [AuthZ] Environments and Groups
Posted by David Jencks <da...@yahoo.com>.
On Oct 24, 2007, at 10:29 AM, Alex Karasulu wrote:
> Environments and Groups
> -------------------------------------
>
> When releases are ready for deployment, systems and applications
> must be put into
> some operating environment. Within any environment identities will
> exist; some
> will be users, some services and some will be specific hosts. These
> principals for
> the sake of manageability are often categorized together into
> logical associations.
> By grouping identities together, administrators can handle them as
> a single entity
> where the same set of tasks may apply to the group whatever those
> management
> operations may be.
>
> Although groups are designed by administrators to simplify and
> reduce their workload,
> it's no coincidence that these groups are highly dependent on an
> organization's structure
> or the processes within an organization. General groups may exist
> for the entire
> organization. More specific groups will exist for the departments
> of an organization.
> When processes drive the creation of groups, membership is a based
> on similar functions
> required of a group's members. Sometimes processes are isolated to
> a division, but more
> often than not, processes span across divisions leading to the
> creation of cross
> divisional groups.
>
I think this says that there's a set of Users (or principals?) we
need to keep track of and that if there are more than a few users we
will want to treat lots of them the same way. Since we are
discussing authorization here I think this means that there are sets
of users we want to grant the same permissions with a single simple
operation.
> We extract more glossary definitions:
>
> Group:
> A set of distinctly identifiable entities which are
> categorically alike within an
> organization, organizational unit or with respect to some
> organizational process.
>
I'm not sure what this means beyond "a group is a set of users".
I'm sure everyone agrees that we need an easy way to take users who
need to do the same kind of stuff and treat them all in the same
way. Even though "groups" are in most or all existing systems I'm
not sure our model or our discussion needs a separate concept from
"roles" to handle them. To me it seems that conceptually when you
start with users and ask "who does the same kind of job" you think
"group" but when you start with permissions and ask "what permissions
do we need to group together to get a useful task done" you think
"role".
thanks
david jencks