Foreman and Organizations

My apologies for my short email. :slight_smile: I generally like the direction we
are going here, of allowing permissions to be set more broadly than at
the user level.

I just wonder, why create a new concept of ORG? Why not extend user
groups to provide this functionality, as I feel like much of what you
are describing is something that I would like to see at the user group
level.

For example, I want some pretty hefty puppet class permissions at
the user group level, allowing me to set which puppet classes users in a
specific group can see in their list of available classes, and tag nodes with.
Classes would not be restricted to being used by group and some groups could
be common to all user groups. There are many other enhancements that could
be done to user group permissions in the same vein, that appear to
overlap with ORG functionality.

Perhaps I am missing something fundamental here?

Thanks,
Brian

路路路 On Tue, Jul 24, 2012 at 4:41 PM, Greg Blomquist wrote: > Hi all, > > I apologize for the long email. > tl;dr: a discussion on the "organizations" feature for foreman; how it's > used, what's changed in foreman, open questions. > > I've been working on a feature for Foreman to add Organizations (aka, > Locations). The concept is to be able to group system objects together and > control access by users. You can see the code here: > https://github.com/theforeman/foreman/tree/orgs. > > Background > > With Organizations, an Admin can place system objects (Domains, Smart > Proxies, Compute Resources, etc...) into organizations and grant users > access to organizations. Users (non-admins) can only see system objects in > their organizations. > > Setup > > An installer can enable organizations for a foreman instance by setting the > "single_org" or "multi_org" foreman setting to true (in settings.yaml). > Foreman provides two ways to operate with organizations: > > single_org: In single_org mode, an Admin can grant a user access to several > organizations, but a user must select a single organization from an > Organization Dropdown while working in foreman. > multi_org: In multi_org mode, an Admin grants a user access to several > organizations, and the user can see all system objects in all granted > organizations. > > The single_org and multi_org modes do not control how many organizations a > user can belong to. Users can always belong to multiple orgs regardless of > this setting (see Current Organization(s) below). > > This allows foreman to provide flexibility in managing organizations. > > Administration > > Administrators are not bound to organizations, so admins can see all system > objects regardless of organizational association. Users (non-admins) are > assigned to organizations. Users can only see the system objects that are > associated to their organizations. > > Organizationally bound objects > > Compute Resources > Domains > Environments > Hostgroups > Installation Media > Smart Proxies > > > Organizations and Users > > When organizations are enabled, Users (specifically, non-admins) can belong > to multiple organizations. If organizations are enabled, then users can > only see system objects in their organizations. If a user is created and > not granted access to any organizations, the user will not see any > organizationally bound objects. If a system object is created and not > associated to any organizations, then no user will see the object (not even > those users who have no organization association). > > Current Organization(s) > > In single_org mode, if a user is associated with only one organization, that > organization becomes the user's "current organization". The current > organization provides foreman with the correct context for scope when > retrieving organizationally bound objects. If the user is associated with > multiple organizations, the user can select the current organization from an > organization drop down added to the topbar context. For the user in > multiple organizations, the default current organization is > User.current.organizations.first. > > When creating system objects in single_org mode, the user's current > organization is automatically associated with the system object being > created. For instance, when a user creates Domain "ABC" and has > Organization "X" currently selected. Domain "ABC" is automatically > associated with Organization "X". > > In multi_org mode, the current organizations is the list of organizations > the user is associated with. The user will be able to see all the object > associated to all of their organizations without having to select a current > organization. > > When creating system objects in multi_org mode, the user can select to add > the system object to any of their organizations via an "Organizations" tab > on the edit view. > > Implementation > > There are four key points of implementation: > > enabling organizations > tracking current organization(s) > changes to views > updating the default_scope for model associations > > Enabling organizations > > The config/settings.yaml file contains two new settings: single_org and > multi_org. These settings are mutually exclusive. They can both be false, > but they can't both be true. To enable organizations, the installer should > set either single_org or multi_org to true. > > Enabling organizations will enable the routes for organizations as well as > enable queries based on organization associations. > > I haven't tested enabling organizations, using organizations, then disabling > organizations. > > Tracking current organization(s) > > In single_org mode, the current organization is tracked similar to the > current user; in a thread local variable. When a user (non-admin) logs in, > the first organization (User.current.organizations.first) is selected as the > current organization. When the user changes the current organization using > the organization drop down, the thread local variable is updated. > > In multi_org mode, the current organizations is always > User.current.organizations. > > Changes to views > > An organization tab has been added to the form for system objects that are > organizationally bound. Administrators use the multi-checkbox on the > organizations tab to associated system objects to organizations. > > Updating default_scope for model associations > > In rails 3.0, the default_scope unnamed scope does not allow lambdas or > blocks. The default_scope is evaluated immediately upon definition instead > of being evaluated at the time of SQL composition. (This has been fixed in > rails 3.1 and moving forward: > https://rails.lighthouseapp.com/projects/8994/tickets/1812-default). In > order to restrict queries for organizationally bound system objects, the > processing of default_scope needed to change to allow a lambda to grab the > currently selected organization(s) based on the current user. This change > is implemented as an initializer monkey patch of > ActiveRecord::Base.current_scoped_methods. > > The side effect of this monkey patch is that it's not possible to stack > default_scopes that use lambdas and non-lambdas. For default_scopes that > use lambdas, all the default scoping should be contained in the lambda. > > With lambdas available for default_scope, the model object associations are > fairly straightforward. The class method Organization.apply_org_scope will > scope the caller on its relationship with organizations through the current > organization(s). Each model object for organizationally bound system > objects has a default_scope definition that calls > Organization.apply_org_scope in addition to any previous default scoping > that was applied before the organizations feature. > > Open questions > > What are other objects that should be organizationally bound? > > puppet classes > hosts > > How should user filters interact with organizational filtering? > When a user tries to create Domain "ABC" in Organization "X" and Domain > "ABC" already exists in Organization "Y", the user will receive an error > saying that "ABC" already exists. However, the user cannot access Domain > "ABC". How should the foreman deal with this situation? > > indicate the that Domain already exists, but the user does not have access > to the Domain in that organization? > alert administrators that a user tried to add Domain "ABC" to an different > Organization, and that perhaps the admin needs to associate the existing > "ABC" Domain with more orgs? > other ideas? > > Should there be a "default organization" setting a user can select that sets > the default current organization for the user upon login? > Is there a better way to represent the config/settings.yaml changes? > How do organizations and user groups coexist, if at all? > More questions? > > > > Thanks! > > ---- > Greg

I think that there should be both an expansion of the user group system and
how permissions work as well as organizations. User groups and
organizations do collide in a semantic way, though, so maybe user groups
need to be renamed to "permission groups" (that name kind of sucks, too.
Suggestions?). As the new names would suggest, permissions that can be
applied to groups of users (whether inside an organization or not) would
then be stored as "permission group" object and then users inside or
outside an organization can be placed into a permission group.

As for whether organizations are necessary, I definitely do think that they
are a worthwhile addition to Foreman. When looking at a tool like Katello,
it's clear how powerful an organization system can become to support
multi-tenant installations. That being said, having a way that Foreman can
run as a single org (without any of the organization-related
language/tools) is important, too, and allows a smooth upgrade path for
users who are already happily using Foreman and don't need the organization
tools.

Brian, as someone who is already using Foreman with several different
customer accounts, I'm interested in how useful you see more global
permissions groups along with organizations vs. a single user group model.
Thoughts?

路路路 On Thu, Jul 26, 2012 at 3:22 PM, Brian Gupta wrote:

My apologies for my short email. :slight_smile: I generally like the direction we
are going here, of allowing permissions to be set more broadly than at
the user level.

I just wonder, why create a new concept of ORG? Why not extend user
groups to provide this functionality, as I feel like much of what you
are describing is something that I would like to see at the user group
level.

For example, I want some pretty hefty puppet class permissions at
the user group level, allowing me to set which puppet classes users in a
specific group can see in their list of available classes, and tag nodes
with.
Classes would not be restricted to being used by group and some groups
could
be common to all user groups. There are many other enhancements that could
be done to user group permissions in the same vein, that appear to
overlap with ORG functionality.

Perhaps I am missing something fundamental here?

Thanks,
Brian

On Tue, Jul 24, 2012 at 4:41 PM, Greg Blomquist blomquisg@gmail.com > wrote:

Hi all,

I apologize for the long email.
tl;dr: a discussion on the 鈥渙rganizations鈥 feature for foreman; how it鈥檚
used, what鈥檚 changed in foreman, open questions.

I鈥檝e been working on a feature for Foreman to add Organizations (aka,
Locations). The concept is to be able to group system objects together
and
control access by users. You can see the code here:
https://github.com/theforeman/foreman/tree/orgs.

Background

With Organizations, an Admin can place system objects (Domains, Smart
Proxies, Compute Resources, etc鈥) into organizations and grant users
access to organizations. Users (non-admins) can only see system objects
in
their organizations.

Setup

An installer can enable organizations for a foreman instance by setting
the
"single_org" or 鈥渕ulti_org鈥 foreman setting to true (in settings.yaml).
Foreman provides two ways to operate with organizations:

single_org: In single_org mode, an Admin can grant a user access to
several
organizations, but a user must select a single organization from an
Organization Dropdown while working in foreman.
multi_org: In multi_org mode, an Admin grants a user access to several
organizations, and the user can see all system objects in all granted
organizations.

The single_org and multi_org modes do not control how many organizations
a
user can belong to. Users can always belong to multiple orgs regardless
of
this setting (see Current Organization(s) below).

This allows foreman to provide flexibility in managing organizations.

Administration

Administrators are not bound to organizations, so admins can see all
system
objects regardless of organizational association. Users (non-admins) are
assigned to organizations. Users can only see the system objects that
are
associated to their organizations.

Organizationally bound objects

Compute Resources
Domains
Environments
Hostgroups
Installation Media
Smart Proxies

Organizations and Users

When organizations are enabled, Users (specifically, non-admins) can
belong
to multiple organizations. If organizations are enabled, then users can
only see system objects in their organizations. If a user is created and
not granted access to any organizations, the user will not see any
organizationally bound objects. If a system object is created and not
associated to any organizations, then no user will see the object (not
even
those users who have no organization association).

Current Organization(s)

In single_org mode, if a user is associated with only one organization,
that
organization becomes the user鈥檚 鈥渃urrent organization鈥. The current
organization provides foreman with the correct context for scope when
retrieving organizationally bound objects. If the user is associated
with
multiple organizations, the user can select the current organization
from an
organization drop down added to the topbar context. For the user in
multiple organizations, the default current organization is
User.current.organizations.first.

When creating system objects in single_org mode, the user鈥檚 current
organization is automatically associated with the system object being
created. For instance, when a user creates Domain 鈥淎BC鈥 and has
Organization 鈥淴鈥 currently selected. Domain 鈥淎BC鈥 is automatically
associated with Organization 鈥淴鈥.

In multi_org mode, the current organizations is the list of organizations
the user is associated with. The user will be able to see all the object
associated to all of their organizations without having to select a
current
organization.

When creating system objects in multi_org mode, the user can select to
add
the system object to any of their organizations via an "Organizations"
tab
on the edit view.

Implementation

There are four key points of implementation:

enabling organizations
tracking current organization(s)
changes to views
updating the default_scope for model associations

Enabling organizations

The config/settings.yaml file contains two new settings: single_org and
multi_org. These settings are mutually exclusive. They can both be
false,
but they can鈥檛 both be true. To enable organizations, the installer
should
set either single_org or multi_org to true.

Enabling organizations will enable the routes for organizations as well
as
enable queries based on organization associations.

I haven鈥檛 tested enabling organizations, using organizations, then
disabling
organizations.

Tracking current organization(s)

In single_org mode, the current organization is tracked similar to the
current user; in a thread local variable. When a user (non-admin) logs
in,
the first organization (User.current.organizations.first) is selected as
the
current organization. When the user changes the current organization
using
the organization drop down, the thread local variable is updated.

In multi_org mode, the current organizations is always
User.current.organizations.

Changes to views

An organization tab has been added to the form for system objects that
are
organizationally bound. Administrators use the multi-checkbox on the
organizations tab to associated system objects to organizations.

Updating default_scope for model associations

In rails 3.0, the default_scope unnamed scope does not allow lambdas or
blocks. The default_scope is evaluated immediately upon definition
instead
of being evaluated at the time of SQL composition. (This has been fixed
in
rails 3.1 and moving forward:
https://rails.lighthouseapp.com/projects/8994/tickets/1812-default). In
order to restrict queries for organizationally bound system objects, the
processing of default_scope needed to change to allow a lambda to grab
the
currently selected organization(s) based on the current user. This
change
is implemented as an initializer monkey patch of
ActiveRecord::Base.current_scoped_methods.

The side effect of this monkey patch is that it鈥檚 not possible to stack
default_scopes that use lambdas and non-lambdas. For default_scopes that
use lambdas, all the default scoping should be contained in the lambda.

With lambdas available for default_scope, the model object associations
are
fairly straightforward. The class method Organization.apply_org_scope
will
scope the caller on its relationship with organizations through the
current
organization(s). Each model object for organizationally bound system
objects has a default_scope definition that calls
Organization.apply_org_scope in addition to any previous default scoping
that was applied before the organizations feature.

Open questions

What are other objects that should be organizationally bound?

puppet classes
hosts

How should user filters interact with organizational filtering?
When a user tries to create Domain 鈥淎BC鈥 in Organization 鈥淴鈥 and Domain
"ABC" already exists in Organization 鈥淵鈥, the user will receive an error
saying that 鈥淎BC鈥 already exists. However, the user cannot access Domain
"ABC". How should the foreman deal with this situation?

indicate the that Domain already exists, but the user does not have
access
to the Domain in that organization?
alert administrators that a user tried to add Domain 鈥淎BC鈥 to an
different
Organization, and that perhaps the admin needs to associate the existing
"ABC" Domain with more orgs?
other ideas?

Should there be a 鈥渄efault organization鈥 setting a user can select that
sets
the default current organization for the user upon login?
Is there a better way to represent the config/settings.yaml changes?
How do organizations and user groups coexist, if at all?
More questions?

Thanks!


Greg

I agree with the move of largr groups as well. When greg mentioned that
admine see all orgs, that worries me. I would assume we want to give folks
admin in some orgs, and user in others.

鈥揵 k

路路路 On Fri, Jul 27, 2012 at 11:16 AM, Sam Kottler wrote:

I think that there should be both an expansion of the user group system
and how permissions work as well as organizations. User groups and
organizations do collide in a semantic way, though, so maybe user groups
need to be renamed to 鈥減ermission groups鈥 (that name kind of sucks, too.
Suggestions?). As the new names would suggest, permissions that can be
applied to groups of users (whether inside an organization or not) would
then be stored as 鈥減ermission group鈥 object and then users inside or
outside an organization can be placed into a permission group.

As for whether organizations are necessary, I definitely do think that
they are a worthwhile addition to Foreman. When looking at a tool like
Katello, it鈥檚 clear how powerful an organization system can become to
support multi-tenant installations. That being said, having a way that
Foreman can run as a single org (without any of the organization-related
language/tools) is important, too, and allows a smooth upgrade path for
users who are already happily using Foreman and don鈥檛 need the organization
tools.

Brian, as someone who is already using Foreman with several different
customer accounts, I鈥檓 interested in how useful you see more global
permissions groups along with organizations vs. a single user group model.
Thoughts?

On Thu, Jul 26, 2012 at 3:22 PM, Brian Gupta brian.gupta@brandorr.comwrote:

My apologies for my short email. :slight_smile: I generally like the direction we
are going here, of allowing permissions to be set more broadly than at
the user level.

I just wonder, why create a new concept of ORG? Why not extend user
groups to provide this functionality, as I feel like much of what you
are describing is something that I would like to see at the user group
level.

For example, I want some pretty hefty puppet class permissions at
the user group level, allowing me to set which puppet classes users in a
specific group can see in their list of available classes, and tag nodes
with.
Classes would not be restricted to being used by group and some groups
could
be common to all user groups. There are many other enhancements that could
be done to user group permissions in the same vein, that appear to
overlap with ORG functionality.

Perhaps I am missing something fundamental here?

Thanks,
Brian

On Tue, Jul 24, 2012 at 4:41 PM, Greg Blomquist blomquisg@gmail.com >> wrote:

Hi all,

I apologize for the long email.
tl;dr: a discussion on the 鈥渙rganizations鈥 feature for foreman; how it鈥檚
used, what鈥檚 changed in foreman, open questions.

I鈥檝e been working on a feature for Foreman to add Organizations (aka,
Locations). The concept is to be able to group system objects together
and
control access by users. You can see the code here:
https://github.com/theforeman/foreman/tree/orgs.

Background

With Organizations, an Admin can place system objects (Domains, Smart
Proxies, Compute Resources, etc鈥) into organizations and grant users
access to organizations. Users (non-admins) can only see system
objects in
their organizations.

Setup

An installer can enable organizations for a foreman instance by setting
the
"single_org" or 鈥渕ulti_org鈥 foreman setting to true (in settings.yaml).
Foreman provides two ways to operate with organizations:

single_org: In single_org mode, an Admin can grant a user access to
several
organizations, but a user must select a single organization from an
Organization Dropdown while working in foreman.
multi_org: In multi_org mode, an Admin grants a user access to several
organizations, and the user can see all system objects in all granted
organizations.

The single_org and multi_org modes do not control how many
organizations a
user can belong to. Users can always belong to multiple orgs
regardless of
this setting (see Current Organization(s) below).

This allows foreman to provide flexibility in managing organizations.

Administration

Administrators are not bound to organizations, so admins can see all
system
objects regardless of organizational association. Users (non-admins)
are
assigned to organizations. Users can only see the system objects that
are
associated to their organizations.

Organizationally bound objects

Compute Resources
Domains
Environments
Hostgroups
Installation Media
Smart Proxies

Organizations and Users

When organizations are enabled, Users (specifically, non-admins) can
belong
to multiple organizations. If organizations are enabled, then users can
only see system objects in their organizations. If a user is created
and
not granted access to any organizations, the user will not see any
organizationally bound objects. If a system object is created and not
associated to any organizations, then no user will see the object (not
even
those users who have no organization association).

Current Organization(s)

In single_org mode, if a user is associated with only one organization,
that
organization becomes the user鈥檚 鈥渃urrent organization鈥. The current
organization provides foreman with the correct context for scope when
retrieving organizationally bound objects. If the user is associated
with
multiple organizations, the user can select the current organization
from an
organization drop down added to the topbar context. For the user in
multiple organizations, the default current organization is
User.current.organizations.first.

When creating system objects in single_org mode, the user鈥檚 current
organization is automatically associated with the system object being
created. For instance, when a user creates Domain 鈥淎BC鈥 and has
Organization 鈥淴鈥 currently selected. Domain 鈥淎BC鈥 is automatically
associated with Organization 鈥淴鈥.

In multi_org mode, the current organizations is the list of
organizations
the user is associated with. The user will be able to see all the
object
associated to all of their organizations without having to select a
current
organization.

When creating system objects in multi_org mode, the user can select to
add
the system object to any of their organizations via an "Organizations"
tab
on the edit view.

Implementation

There are four key points of implementation:

enabling organizations
tracking current organization(s)
changes to views
updating the default_scope for model associations

Enabling organizations

The config/settings.yaml file contains two new settings: single_org and
multi_org. These settings are mutually exclusive. They can both be
false,
but they can鈥檛 both be true. To enable organizations, the installer
should
set either single_org or multi_org to true.

Enabling organizations will enable the routes for organizations as well
as
enable queries based on organization associations.

I haven鈥檛 tested enabling organizations, using organizations, then
disabling
organizations.

Tracking current organization(s)

In single_org mode, the current organization is tracked similar to the
current user; in a thread local variable. When a user (non-admin) logs
in,
the first organization (User.current.organizations.first) is selected
as the
current organization. When the user changes the current organization
using
the organization drop down, the thread local variable is updated.

In multi_org mode, the current organizations is always
User.current.organizations.

Changes to views

An organization tab has been added to the form for system objects that
are
organizationally bound. Administrators use the multi-checkbox on the
organizations tab to associated system objects to organizations.

Updating default_scope for model associations

In rails 3.0, the default_scope unnamed scope does not allow lambdas or
blocks. The default_scope is evaluated immediately upon definition
instead
of being evaluated at the time of SQL composition. (This has been
fixed in
rails 3.1 and moving forward:
https://rails.lighthouseapp.com/projects/8994/tickets/1812-default).
In
order to restrict queries for organizationally bound system objects, the
processing of default_scope needed to change to allow a lambda to grab
the
currently selected organization(s) based on the current user. This
change
is implemented as an initializer monkey patch of
ActiveRecord::Base.current_scoped_methods.

The side effect of this monkey patch is that it鈥檚 not possible to stack
default_scopes that use lambdas and non-lambdas. For default_scopes
that
use lambdas, all the default scoping should be contained in the lambda.

With lambdas available for default_scope, the model object associations
are
fairly straightforward. The class method Organization.apply_org_scope
will
scope the caller on its relationship with organizations through the
current
organization(s). Each model object for organizationally bound system
objects has a default_scope definition that calls
Organization.apply_org_scope in addition to any previous default scoping
that was applied before the organizations feature.

Open questions

What are other objects that should be organizationally bound?

puppet classes
hosts

How should user filters interact with organizational filtering?
When a user tries to create Domain 鈥淎BC鈥 in Organization 鈥淴鈥 and Domain
"ABC" already exists in Organization 鈥淵鈥, the user will receive an error
saying that 鈥淎BC鈥 already exists. However, the user cannot access
Domain
"ABC". How should the foreman deal with this situation?

indicate the that Domain already exists, but the user does not have
access
to the Domain in that organization?
alert administrators that a user tried to add Domain 鈥淎BC鈥 to an
different
Organization, and that perhaps the admin needs to associate the existing
"ABC" Domain with more orgs?
other ideas?

Should there be a 鈥渄efault organization鈥 setting a user can select that
sets
the default current organization for the user upon login?
Is there a better way to represent the config/settings.yaml changes?
How do organizations and user groups coexist, if at all?
More questions?

Thanks!


Greg

Mmm鈥 had some more thoughts on this鈥

I think permissions should all be done at the user group level, and
all resources that a user group can be given permissions, should be
able to belong to a resource group, which can be a
container/abstraction for compute resources, domains, subnets, puppet
classes, puppet masters, dns servers, puppet environments, etc. A
resource can belong to more than one Resource Group. Basically, the
thought is that we have one type of group for things that can be
granted permissions, and another for things they would be granted
permissions to. As far as nesting goes, I do think that since
resources should be able to belong to more than one group, a resource
group, can contain one or more other resource groups, to support
nesting.

Perhaps this is to difficult to implement? Other thoughts? (I can
flesh out further, if people like the idea.)

-Brian

路路路 On Fri, Jul 27, 2012 at 11:16 AM, Sam Kottler wrote: > I think that there should be both an expansion of the user group system and > how permissions work as well as organizations. User groups and organizations > do collide in a semantic way, though, so maybe user groups need to be > renamed to "permission groups" (that name kind of sucks, too. Suggestions?). > As the new names would suggest, permissions that can be applied to groups of > users (whether inside an organization or not) would then be stored as > "permission group" object and then users inside or outside an organization > can be placed into a permission group. > > As for whether organizations are necessary, I definitely do think that they > are a worthwhile addition to Foreman. When looking at a tool like Katello, > it's clear how powerful an organization system can become to support > multi-tenant installations. That being said, having a way that Foreman can > run as a single org (without any of the organization-related language/tools) > is important, too, and allows a smooth upgrade path for users who are > already happily using Foreman and don't need the organization tools. > > Brian, as someone who is already using Foreman with several different > customer accounts, I'm interested in how useful you see more global > permissions groups along with organizations vs. a single user group model. > Thoughts? > > On Thu, Jul 26, 2012 at 3:22 PM, Brian Gupta > wrote: >> >> My apologies for my short email. :) I generally like the direction we >> are going here, of allowing permissions to be set more broadly than at >> the user level. >> >> I just wonder, why create a new concept of ORG? Why not extend user >> groups to provide this functionality, as I feel like much of what you >> are describing is something that I would like to see at the user group >> level. >> >> For example, I want some pretty hefty puppet class permissions at >> the user group level, allowing me to set which puppet classes users in a >> specific group can see in their list of available classes, and tag nodes >> with. >> Classes would not be restricted to being used by group and some groups >> could >> be common to all user groups. There are many other enhancements that could >> be done to user group permissions in the same vein, that appear to >> overlap with ORG functionality. >> >> Perhaps I am missing something fundamental here? >> >> Thanks, >> Brian >> >> On Tue, Jul 24, 2012 at 4:41 PM, Greg Blomquist >> wrote: >> > Hi all, >> > >> > I apologize for the long email. >> > tl;dr: a discussion on the "organizations" feature for foreman; how it's >> > used, what's changed in foreman, open questions. >> > >> > I've been working on a feature for Foreman to add Organizations (aka, >> > Locations). The concept is to be able to group system objects together >> > and >> > control access by users. You can see the code here: >> > https://github.com/theforeman/foreman/tree/orgs. >> > >> > Background >> > >> > With Organizations, an Admin can place system objects (Domains, Smart >> > Proxies, Compute Resources, etc...) into organizations and grant users >> > access to organizations. Users (non-admins) can only see system objects >> > in >> > their organizations. >> > >> > Setup >> > >> > An installer can enable organizations for a foreman instance by setting >> > the >> > "single_org" or "multi_org" foreman setting to true (in settings.yaml). >> > Foreman provides two ways to operate with organizations: >> > >> > single_org: In single_org mode, an Admin can grant a user access to >> > several >> > organizations, but a user must select a single organization from an >> > Organization Dropdown while working in foreman. >> > multi_org: In multi_org mode, an Admin grants a user access to several >> > organizations, and the user can see all system objects in all granted >> > organizations. >> > >> > The single_org and multi_org modes do not control how many organizations >> > a >> > user can belong to. Users can always belong to multiple orgs regardless >> > of >> > this setting (see Current Organization(s) below). >> > >> > This allows foreman to provide flexibility in managing organizations. >> > >> > Administration >> > >> > Administrators are not bound to organizations, so admins can see all >> > system >> > objects regardless of organizational association. Users (non-admins) >> > are >> > assigned to organizations. Users can only see the system objects that >> > are >> > associated to their organizations. >> > >> > Organizationally bound objects >> > >> > Compute Resources >> > Domains >> > Environments >> > Hostgroups >> > Installation Media >> > Smart Proxies >> > >> > >> > Organizations and Users >> > >> > When organizations are enabled, Users (specifically, non-admins) can >> > belong >> > to multiple organizations. If organizations are enabled, then users can >> > only see system objects in their organizations. If a user is created >> > and >> > not granted access to any organizations, the user will not see any >> > organizationally bound objects. If a system object is created and not >> > associated to any organizations, then no user will see the object (not >> > even >> > those users who have no organization association). >> > >> > Current Organization(s) >> > >> > In single_org mode, if a user is associated with only one organization, >> > that >> > organization becomes the user's "current organization". The current >> > organization provides foreman with the correct context for scope when >> > retrieving organizationally bound objects. If the user is associated >> > with >> > multiple organizations, the user can select the current organization >> > from an >> > organization drop down added to the topbar context. For the user in >> > multiple organizations, the default current organization is >> > User.current.organizations.first. >> > >> > When creating system objects in single_org mode, the user's current >> > organization is automatically associated with the system object being >> > created. For instance, when a user creates Domain "ABC" and has >> > Organization "X" currently selected. Domain "ABC" is automatically >> > associated with Organization "X". >> > >> > In multi_org mode, the current organizations is the list of >> > organizations >> > the user is associated with. The user will be able to see all the >> > object >> > associated to all of their organizations without having to select a >> > current >> > organization. >> > >> > When creating system objects in multi_org mode, the user can select to >> > add >> > the system object to any of their organizations via an "Organizations" >> > tab >> > on the edit view. >> > >> > Implementation >> > >> > There are four key points of implementation: >> > >> > enabling organizations >> > tracking current organization(s) >> > changes to views >> > updating the default_scope for model associations >> > >> > Enabling organizations >> > >> > The config/settings.yaml file contains two new settings: single_org and >> > multi_org. These settings are mutually exclusive. They can both be >> > false, >> > but they can't both be true. To enable organizations, the installer >> > should >> > set either single_org or multi_org to true. >> > >> > Enabling organizations will enable the routes for organizations as well >> > as >> > enable queries based on organization associations. >> > >> > I haven't tested enabling organizations, using organizations, then >> > disabling >> > organizations. >> > >> > Tracking current organization(s) >> > >> > In single_org mode, the current organization is tracked similar to the >> > current user; in a thread local variable. When a user (non-admin) logs >> > in, >> > the first organization (User.current.organizations.first) is selected as >> > the >> > current organization. When the user changes the current organization >> > using >> > the organization drop down, the thread local variable is updated. >> > >> > In multi_org mode, the current organizations is always >> > User.current.organizations. >> > >> > Changes to views >> > >> > An organization tab has been added to the form for system objects that >> > are >> > organizationally bound. Administrators use the multi-checkbox on the >> > organizations tab to associated system objects to organizations. >> > >> > Updating default_scope for model associations >> > >> > In rails 3.0, the default_scope unnamed scope does not allow lambdas or >> > blocks. The default_scope is evaluated immediately upon definition >> > instead >> > of being evaluated at the time of SQL composition. (This has been fixed >> > in >> > rails 3.1 and moving forward: >> > https://rails.lighthouseapp.com/projects/8994/tickets/1812-default). In >> > order to restrict queries for organizationally bound system objects, the >> > processing of default_scope needed to change to allow a lambda to grab >> > the >> > currently selected organization(s) based on the current user. This >> > change >> > is implemented as an initializer monkey patch of >> > ActiveRecord::Base.current_scoped_methods. >> > >> > The side effect of this monkey patch is that it's not possible to stack >> > default_scopes that use lambdas and non-lambdas. For default_scopes >> > that >> > use lambdas, all the default scoping should be contained in the lambda. >> > >> > With lambdas available for default_scope, the model object associations >> > are >> > fairly straightforward. The class method Organization.apply_org_scope >> > will >> > scope the caller on its relationship with organizations through the >> > current >> > organization(s). Each model object for organizationally bound system >> > objects has a default_scope definition that calls >> > Organization.apply_org_scope in addition to any previous default scoping >> > that was applied before the organizations feature. >> > >> > Open questions >> > >> > What are other objects that should be organizationally bound? >> > >> > puppet classes >> > hosts >> > >> > How should user filters interact with organizational filtering? >> > When a user tries to create Domain "ABC" in Organization "X" and Domain >> > "ABC" already exists in Organization "Y", the user will receive an error >> > saying that "ABC" already exists. However, the user cannot access >> > Domain >> > "ABC". How should the foreman deal with this situation? >> > >> > indicate the that Domain already exists, but the user does not have >> > access >> > to the Domain in that organization? >> > alert administrators that a user tried to add Domain "ABC" to an >> > different >> > Organization, and that perhaps the admin needs to associate the existing >> > "ABC" Domain with more orgs? >> > other ideas? >> > >> > Should there be a "default organization" setting a user can select that >> > sets >> > the default current organization for the user upon login? >> > Is there a better way to represent the config/settings.yaml changes? >> > How do organizations and user groups coexist, if at all? >> > More questions? >> > >> > >> > >> > Thanks! >> > >> > ---- >> > Greg > >

> I agree with the move of largr groups as well. When greg mentioned that
> admine see all orgs, that worries me. I would assume we want to give folks
> admin in some orgs, and user in others.

Wont that be the rbac role of your liking role that you add to a user
within an org?

a foreman admin is someone that can manage everything (including adding new
orgs, etc) which in fact has no permission limitations what so ever.

does that make sense?

Ohad

路路路 On Mon, Jul 30, 2012 at 7:24 PM, Bryan Kearney wrote:

鈥揵 k

On Fri, Jul 27, 2012 at 11:16 AM, Sam Kottler sam@kottlerdevelopment.comwrote:

I think that there should be both an expansion of the user group system
and how permissions work as well as organizations. User groups and
organizations do collide in a semantic way, though, so maybe user groups
need to be renamed to 鈥減ermission groups鈥 (that name kind of sucks, too.
Suggestions?). As the new names would suggest, permissions that can be
applied to groups of users (whether inside an organization or not) would
then be stored as 鈥減ermission group鈥 object and then users inside or
outside an organization can be placed into a permission group.

As for whether organizations are necessary, I definitely do think that
they are a worthwhile addition to Foreman. When looking at a tool like
Katello, it鈥檚 clear how powerful an organization system can become to
support multi-tenant installations. That being said, having a way that
Foreman can run as a single org (without any of the organization-related
language/tools) is important, too, and allows a smooth upgrade path for
users who are already happily using Foreman and don鈥檛 need the organization
tools.

Brian, as someone who is already using Foreman with several different
customer accounts, I鈥檓 interested in how useful you see more global
permissions groups along with organizations vs. a single user group model.
Thoughts?

On Thu, Jul 26, 2012 at 3:22 PM, Brian Gupta brian.gupta@brandorr.comwrote:

My apologies for my short email. :slight_smile: I generally like the direction we
are going here, of allowing permissions to be set more broadly than at
the user level.

I just wonder, why create a new concept of ORG? Why not extend user
groups to provide this functionality, as I feel like much of what you
are describing is something that I would like to see at the user group
level.

For example, I want some pretty hefty puppet class permissions at
the user group level, allowing me to set which puppet classes users in a
specific group can see in their list of available classes, and tag nodes
with.
Classes would not be restricted to being used by group and some groups
could
be common to all user groups. There are many other enhancements that
could
be done to user group permissions in the same vein, that appear to
overlap with ORG functionality.

Perhaps I am missing something fundamental here?

Thanks,
Brian

On Tue, Jul 24, 2012 at 4:41 PM, Greg Blomquist blomquisg@gmail.com >>> wrote:

Hi all,

I apologize for the long email.
tl;dr: a discussion on the 鈥渙rganizations鈥 feature for foreman; how
it鈥檚
used, what鈥檚 changed in foreman, open questions.

I鈥檝e been working on a feature for Foreman to add Organizations (aka,
Locations). The concept is to be able to group system objects
together and
control access by users. You can see the code here:
https://github.com/theforeman/foreman/tree/orgs.

Background

With Organizations, an Admin can place system objects (Domains, Smart
Proxies, Compute Resources, etc鈥) into organizations and grant users
access to organizations. Users (non-admins) can only see system
objects in
their organizations.

Setup

An installer can enable organizations for a foreman instance by
setting the
"single_org" or 鈥渕ulti_org鈥 foreman setting to true (in settings.yaml).
Foreman provides two ways to operate with organizations:

single_org: In single_org mode, an Admin can grant a user access to
several
organizations, but a user must select a single organization from an
Organization Dropdown while working in foreman.
multi_org: In multi_org mode, an Admin grants a user access to several
organizations, and the user can see all system objects in all granted
organizations.

The single_org and multi_org modes do not control how many
organizations a
user can belong to. Users can always belong to multiple orgs
regardless of
this setting (see Current Organization(s) below).

This allows foreman to provide flexibility in managing organizations.

Administration

Administrators are not bound to organizations, so admins can see all
system
objects regardless of organizational association. Users (non-admins)
are
assigned to organizations. Users can only see the system objects that
are
associated to their organizations.

Organizationally bound objects

Compute Resources
Domains
Environments
Hostgroups
Installation Media
Smart Proxies

Organizations and Users

When organizations are enabled, Users (specifically, non-admins) can
belong
to multiple organizations. If organizations are enabled, then users
can
only see system objects in their organizations. If a user is created
and
not granted access to any organizations, the user will not see any
organizationally bound objects. If a system object is created and not
associated to any organizations, then no user will see the object (not
even
those users who have no organization association).

Current Organization(s)

In single_org mode, if a user is associated with only one
organization, that
organization becomes the user鈥檚 鈥渃urrent organization鈥. The current
organization provides foreman with the correct context for scope when
retrieving organizationally bound objects. If the user is associated
with
multiple organizations, the user can select the current organization
from an
organization drop down added to the topbar context. For the user in
multiple organizations, the default current organization is
User.current.organizations.first.

When creating system objects in single_org mode, the user鈥檚 current
organization is automatically associated with the system object being
created. For instance, when a user creates Domain 鈥淎BC鈥 and has
Organization 鈥淴鈥 currently selected. Domain 鈥淎BC鈥 is automatically
associated with Organization 鈥淴鈥.

In multi_org mode, the current organizations is the list of
organizations
the user is associated with. The user will be able to see all the
object
associated to all of their organizations without having to select a
current
organization.

When creating system objects in multi_org mode, the user can select to
add
the system object to any of their organizations via an "Organizations"
tab
on the edit view.

Implementation

There are four key points of implementation:

enabling organizations
tracking current organization(s)
changes to views
updating the default_scope for model associations

Enabling organizations

The config/settings.yaml file contains two new settings: single_org
and
multi_org. These settings are mutually exclusive. They can both be
false,
but they can鈥檛 both be true. To enable organizations, the installer
should
set either single_org or multi_org to true.

Enabling organizations will enable the routes for organizations as
well as
enable queries based on organization associations.

I haven鈥檛 tested enabling organizations, using organizations, then
disabling
organizations.

Tracking current organization(s)

In single_org mode, the current organization is tracked similar to the
current user; in a thread local variable. When a user (non-admin)
logs in,
the first organization (User.current.organizations.first) is selected
as the
current organization. When the user changes the current organization
using
the organization drop down, the thread local variable is updated.

In multi_org mode, the current organizations is always
User.current.organizations.

Changes to views

An organization tab has been added to the form for system objects that
are
organizationally bound. Administrators use the multi-checkbox on the
organizations tab to associated system objects to organizations.

Updating default_scope for model associations

In rails 3.0, the default_scope unnamed scope does not allow lambdas or
blocks. The default_scope is evaluated immediately upon definition
instead
of being evaluated at the time of SQL composition. (This has been
fixed in
rails 3.1 and moving forward:
https://rails.lighthouseapp.com/projects/8994/tickets/1812-default).
In
order to restrict queries for organizationally bound system objects,
the
processing of default_scope needed to change to allow a lambda to grab
the
currently selected organization(s) based on the current user. This
change
is implemented as an initializer monkey patch of
ActiveRecord::Base.current_scoped_methods.

The side effect of this monkey patch is that it鈥檚 not possible to stack
default_scopes that use lambdas and non-lambdas. For default_scopes
that
use lambdas, all the default scoping should be contained in the lambda.

With lambdas available for default_scope, the model object
associations are
fairly straightforward. The class method Organization.apply_org_scope
will
scope the caller on its relationship with organizations through the
current
organization(s). Each model object for organizationally bound system
objects has a default_scope definition that calls
Organization.apply_org_scope in addition to any previous default
scoping
that was applied before the organizations feature.

Open questions

What are other objects that should be organizationally bound?

puppet classes
hosts

How should user filters interact with organizational filtering?
When a user tries to create Domain 鈥淎BC鈥 in Organization 鈥淴鈥 and Domain
"ABC" already exists in Organization 鈥淵鈥, the user will receive an
error
saying that 鈥淎BC鈥 already exists. However, the user cannot access
Domain
"ABC". How should the foreman deal with this situation?

indicate the that Domain already exists, but the user does not have
access
to the Domain in that organization?
alert administrators that a user tried to add Domain 鈥淎BC鈥 to an
different
Organization, and that perhaps the admin needs to associate the
existing
"ABC" Domain with more orgs?
other ideas?

Should there be a 鈥渄efault organization鈥 setting a user can select
that sets
the default current organization for the user upon login?
Is there a better way to represent the config/settings.yaml changes?
How do organizations and user groups coexist, if at all?
More questions?

Thanks!


Greg

> Mmm鈥 had some more thoughts on this鈥
>
> I think permissions should all be done at the user group level, and
> all resources that a user group can be given permissions, should be
> able to belong to a resource group, which can be a
> container/abstraction for compute resources, domains, subnets, puppet
> classes, puppet masters, dns servers, puppet environments, etc. A
> resource can belong to more than one Resource Group. Basically, the
> thought is that we have one type of group for things that can be
> granted permissions, and another for things they would be granted
> permissions to. As far as nesting goes, I do think that since
> resources should be able to belong to more than one group, a resource
> group, can contain one or more other resource groups, to support
> nesting.
>
> Perhaps this is to difficult to implement? Other thoughts? (I can
> flesh out further, if people like the idea.)
>

how do you model a location in this approach ?
e.g., when deploying to location XX I want to see in the dropdowns only
relevant options.

Ohad

路路路 On Mon, Jul 30, 2012 at 7:37 PM, Brian Gupta wrote:

-Brian

On Fri, Jul 27, 2012 at 11:16 AM, Sam Kottler > sam@kottlerdevelopment.com wrote:

I think that there should be both an expansion of the user group system
and
how permissions work as well as organizations. User groups and
organizations
do collide in a semantic way, though, so maybe user groups need to be
renamed to 鈥減ermission groups鈥 (that name kind of sucks, too.
Suggestions?).
As the new names would suggest, permissions that can be applied to
groups of
users (whether inside an organization or not) would then be stored as
"permission group" object and then users inside or outside an
organization
can be placed into a permission group.

As for whether organizations are necessary, I definitely do think that
they
are a worthwhile addition to Foreman. When looking at a tool like
Katello,
it鈥檚 clear how powerful an organization system can become to support
multi-tenant installations. That being said, having a way that Foreman
can
run as a single org (without any of the organization-related
language/tools)
is important, too, and allows a smooth upgrade path for users who are
already happily using Foreman and don鈥檛 need the organization tools.

Brian, as someone who is already using Foreman with several different
customer accounts, I鈥檓 interested in how useful you see more global
permissions groups along with organizations vs. a single user group
model.
Thoughts?

On Thu, Jul 26, 2012 at 3:22 PM, Brian Gupta brian.gupta@brandorr.com > > wrote:

My apologies for my short email. :slight_smile: I generally like the direction we
are going here, of allowing permissions to be set more broadly than at
the user level.

I just wonder, why create a new concept of ORG? Why not extend user
groups to provide this functionality, as I feel like much of what you
are describing is something that I would like to see at the user group
level.

For example, I want some pretty hefty puppet class permissions at
the user group level, allowing me to set which puppet classes users in a
specific group can see in their list of available classes, and tag nodes
with.
Classes would not be restricted to being used by group and some groups
could
be common to all user groups. There are many other enhancements that
could

be done to user group permissions in the same vein, that appear to
overlap with ORG functionality.

Perhaps I am missing something fundamental here?

Thanks,
Brian

On Tue, Jul 24, 2012 at 4:41 PM, Greg Blomquist blomquisg@gmail.com > >> wrote:

Hi all,

I apologize for the long email.
tl;dr: a discussion on the 鈥渙rganizations鈥 feature for foreman; how
it鈥檚

used, what鈥檚 changed in foreman, open questions.

I鈥檝e been working on a feature for Foreman to add Organizations (aka,
Locations). The concept is to be able to group system objects
together

and
control access by users. You can see the code here:
https://github.com/theforeman/foreman/tree/orgs.

Background

With Organizations, an Admin can place system objects (Domains, Smart
Proxies, Compute Resources, etc鈥) into organizations and grant users
access to organizations. Users (non-admins) can only see system
objects

in
their organizations.

Setup

An installer can enable organizations for a foreman instance by
setting

the
"single_org" or 鈥渕ulti_org鈥 foreman setting to true (in
settings.yaml).

Foreman provides two ways to operate with organizations:

single_org: In single_org mode, an Admin can grant a user access to
several
organizations, but a user must select a single organization from an
Organization Dropdown while working in foreman.
multi_org: In multi_org mode, an Admin grants a user access to
several

organizations, and the user can see all system objects in all granted
organizations.

The single_org and multi_org modes do not control how many
organizations

a
user can belong to. Users can always belong to multiple orgs
regardless

of
this setting (see Current Organization(s) below).

This allows foreman to provide flexibility in managing organizations.

Administration

Administrators are not bound to organizations, so admins can see all
system
objects regardless of organizational association. Users (non-admins)
are
assigned to organizations. Users can only see the system objects that
are
associated to their organizations.

Organizationally bound objects

Compute Resources
Domains
Environments
Hostgroups
Installation Media
Smart Proxies

Organizations and Users

When organizations are enabled, Users (specifically, non-admins) can
belong
to multiple organizations. If organizations are enabled, then users
can

only see system objects in their organizations. If a user is created
and
not granted access to any organizations, the user will not see any
organizationally bound objects. If a system object is created and not
associated to any organizations, then no user will see the object (not
even
those users who have no organization association).

Current Organization(s)

In single_org mode, if a user is associated with only one
organization,

that
organization becomes the user鈥檚 鈥渃urrent organization鈥. The current
organization provides foreman with the correct context for scope when
retrieving organizationally bound objects. If the user is associated
with
multiple organizations, the user can select the current organization
from an
organization drop down added to the topbar context. For the user in
multiple organizations, the default current organization is
User.current.organizations.first.

When creating system objects in single_org mode, the user鈥檚 current
organization is automatically associated with the system object being
created. For instance, when a user creates Domain 鈥淎BC鈥 and has
Organization 鈥淴鈥 currently selected. Domain 鈥淎BC鈥 is automatically
associated with Organization 鈥淴鈥.

In multi_org mode, the current organizations is the list of
organizations
the user is associated with. The user will be able to see all the
object
associated to all of their organizations without having to select a
current
organization.

When creating system objects in multi_org mode, the user can select to
add
the system object to any of their organizations via an "Organizations"
tab
on the edit view.

Implementation

There are four key points of implementation:

enabling organizations
tracking current organization(s)
changes to views
updating the default_scope for model associations

Enabling organizations

The config/settings.yaml file contains two new settings: single_org
and

multi_org. These settings are mutually exclusive. They can both be
false,
but they can鈥檛 both be true. To enable organizations, the installer
should
set either single_org or multi_org to true.

Enabling organizations will enable the routes for organizations as
well

as
enable queries based on organization associations.

I haven鈥檛 tested enabling organizations, using organizations, then
disabling
organizations.

Tracking current organization(s)

In single_org mode, the current organization is tracked similar to the
current user; in a thread local variable. When a user (non-admin)
logs

in,
the first organization (User.current.organizations.first) is selected
as

the
current organization. When the user changes the current organization
using
the organization drop down, the thread local variable is updated.

In multi_org mode, the current organizations is always
User.current.organizations.

Changes to views

An organization tab has been added to the form for system objects that
are
organizationally bound. Administrators use the multi-checkbox on the
organizations tab to associated system objects to organizations.

Updating default_scope for model associations

In rails 3.0, the default_scope unnamed scope does not allow lambdas
or

blocks. The default_scope is evaluated immediately upon definition
instead
of being evaluated at the time of SQL composition. (This has been
fixed

in
rails 3.1 and moving forward:
https://rails.lighthouseapp.com/projects/8994/tickets/1812-default).
In

order to restrict queries for organizationally bound system objects,
the

processing of default_scope needed to change to allow a lambda to grab
the
currently selected organization(s) based on the current user. This
change
is implemented as an initializer monkey patch of
ActiveRecord::Base.current_scoped_methods.

The side effect of this monkey patch is that it鈥檚 not possible to
stack

default_scopes that use lambdas and non-lambdas. For default_scopes
that
use lambdas, all the default scoping should be contained in the
lambda.

With lambdas available for default_scope, the model object
associations

are
fairly straightforward. The class method Organization.apply_org_scope
will
scope the caller on its relationship with organizations through the
current
organization(s). Each model object for organizationally bound system
objects has a default_scope definition that calls
Organization.apply_org_scope in addition to any previous default
scoping

that was applied before the organizations feature.

Open questions

What are other objects that should be organizationally bound?

puppet classes
hosts

How should user filters interact with organizational filtering?
When a user tries to create Domain 鈥淎BC鈥 in Organization 鈥淴鈥 and
Domain

鈥淎BC鈥 already exists in Organization 鈥淵鈥, the user will receive an
error

saying that 鈥淎BC鈥 already exists. However, the user cannot access
Domain
"ABC". How should the foreman deal with this situation?

indicate the that Domain already exists, but the user does not have
access
to the Domain in that organization?
alert administrators that a user tried to add Domain 鈥淎BC鈥 to an
different
Organization, and that perhaps the admin needs to associate the
existing

鈥淎BC鈥 Domain with more orgs?
other ideas?

Should there be a 鈥渄efault organization鈥 setting a user can select
that

sets
the default current organization for the user upon login?
Is there a better way to represent the config/settings.yaml changes?
How do organizations and user groups coexist, if at all?
More questions?

Thanks!


Greg

>
>
>>
>> Mmm鈥 had some more thoughts on this鈥
>>
>> I think permissions should all be done at the user group level, and
>> all resources that a user group can be given permissions, should be
>> able to belong to a resource group, which can be a
>> container/abstraction for compute resources, domains, subnets, puppet
>> classes, puppet masters, dns servers, puppet environments, etc. A
>> resource can belong to more than one Resource Group. Basically, the
>> thought is that we have one type of group for things that can be
>> granted permissions, and another for things they would be granted
>> permissions to. As far as nesting goes, I do think that since
>> resources should be able to belong to more than one group, a resource
>> group, can contain one or more other resource groups, to support
>> nesting.
>>
>> Perhaps this is to difficult to implement? Other thoughts? (I can
>> flesh out further, if people like the idea.)
>
>
> how do you model a location in this approach ?
> e.g., when deploying to location XX I want to see in the dropdowns only
> relevant options.

Could one not model a resource group per location? If not, then I
envision location being an atribute of a resource group, or individual
resource.

-Brian

路路路 On Mon, Jul 30, 2012 at 2:57 PM, Ohad Levy wrote: > On Mon, Jul 30, 2012 at 7:37 PM, Brian Gupta > wrote:

Ohad

-Brian

On Fri, Jul 27, 2012 at 11:16 AM, Sam Kottler >> sam@kottlerdevelopment.com wrote:

I think that there should be both an expansion of the user group system
and
how permissions work as well as organizations. User groups and
organizations
do collide in a semantic way, though, so maybe user groups need to be
renamed to 鈥減ermission groups鈥 (that name kind of sucks, too.
Suggestions?).
As the new names would suggest, permissions that can be applied to
groups of
users (whether inside an organization or not) would then be stored as
"permission group" object and then users inside or outside an
organization
can be placed into a permission group.

As for whether organizations are necessary, I definitely do think that
they
are a worthwhile addition to Foreman. When looking at a tool like
Katello,
it鈥檚 clear how powerful an organization system can become to support
multi-tenant installations. That being said, having a way that Foreman
can
run as a single org (without any of the organization-related
language/tools)
is important, too, and allows a smooth upgrade path for users who are
already happily using Foreman and don鈥檛 need the organization tools.

Brian, as someone who is already using Foreman with several different
customer accounts, I鈥檓 interested in how useful you see more global
permissions groups along with organizations vs. a single user group
model.
Thoughts?

On Thu, Jul 26, 2012 at 3:22 PM, Brian Gupta brian.gupta@brandorr.com >> > wrote:

My apologies for my short email. :slight_smile: I generally like the direction we
are going here, of allowing permissions to be set more broadly than at
the user level.

I just wonder, why create a new concept of ORG? Why not extend user
groups to provide this functionality, as I feel like much of what you
are describing is something that I would like to see at the user group
level.

For example, I want some pretty hefty puppet class permissions at
the user group level, allowing me to set which puppet classes users in
a
specific group can see in their list of available classes, and tag
nodes
with.
Classes would not be restricted to being used by group and some groups
could
be common to all user groups. There are many other enhancements that
could
be done to user group permissions in the same vein, that appear to
overlap with ORG functionality.

Perhaps I am missing something fundamental here?

Thanks,
Brian

On Tue, Jul 24, 2012 at 4:41 PM, Greg Blomquist blomquisg@gmail.com >> >> wrote:

Hi all,

I apologize for the long email.
tl;dr: a discussion on the 鈥渙rganizations鈥 feature for foreman; how
it鈥檚
used, what鈥檚 changed in foreman, open questions.

I鈥檝e been working on a feature for Foreman to add Organizations (aka,
Locations). The concept is to be able to group system objects
together
and
control access by users. You can see the code here:
https://github.com/theforeman/foreman/tree/orgs.

Background

With Organizations, an Admin can place system objects (Domains, Smart
Proxies, Compute Resources, etc鈥) into organizations and grant
users
access to organizations. Users (non-admins) can only see system
objects
in
their organizations.

Setup

An installer can enable organizations for a foreman instance by
setting
the
"single_org" or 鈥渕ulti_org鈥 foreman setting to true (in
settings.yaml).
Foreman provides two ways to operate with organizations:

single_org: In single_org mode, an Admin can grant a user access to
several
organizations, but a user must select a single organization from an
Organization Dropdown while working in foreman.
multi_org: In multi_org mode, an Admin grants a user access to
several
organizations, and the user can see all system objects in all granted
organizations.

The single_org and multi_org modes do not control how many
organizations
a
user can belong to. Users can always belong to multiple orgs
regardless
of
this setting (see Current Organization(s) below).

This allows foreman to provide flexibility in managing organizations.

Administration

Administrators are not bound to organizations, so admins can see all
system
objects regardless of organizational association. Users (non-admins)
are
assigned to organizations. Users can only see the system objects
that
are
associated to their organizations.

Organizationally bound objects

Compute Resources
Domains
Environments
Hostgroups
Installation Media
Smart Proxies

Organizations and Users

When organizations are enabled, Users (specifically, non-admins) can
belong
to multiple organizations. If organizations are enabled, then users
can
only see system objects in their organizations. If a user is created
and
not granted access to any organizations, the user will not see any
organizationally bound objects. If a system object is created and
not
associated to any organizations, then no user will see the object
(not
even
those users who have no organization association).

Current Organization(s)

In single_org mode, if a user is associated with only one
organization,
that
organization becomes the user鈥檚 鈥渃urrent organization鈥. The current
organization provides foreman with the correct context for scope when
retrieving organizationally bound objects. If the user is associated
with
multiple organizations, the user can select the current organization
from an
organization drop down added to the topbar context. For the user in
multiple organizations, the default current organization is
User.current.organizations.first.

When creating system objects in single_org mode, the user鈥檚 current
organization is automatically associated with the system object being
created. For instance, when a user creates Domain 鈥淎BC鈥 and has
Organization 鈥淴鈥 currently selected. Domain 鈥淎BC鈥 is automatically
associated with Organization 鈥淴鈥.

In multi_org mode, the current organizations is the list of
organizations
the user is associated with. The user will be able to see all the
object
associated to all of their organizations without having to select a
current
organization.

When creating system objects in multi_org mode, the user can select
to
add
the system object to any of their organizations via an
"Organizations"
tab
on the edit view.

Implementation

There are four key points of implementation:

enabling organizations
tracking current organization(s)
changes to views
updating the default_scope for model associations

Enabling organizations

The config/settings.yaml file contains two new settings: single_org
and
multi_org. These settings are mutually exclusive. They can both be
false,
but they can鈥檛 both be true. To enable organizations, the installer
should
set either single_org or multi_org to true.

Enabling organizations will enable the routes for organizations as
well
as
enable queries based on organization associations.

I haven鈥檛 tested enabling organizations, using organizations, then
disabling
organizations.

Tracking current organization(s)

In single_org mode, the current organization is tracked similar to
the
current user; in a thread local variable. When a user (non-admin)
logs
in,
the first organization (User.current.organizations.first) is selected
as
the
current organization. When the user changes the current organization
using
the organization drop down, the thread local variable is updated.

In multi_org mode, the current organizations is always
User.current.organizations.

Changes to views

An organization tab has been added to the form for system objects
that
are
organizationally bound. Administrators use the multi-checkbox on the
organizations tab to associated system objects to organizations.

Updating default_scope for model associations

In rails 3.0, the default_scope unnamed scope does not allow lambdas
or
blocks. The default_scope is evaluated immediately upon definition
instead
of being evaluated at the time of SQL composition. (This has been
fixed
in
rails 3.1 and moving forward:
https://rails.lighthouseapp.com/projects/8994/tickets/1812-default).
In
order to restrict queries for organizationally bound system objects,
the
processing of default_scope needed to change to allow a lambda to
grab
the
currently selected organization(s) based on the current user. This
change
is implemented as an initializer monkey patch of
ActiveRecord::Base.current_scoped_methods.

The side effect of this monkey patch is that it鈥檚 not possible to
stack
default_scopes that use lambdas and non-lambdas. For default_scopes
that
use lambdas, all the default scoping should be contained in the
lambda.

With lambdas available for default_scope, the model object
associations
are
fairly straightforward. The class method
Organization.apply_org_scope
will
scope the caller on its relationship with organizations through the
current
organization(s). Each model object for organizationally bound system
objects has a default_scope definition that calls
Organization.apply_org_scope in addition to any previous default
scoping
that was applied before the organizations feature.

Open questions

What are other objects that should be organizationally bound?

puppet classes
hosts

How should user filters interact with organizational filtering?
When a user tries to create Domain 鈥淎BC鈥 in Organization 鈥淴鈥 and
Domain
"ABC" already exists in Organization 鈥淵鈥, the user will receive an
error
saying that 鈥淎BC鈥 already exists. However, the user cannot access
Domain
"ABC". How should the foreman deal with this situation?

indicate the that Domain already exists, but the user does not have
access
to the Domain in that organization?
alert administrators that a user tried to add Domain 鈥淎BC鈥 to an
different
Organization, and that perhaps the admin needs to associate the
existing
"ABC" Domain with more orgs?
other ideas?

Should there be a 鈥渄efault organization鈥 setting a user can select
that
sets
the default current organization for the user upon login?
Is there a better way to represent the config/settings.yaml changes?
How do organizations and user groups coexist, if at all?
More questions?

Thanks!


Greg

> >
> >
> >>
> >> Mmm鈥 had some more thoughts on this鈥
> >>
> >> I think permissions should all be done at the user group level, and
> >> all resources that a user group can be given permissions, should be
> >> able to belong to a resource group, which can be a
> >> container/abstraction for compute resources, domains, subnets, puppet
> >> classes, puppet masters, dns servers, puppet environments, etc. A
> >> resource can belong to more than one Resource Group. Basically, the
> >> thought is that we have one type of group for things that can be
> >> granted permissions, and another for things they would be granted
> >> permissions to. As far as nesting goes, I do think that since
> >> resources should be able to belong to more than one group, a resource
> >> group, can contain one or more other resource groups, to support
> >> nesting.
> >>
> >> Perhaps this is to difficult to implement? Other thoughts? (I can
> >> flesh out further, if people like the idea.)
> >
> >
> > how do you model a location in this approach ?
> > e.g., when deploying to location XX I want to see in the dropdowns only
> > relevant options.
>
> Could one not model a resource group per location?

so a usergroup == resource group == orgs?

Ohad

路路路 On Mon, Jul 30, 2012 at 10:09 PM, Brian Gupta wrote: > On Mon, Jul 30, 2012 at 2:57 PM, Ohad Levy wrote: > > On Mon, Jul 30, 2012 at 7:37 PM, Brian Gupta > > wrote:

If not, then I
envision location being an atribute of a resource group, or individual
resource.

-Brian

Ohad

-Brian

On Fri, Jul 27, 2012 at 11:16 AM, Sam Kottler > >> sam@kottlerdevelopment.com wrote:

I think that there should be both an expansion of the user group
system

and
how permissions work as well as organizations. User groups and
organizations
do collide in a semantic way, though, so maybe user groups need to be
renamed to 鈥減ermission groups鈥 (that name kind of sucks, too.
Suggestions?).
As the new names would suggest, permissions that can be applied to
groups of
users (whether inside an organization or not) would then be stored as
"permission group" object and then users inside or outside an
organization
can be placed into a permission group.

As for whether organizations are necessary, I definitely do think that
they
are a worthwhile addition to Foreman. When looking at a tool like
Katello,
it鈥檚 clear how powerful an organization system can become to support
multi-tenant installations. That being said, having a way that Foreman
can
run as a single org (without any of the organization-related
language/tools)
is important, too, and allows a smooth upgrade path for users who are
already happily using Foreman and don鈥檛 need the organization tools.

Brian, as someone who is already using Foreman with several different
customer accounts, I鈥檓 interested in how useful you see more global
permissions groups along with organizations vs. a single user group
model.
Thoughts?

On Thu, Jul 26, 2012 at 3:22 PM, Brian Gupta < > brian.gupta@brandorr.com> > >> > wrote:

My apologies for my short email. :slight_smile: I generally like the direction we
are going here, of allowing permissions to be set more broadly than
at

the user level.

I just wonder, why create a new concept of ORG? Why not extend user
groups to provide this functionality, as I feel like much of what you
are describing is something that I would like to see at the user
group

level.

For example, I want some pretty hefty puppet class permissions at
the user group level, allowing me to set which puppet classes users
in

a
specific group can see in their list of available classes, and tag
nodes
with.
Classes would not be restricted to being used by group and some
groups

could
be common to all user groups. There are many other enhancements that
could
be done to user group permissions in the same vein, that appear to
overlap with ORG functionality.

Perhaps I am missing something fundamental here?

Thanks,
Brian

On Tue, Jul 24, 2012 at 4:41 PM, Greg Blomquist <blomquisg@gmail.com > > > >> >> wrote:

Hi all,

I apologize for the long email.
tl;dr: a discussion on the 鈥渙rganizations鈥 feature for foreman; how
it鈥檚
used, what鈥檚 changed in foreman, open questions.

I鈥檝e been working on a feature for Foreman to add Organizations
(aka,

Locations). The concept is to be able to group system objects
together
and
control access by users. You can see the code here:
https://github.com/theforeman/foreman/tree/orgs.

Background

With Organizations, an Admin can place system objects (Domains,
Smart

Proxies, Compute Resources, etc鈥) into organizations and grant
users
access to organizations. Users (non-admins) can only see system
objects
in
their organizations.

Setup

An installer can enable organizations for a foreman instance by
setting
the
"single_org" or 鈥渕ulti_org鈥 foreman setting to true (in
settings.yaml).
Foreman provides two ways to operate with organizations:

single_org: In single_org mode, an Admin can grant a user access to
several
organizations, but a user must select a single organization from an
Organization Dropdown while working in foreman.
multi_org: In multi_org mode, an Admin grants a user access to
several
organizations, and the user can see all system objects in all
granted

organizations.

The single_org and multi_org modes do not control how many
organizations
a
user can belong to. Users can always belong to multiple orgs
regardless
of
this setting (see Current Organization(s) below).

This allows foreman to provide flexibility in managing
organizations.

Administration

Administrators are not bound to organizations, so admins can see
all

system
objects regardless of organizational association. Users
(non-admins)

are
assigned to organizations. Users can only see the system objects
that
are
associated to their organizations.

Organizationally bound objects

Compute Resources
Domains
Environments
Hostgroups
Installation Media
Smart Proxies

Organizations and Users

When organizations are enabled, Users (specifically, non-admins)
can

belong
to multiple organizations. If organizations are enabled, then
users

can
only see system objects in their organizations. If a user is
created

and
not granted access to any organizations, the user will not see any
organizationally bound objects. If a system object is created and
not
associated to any organizations, then no user will see the object
(not
even
those users who have no organization association).

Current Organization(s)

In single_org mode, if a user is associated with only one
organization,
that
organization becomes the user鈥檚 鈥渃urrent organization鈥. The
current

organization provides foreman with the correct context for scope
when

retrieving organizationally bound objects. If the user is
associated

with
multiple organizations, the user can select the current
organization

from an
organization drop down added to the topbar context. For the user
in

multiple organizations, the default current organization is
User.current.organizations.first.

When creating system objects in single_org mode, the user鈥檚 current
organization is automatically associated with the system object
being

created. For instance, when a user creates Domain 鈥淎BC鈥 and has
Organization 鈥淴鈥 currently selected. Domain 鈥淎BC鈥 is automatically
associated with Organization 鈥淴鈥.

In multi_org mode, the current organizations is the list of
organizations
the user is associated with. The user will be able to see all the
object
associated to all of their organizations without having to select a
current
organization.

When creating system objects in multi_org mode, the user can select
to
add
the system object to any of their organizations via an
"Organizations"
tab
on the edit view.

Implementation

There are four key points of implementation:

enabling organizations
tracking current organization(s)
changes to views
updating the default_scope for model associations

Enabling organizations

The config/settings.yaml file contains two new settings:
single_org

and
multi_org. These settings are mutually exclusive. They can both
be

false,
but they can鈥檛 both be true. To enable organizations, the
installer

should
set either single_org or multi_org to true.

Enabling organizations will enable the routes for organizations as
well
as
enable queries based on organization associations.

I haven鈥檛 tested enabling organizations, using organizations, then
disabling
organizations.

Tracking current organization(s)

In single_org mode, the current organization is tracked similar to
the
current user; in a thread local variable. When a user (non-admin)
logs
in,
the first organization (User.current.organizations.first) is
selected

as
the
current organization. When the user changes the current
organization

using
the organization drop down, the thread local variable is updated.

In multi_org mode, the current organizations is always
User.current.organizations.

Changes to views

An organization tab has been added to the form for system objects
that
are
organizationally bound. Administrators use the multi-checkbox on
the

organizations tab to associated system objects to organizations.

Updating default_scope for model associations

In rails 3.0, the default_scope unnamed scope does not allow
lambdas

or
blocks. The default_scope is evaluated immediately upon definition
instead
of being evaluated at the time of SQL composition. (This has been
fixed
in
rails 3.1 and moving forward:
https://rails.lighthouseapp.com/projects/8994/tickets/1812-default
).

In
order to restrict queries for organizationally bound system
objects,

the
processing of default_scope needed to change to allow a lambda to
grab
the
currently selected organization(s) based on the current user. This
change
is implemented as an initializer monkey patch of
ActiveRecord::Base.current_scoped_methods.

The side effect of this monkey patch is that it鈥檚 not possible to
stack
default_scopes that use lambdas and non-lambdas. For
default_scopes

that
use lambdas, all the default scoping should be contained in the
lambda.

With lambdas available for default_scope, the model object
associations
are
fairly straightforward. The class method
Organization.apply_org_scope
will
scope the caller on its relationship with organizations through the
current
organization(s). Each model object for organizationally bound
system

objects has a default_scope definition that calls
Organization.apply_org_scope in addition to any previous default
scoping
that was applied before the organizations feature.

Open questions

What are other objects that should be organizationally bound?

puppet classes
hosts

How should user filters interact with organizational filtering?
When a user tries to create Domain 鈥淎BC鈥 in Organization 鈥淴鈥 and
Domain
"ABC" already exists in Organization 鈥淵鈥, the user will receive an
error
saying that 鈥淎BC鈥 already exists. However, the user cannot access
Domain
"ABC". How should the foreman deal with this situation?

indicate the that Domain already exists, but the user does not have
access
to the Domain in that organization?
alert administrators that a user tried to add Domain 鈥淎BC鈥 to an
different
Organization, and that perhaps the admin needs to associate the
existing
"ABC" Domain with more orgs?
other ideas?

Should there be a 鈥渄efault organization鈥 setting a user can select
that
sets
the default current organization for the user upon login?
Is there a better way to represent the config/settings.yaml
changes?

How do organizations and user groups coexist, if at all?
More questions?

Thanks!


Greg

That's not how I interpret it.

Here's how I read Brian G's comment:
User groups contain user permissions.
Resource groups (aka Orgs) contain resources (compute resources, hosts,
domains, etc).

Users are associated to resources through resource groups.
Users are granted permissions via user groups.

In this way they are distinct and separate.

The only problem I see arises with the scenario: UserX should have
permission to create Domains in Resource Group 1, but only have permission
to view Domains in Resource Group 2.
To support this concept, permissions need to be crossed with resource
groups.

The only question is, should foreman support this scenario? On the
surface, it seems like it should.

路路路 On Monday, July 30, 2012 3:25:11 PM UTC-4, ohadlevy wrote: > > > > On Mon, Jul 30, 2012 at 10:09 PM, Brian Gupta wrote: > >> On Mon, Jul 30, 2012 at 2:57 PM, Ohad Levy wrote: >> > >> > >> > On Mon, Jul 30, 2012 at 7:37 PM, Brian Gupta >> > wrote: >> >> >> >> Mmm.. had some more thoughts on this... >> >> >> >> *I* think permissions should all be done at the user group level, and >> >> all resources that a user group can be given permissions, should be >> >> able to belong to a resource group, which can be a >> >> container/abstraction for compute resources, domains, subnets, puppet >> >> classes, puppet masters, dns servers, puppet environments, etc. A >> >> resource can belong to more than one Resource Group. Basically, the >> >> thought is that we have one type of group for things that can be >> >> granted permissions, and another for things they would be granted >> >> permissions to. As far as nesting goes, I do think that since >> >> resources should be able to belong to more than one group, a resource >> >> group, can contain one or more other resource groups, to support >> >> nesting. >> >> >> >> Perhaps this is to difficult to implement? Other thoughts? (I can >> >> flesh out further, if people like the idea.) >> > >> > >> > how do you model a location in this approach ? >> > e.g., when deploying to location XX I want to see in the dropdowns only >> > relevant options. >> >> Could one not model a resource group per location? > > > so a usergroup == resource group == orgs? >

Greg

>
>
>>
>>
>>
>>
>>> >
>>> >
>>> >>
>>> >> Mmm鈥 had some more thoughts on this鈥
>>> >>
>>> >> I think permissions should all be done at the user group level, and
>>> >> all resources that a user group can be given permissions, should be
>>> >> able to belong to a resource group, which can be a
>>> >> container/abstraction for compute resources, domains, subnets, puppet
>>> >> classes, puppet masters, dns servers, puppet environments, etc. A
>>> >> resource can belong to more than one Resource Group. Basically, the
>>> >> thought is that we have one type of group for things that can be
>>> >> granted permissions, and another for things they would be granted
>>> >> permissions to. As far as nesting goes, I do think that since
>>> >> resources should be able to belong to more than one group, a resource
>>> >> group, can contain one or more other resource groups, to support
>>> >> nesting.
>>> >>
>>> >> Perhaps this is to difficult to implement? Other thoughts? (I can
>>> >> flesh out further, if people like the idea.)
>>> >
>>> >
>>> > how do you model a location in this approach ?
>>> > e.g., when deploying to location XX I want to see in the dropdowns only
>>> > relevant options.
>>>
>>> Could one not model a resource group per location?
>>>
>>
>> so a usergroup == resource group == orgs?
>>
>
> That's not how I interpret it.
>
> Here's how I read Brian G's comment:
> User groups contain user permissions.
> Resource groups (aka Orgs) contain resources (compute resources, hosts,
> domains, etc).
>
> Users are associated to resources through resource groups.
> Users are granted permissions via user groups.
>
> In this way they are distinct and separate.
>
> The only problem I see arises with the scenario: UserX should have
> permission to create Domains in Resource Group 1, but only have permission
> to view Domains in Resource Group 2.
> To support this concept, permissions need to be crossed with resource
> groups.
>
> The only question is, should foreman support this scenario? On the
> surface, it seems like it should.
>

I tend to agree, I started to summaries my thoughts here(wip):

http://theforeman.org/projects/foreman/wiki/Organization-Groups-Design

thanks!
Ohad

路路路 On Wed, Aug 1, 2012 at 2:59 AM, Greg Blomquist wrote: > On Monday, July 30, 2012 3:25:11 PM UTC-4, ohadlevy wrote: >> On Mon, Jul 30, 2012 at 10:09 PM, Brian Gupta wrote: >>> On Mon, Jul 30, 2012 at 2:57 PM, Ohad Levy wrote: >>> > On Mon, Jul 30, 2012 at 7:37 PM, Brian Gupta >>> > wrote:

Greg

> I tend to agree, I started to summaries my thoughts here(wip):
>

>
http://theforeman.org/projects/foreman/wiki/Organization-Groups-Design
>
> thanks!
> Ohad
>

Following my discussion with Ohad on IRC, I post my proposal here:

I don't particularly like the name "Organization", it makes me think of
companies rather than a physical/logical hierarchy/classification of stuff.
Organization Unit is too close to Business Unit too, IMHO.

Looking at synonyms of synonyms I suggest: grouping, structure,
arrangement, layout, component, bunch, element, part, bundle, collection,
gathering, ensemble, entity,
categorization/classification/combination/composition/division, fragment
Using composed words may help making things clearer.

Here is how I see things, focusing on permission management:

In a nutshell:
Users can be nested into groups, which nest too; similar thing with Orgs;
you then match the two sets with a given {Role;Filter} couple.

The long version, with grammar equivalent:
Users COULD be grouped inside Groups, that COULD themselves be grouped into
new Groups (preventing recursion). We could call all of them Persons
(either physical (Users), or moral (Groups)).

Person: group|user
group: Person*

Proxies, Computes, Media, Domains, Hostgroups, Environments, Subnets,
Hosts, Users, etc. are Items. Some Items COULD be grouped inside Entities.
Entities are Items too, hence can be contained in other Entities too
(preventing recursion).

Note that persons are entities too, you can manage them too through some

permissions.
Entity: Entities | Person | proxy | compute_resource | media | domain |
hostgroup | environment | subnet | host
Entities: Entity*

We now have two ensembles of things we would like to interconnect with
right restrictions. Permissions (like edit_host, create_compute, etc.) are
grouped granted in Roles.

Role: permission*
Filter: Entity | bookmarks | search_string

The solution I see would GRANT some rights TO a Person ONTO an Item, using
a particular Role-Filter couple.

GRANT Role TO Person ONTO Filter+

But the logic coded inside Filters may be interesting to reuse, so it may
also be used INSIDE Filters or Roles.

FilterExpression: Filter | FilterExpression (AND | OR | XOR)
FilterExpression | NOT FilterExpression
FilteredPermission: permission [ONTO FilterExpression]
Role: FilteredPermission*
GRANT Role TO Person ONTO FilterExpression

Notes:

This could/should be simplified, eventually merely to fit properly inside a
simple web form.
"ONTO FilterExpression" specifies the matching objects that are accessible
with the granted permissions.
I was thinking to add a "IF FilterExpression" to FilteredPermission, that
evaluates to true if the current user has somehow access to the resources
FilterExpression resolves to.

We already have group nesting support.
My Entities really are Organizations, but I don't think this name really
suits (entities may not be the best term either).

From Ohad Levy <ohadlevy@gmail.com>:

> org should also have default values, that we could remove the non app
> related settings from the hostgroups

(I am merely reporting, I didn't understand what he meant :-P)

From the wiki page:

> should hosts belong to more than one org?

I am sure it would be very beneficial.
Just like you may need to manage them both by BusinessUnit, OS, type of
instance, and location,
you may want to allow different permissions to the same host to different
persons, each having one or more rights (granted by roles, onto orgs).

Thinking of whitelist and blacklist filters (the broken "plus all" and
"must be" select beside the filters):

It is similar to "granting" and "denying" filters.
If used as "granted actions MINUS denied actions", with granted actions
being OR-ed together from the whitelist and denied actions being OR-ed
together too from the blacklist,
the denied actions will prevail and clobber everything else, being counter
productive and misleading.
If used a la Apache HTTPD, the previous would be similar to using "order
allow, deny" (granting no rights by default, adding the mentioned rights,
then removing the other mentioned rights).
If we use a "order deny, allow" approach, we would first grant all rights,
then restrict rights, then extend rights.
The fact that all rights are granted by default seems completely wrong and
dangerous, right restriction would be complex too.

This is why I proposed FilterExpression above, with AND/OR/XOR/NOT
capabilities.
As we plan on using search strings in filters, this would almost come for
free.

Cheers,

路路路 2012/8/1 Ohad Levy -- Olivier Favre www.yakaz.com

Olivier, you blew my mind!
I like this grammar. This is a good way to represent the problem.

More comments inline鈥

>
> 2012/8/1 Ohad Levy
>
>> I tend to agree, I started to summaries my thoughts here(wip):
>>
>
>>
> Organization-Groups-Design - Foreman
>>
>> thanks!
>> Ohad
>>
>
> Following my discussion with Ohad on IRC, I post my proposal here:
>
> I don't particularly like the name "Organization", it makes me think of
> companies rather than a physical/logical hierarchy/classification of stuff.
> Organization Unit is too close to Business Unit too, IMHO.
>
> Looking at synonyms of synonyms I suggest: grouping, structure,
> arrangement, layout, component, bunch, element, part, bundle, collection,
> gathering, ensemble, entity,
> categorization/classification/combination/composition/division, fragment
> Using composed words may help making things clearer.
>
>
> Here is how I see things, focusing on permission management:
>
> In a nutshell:
> Users can be nested into groups, which nest too; similar thing with Orgs;
> you then match the two sets with a given {Role;Filter} couple.
>
> The long version, with grammar equivalent:
> Users COULD be grouped inside Groups, that COULD themselves be grouped
> into new Groups (preventing recursion). We could call all of them Persons
> (either physical (Users), or moral (Groups)).
>
> Person: group|user
> group: Person*
>
> Proxies, Computes, Media, Domains, Hostgroups, Environments, Subnets,
> Hosts, Users, etc. are Items. Some Items COULD be grouped inside Entities.
> Entities are Items too, hence can be contained in other Entities too
> (preventing recursion).
>
> # Note that persons are entities too, you can manage them too through some
> permissions.
> Entity: Entities | Person | proxy | compute_resource | media | domain |
> hostgroup | environment | subnet | host
>
>
Not sure I understand why a Person is also an Entity鈥 to follow one
grammar expansion:
GRANT Role TO Person ONTO Filter
=> GRANT Role TO Person ONTO Entity
===> GRANT Role TO Person ONTO Person

> Entities: Entity*
>
> We now have two ensembles of things we would like to interconnect with
> right restrictions. Permissions (like edit_host, create_compute, etc.) are
> grouped granted in Roles.
>
> Role: permission*
> Filter: Entity | bookmarks | search_string
>
> The solution I see would GRANT some rights TO a Person ONTO an Item, using
> a particular Role-Filter couple.
>
> GRANT Role TO Person ONTO Filter+
>
>
> But the logic coded inside Filters may be interesting to reuse, so it may
> also be used INSIDE Filters or Roles.
>
> FilterExpression: Filter | FilterExpression (AND | OR | XOR)
> FilterExpression | NOT FilterExpression
> FilteredPermission: permission [ONTO FilterExpression]
> Role: FilteredPermission*
> GRANT Role TO Person ONTO FilterExpression
>
> Notes:
>
> This could/should be simplified, eventually merely to fit properly inside
> a simple web form.
> "ONTO FilterExpression" specifies the matching objects that are accessible
> with the granted permissions.
> I was thinking to add a "IF FilterExpression" to FilteredPermission, that
> evaluates to true if the current user has somehow access to the resources
> FilterExpression resolves to.
>
>
> We already have group nesting support.
> My Entities really are Organizations, but I don't think this name really
> suits (entities may not be the best term either).
>

Totally agree with the domain model naming. Andreas mentioned "Zone". I
might like that better.

I think part of the problem is that the concept of organizations
potentially has different meaning to different people. It's semantically
polymorphic.

路路路 On Wednesday, August 1, 2012 12:42:54 PM UTC-4, Olivier Favre wrote:

From Ohad Levy:

org should also have default values, that we could remove the non app
related settings from the hostgroups

(I am merely reporting, I didn鈥檛 understand what he meant :-P)

From the wiki page:

should hosts belong to more than one org?

I am sure it would be very beneficial.
Just like you may need to manage them both by BusinessUnit, OS, type of
instance, and location,
you may want to allow different permissions to the same host to different
persons, each having one or more rights (granted by roles, onto orgs).

Thinking of whitelist and blacklist filters (the broken 鈥減lus all鈥 and
"must be" select beside the filters):

It is similar to 鈥済ranting鈥 and 鈥渄enying鈥 filters.
If used as 鈥済ranted actions MINUS denied actions鈥, with granted actions
being OR-ed together from the whitelist and denied actions being OR-ed
together too from the blacklist,
the denied actions will prevail and clobber everything else, being counter
productive and misleading.
If used a la Apache HTTPD, the previous would be similar to using 鈥渙rder
allow, deny鈥 (granting no rights by default, adding the mentioned rights,
then removing the other mentioned rights).
If we use a 鈥渙rder deny, allow鈥 approach, we would first grant all rights,
then restrict rights, then extend rights.
The fact that all rights are granted by default seems completely wrong and
dangerous, right restriction would be complex too.

This is why I proposed FilterExpression above, with AND/OR/XOR/NOT
capabilities.
As we plan on using search strings in filters, this would almost come for
free.

Cheers,

Olivier Favre
www.yakaz.com

What about "Data Center" or "Zone"?
If I have to explain why these are good names they probably aren't good
names. So I leave it uncommented :slight_smile:

HTH

Regards,
Andreas

路路路 Am 01.08.2012 18:42, schrieb Olivier Favre: > I don't particularly like the name "Organization", it makes me think of > companies rather than a physical/logical hierarchy/classification of > stuff. Organization Unit is too close to Business Unit too, IMHO. > > Looking at synonyms of synonyms I suggest: grouping, structure, > arrangement, layout, component, bunch, element, part, bundle, > collection, gathering, ensemble, entity, > categorization/classification/combination/composition/division, fragment > Using composed words may help making things clearer. > -- Solvention Ltd. & Co. KG St.-Sebastianus-Str. 5 51147 K茂驴陆ln

Tel: +49 2203 989967-0
Fax: +49 2203 989967-9

http://www.solvention.de
mailto:info@solvention.de

>
>> I tend to agree, I started to summaries my thoughts here(wip):
>>
>
>>
> Organization-Groups-Design - Foreman
>>
>> thanks!
>> Ohad
>>
>
> Following my discussion with Ohad on IRC, I post my proposal here:
>
> I don't particularly like the name "Organization", it makes me think of
> companies rather than a physical/logical hierarchy/classification of stuff.
> Organization Unit is too close to Business Unit too, IMHO.
>
> Looking at synonyms of synonyms I suggest: grouping, structure,
> arrangement, layout, component, bunch, element, part, bundle, collection,
> gathering, ensemble, entity,
> categorization/classification/combination/composition/division, fragment
> Using composed words may help making things clearer.
>
>
> Here is how I see things, focusing on permission management:
>
> In a nutshell:
> Users can be nested into groups, which nest too; similar thing with Orgs;
> you then match the two sets with a given {Role;Filter} couple.
>
> The long version, with grammar equivalent:
> Users COULD be grouped inside Groups, that COULD themselves be grouped
> into new Groups (preventing recursion). We could call all of them Persons
> (either physical (Users), or moral (Groups)).
>
> Person: group|user
> group: Person*
>
> Proxies, Computes, Media, Domains, Hostgroups, Environments, Subnets,
> Hosts, Users, etc. are Items. Some Items COULD be grouped inside Entities.
> Entities are Items too, hence can be contained in other Entities too
> (preventing recursion).
>
> # Note that persons are entities too, you can manage them too through some
> permissions.
> Entity: Entities | Person | proxy | compute_resource | media | domain |
> hostgroup | environment | subnet | host
> Entities: Entity*
>
> We now have two ensembles of things we would like to interconnect with
> right restrictions. Permissions (like edit_host, create_compute, etc.) are
> grouped granted in Roles.
>
> Role: permission*
> Filter: Entity | bookmarks | search_string
>
> The solution I see would GRANT some rights TO a Person ONTO an Item, using
> a particular Role-Filter couple.
>
> GRANT Role TO Person ONTO Filter+
>
>
> But the logic coded inside Filters may be interesting to reuse, so it may
> also be used INSIDE Filters or Roles.
>
> FilterExpression: Filter | FilterExpression (AND | OR | XOR)
> FilterExpression | NOT FilterExpression
> FilteredPermission: permission [ONTO FilterExpression]
> Role: FilteredPermission*
> GRANT Role TO Person ONTO FilterExpression
>
> Notes:
>
> This could/should be simplified, eventually merely to fit properly inside
> a simple web form.
> "ONTO FilterExpression" specifies the matching objects that are accessible
> with the granted permissions.
> I was thinking to add a "IF FilterExpression" to FilteredPermission, that
> evaluates to true if the current user has somehow access to the resources
> FilterExpression resolves to.
>
>
> We already have group nesting support.
> My Entities really are Organizations, but I don't think this name really
> suits (entities may not be the best term either).
>
> From Ohad Levy <ohadlevy@gmail.com>:
>
>> org should also have default values, that we could remove the non app
>> related settings from the hostgroups
>
> (I am merely reporting, I didn't understand what he meant :-P)
>

Hostgroups ideally should contain attributes that describe the App that you
want to deploy.

however, they are currently over-loaded with additional attributes such as
default puppet master, default domain network etc.
I think all of those attributes needs to move into our new Orgs, and leave
only app related info within the hostgroup.

Ohad

路路路 On Wed, Aug 1, 2012 at 7:42 PM, Olivier Favre wrote: > 2012/8/1 Ohad Levy

From the wiki page:

should hosts belong to more than one org?

I am sure it would be very beneficial.
Just like you may need to manage them both by BusinessUnit, OS, type of
instance, and location,
you may want to allow different permissions to the same host to different
persons, each having one or more rights (granted by roles, onto orgs).

Thinking of whitelist and blacklist filters (the broken 鈥減lus all鈥 and
"must be" select beside the filters):

It is similar to 鈥済ranting鈥 and 鈥渄enying鈥 filters.
If used as 鈥済ranted actions MINUS denied actions鈥, with granted actions
being OR-ed together from the whitelist and denied actions being OR-ed
together too from the blacklist,
the denied actions will prevail and clobber everything else, being counter
productive and misleading.
If used a la Apache HTTPD, the previous would be similar to using 鈥渙rder
allow, deny鈥 (granting no rights by default, adding the mentioned rights,
then removing the other mentioned rights).
If we use a 鈥渙rder deny, allow鈥 approach, we would first grant all rights,
then restrict rights, then extend rights.
The fact that all rights are granted by default seems completely wrong and
dangerous, right restriction would be complex too.

This is why I proposed FilterExpression above, with AND/OR/XOR/NOT
capabilities.
As we plan on using search strings in filters, this would almost come for
free.

Cheers,

Olivier Favre
www.yakaz.com

> Not sure I understand why a Person is also an Entity鈥 to follow one
> grammar expansion:
> GRANT Role TO Person ONTO Filter
> => GRANT Role TO Person ONTO Entity
> ===> GRANT Role TO Person ONTO Person
>
Indeed. That may be thought of as a side-effect,
but it can actually be used to grant a local admin some rights (namely
view, create, destroy, but not edit) on its local fellows.
Anyway, we can either remove Person and use group instead, or merely drop
it, but Ohad cited it in the wiki page.
Besides, the fact that the grammar/site permits it won't have any drawbacks
if it isn't used.

> Totally agree with the domain model naming. Andreas mentioned "Zone". I
> might like that better.
>
> I think part of the problem is that the concept of organizations
> potentially has different meaning to different people. It's semantically
> polymorphic.
>

> What about "Data Center" or "Zone"?

Data Center is like Location, it's too specific, the concept is broader, it
can be either a data center, a business unit, a kind of machines, machines
used for a particular app, etc.
We need a more abstract term, but not necessarily a pure abstract one.
Zone is a bit abstract, it doesn't have the same inconvenient as
Organization, namely an erroneous signification you will lock yourself into
without seeing other semantics.
I'd suggest Area, to follow the same idea thread.

So here are the terms I favor: Entity, Area, Zone.

Yours,

路路路 2012/8/1 Greg Blomquist 2012/8/1 Greg Blomquist 2012/8/1 Andreas Rogge -- Olivier Favre www.yakaz.com

Ldap uses OU for organizational unit.

Thats my .02

Thanks,

Corey Osman
corey@logicminds.biz

Green IT and Data Center Automation Specialist

路路路 On Aug 1, 2012, at 10:16 AM, Andreas Rogge wrote:

Am 01.08.2012 18:42, schrieb Olivier Favre:

I don鈥檛 particularly like the name 鈥淥rganization鈥, it makes me think of
companies rather than a physical/logical hierarchy/classification of
stuff. Organization Unit is too close to Business Unit too, IMHO.

Looking at synonyms of synonyms I suggest: grouping, structure,
arrangement, layout, component, bunch, element, part, bundle,
collection, gathering, ensemble, entity,
categorization/classification/combination/composition/division, fragment
Using composed words may help making things clearer.

What about 鈥淒ata Center鈥 or 鈥淶one鈥?
If I have to explain why these are good names they probably aren鈥檛 good names. So I leave it uncommented :slight_smile:

HTH

Regards,
Andreas

Solvention Ltd. & Co. KG
St.-Sebastianus-Str. 5
51147 K枚ln

Tel: +49 2203 989967-0
Fax: +49 2203 989967-9

http://www.solvention.de
mailto:info@solvention.de

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 2012/8/1 Greg Blomquist <blomquisg@gmail.com <mailto:blomquisg@gmail.com>>
>
> Not sure I understand why a Person is also an Entity鈥 to follow one
grammar expansion:
> GRANT Role TO Person ONTO Filter
> => GRANT Role TO Person ONTO Entity
> ===> GRANT Role TO Person ONTO Person
>
> Indeed. That may be thought of as a side-effect,
> but it can actually be used to grant a local admin some rights (namely
view, create, destroy, but not edit) on its local fellows.
> Anyway, we can either remove Person and use group instead, or merely
drop it, but Ohad cited it in the wiki page.
> Besides, the fact that the grammar/site permits it won't have any
drawbacks if it isn't used.
>
> 2012/8/1 Greg Blomquist <blomquisg@gmail.com <mailto:blomquisg@gmail.com>>
>
> Totally agree with the domain model naming. Andreas mentioned "Zone".
I might like that better.
>
> I think part of the problem is that the concept of organizations
potentially has different meaning to different people. It's semantically
polymorphic.
>
> 2012/8/1 Andreas Rogge <a.rogge@solvention.de
<mailto:a.rogge@solvention.de>>
>
> What about "Data Center" or "Zone"?
>
> Data Center is like Location, it's too specific, the concept is
broader, it can be either a data center, a business unit, a kind of
machines, machines used for a particular app, etc.
> We need a more abstract term, but not necessarily a pure abstract one.
> Zone is a bit abstract, it doesn't have the same inconvenient as
Organization, namely an erroneous signification you will lock yourself
into without seeing other semantics.
> I'd suggest Area, to follow the same idea thread.
>
> So here are the terms I favor: Entity, Area, Zone.
>
>
> Yours,
> 鈥
> Olivier Favre
> www.yakaz.com <http://www.yakaz.com/>
I will continue to advocate for "resource groups". Entity, area, nor
zone are obvious enough names to immediately recognize their purpose.
Additionally, they cater specifically to people who have multiple data
centers that are geographically distributed. Many users don't have
several data-centers, but have multiple tenants and want to use
organizations (whatever their ultimate name may be) to separate
customers from one another. Resource groups immediately make sense, at
least from my perspective, and are generic enough to make sense in the
context of most users who want this capability.

  • -S
路路路 On 08/02/2012 09:38 AM, Olivier Favre wrote: