Katello and Foreman permissions systems

Hi all

During work on Foreman authorization code we have good chance to modify it for
Katello needs. I'd like to invite anyone interested in authorization system of
Foreman and Katello to a short session on Tue 26th at 9:30 EST. It shouldn't
take longer that 30 minutes. I'd like to investigate whether current Foreman
model is good enough for Katello (according to last meeting in Brno, it should
be) and find out what other features we may add.

I'll start with description of current Foreman model and planned (but not
final) changes. Then the discussion should follow.

I'll send a hangout link before start via email and irc #theforeman-dev

··· -- Marek

Good Job Marek! This looks much better than the previous permission
system and should fit katello's use cases pretty well.

I did have a couple of comments from a katello perspective:

  • As I mentioned in the demo, I think it's important for users to be
    able to physically select specific resources as well as use the scoped
    search syntax. Not only is it easier for beginner users, but it would
    work across renames without the user having to lookup and type in Ids.
    This could be backed by scoped search for sure.

  • Katello has a pre-built read-only role created so that admins can give
    an auditing type user read-access to everything on the satellite. Given
    the number of permissions that would need to be granted within foreman,
    I think this could be useful here too. Within katello we were tracking
    whether a particular permission was a read permission or not, and
    generated a role with all the 'read' permissions. None of this needs
    to be done now, but some discussion/thought on how we could do it would
    be useful. Mainly we need someway to know which permissions are
    read-only or not.

  • This assumes that katello will need to add scoped search to all models
    that need permissions.

  • We need to make sure that the plugin registration continues to work
    (and allows new resource types to be added in addition to permissions).

  • To highlight a difference between katello and foreman, accessible orgs
    are assigned apart from roles (In katello accessible orgs were derived
    from a users roles). I think this is okay, just wanted to highlight the
    difference.

  • One main use case with organizations is:

    • I should be able to create a user and assign him to Organization A
      and give him some role.
    • That user should be able to create other users and create & assign
      roles that only have access to things in Organization A.
      From talking to ohad previously this was possible, I just want to
      validate that it still would be possible (I believe it is). This is the
      "Organization" admin use case, where by i'm creating an admin that can
      manage things in a particular organization.

Thanks,

-Justin

··· On 11/22/2013 11:30 AM, Marek Hulan wrote: > Hi all > > During work on Foreman authorization code we have good chance to modify it for > Katello needs. I'd like to invite anyone interested in authorization system of > Foreman and Katello to a short session on Tue 26th at 9:30 EST. It shouldn't > take longer that 30 minutes. I'd like to investigate whether current Foreman > model is good enough for Katello (according to last meeting in Brno, it should > be) and find out what other features we may add. > > I'll start with description of current Foreman model and planned (but not > final) changes. Then the discussion should follow. > > I'll send a hangout link before start via email and irc #theforeman-dev > > -- > Marek >

We're starting in a few minutes:

hangout:
https://plus.google.com/hangouts/_/7acpjaphk5bfuovbtem5kepr6s?authuser=0&hl=en-GB
stream: http://youtu.be/2KP_qUVIv2c

More information about the design being discussed here:

https://github.com/ares/foreman/blob/feature/812_usergroup_roles/roles/gh_roles.md

··· On 22/11/13 16:30, Marek Hulan wrote: > Hi all > > During work on Foreman authorization code we have good chance to modify it for > Katello needs. I'd like to invite anyone interested in authorization system of > Foreman and Katello to a short session on Tue 26th at 9:30 EST. It shouldn't > take longer that 30 minutes. I'd like to investigate whether current Foreman > model is good enough for Katello (according to last meeting in Brno, it should > be) and find out what other features we may add. > > I'll start with description of current Foreman model and planned (but not > final) changes. Then the discussion should follow. > > I'll send a hangout link before start via email and irc #theforeman-dev


Dominic Cleal
Red Hat Engineering

Tom mckay…what about for Headpin… can you turn this stuff off as you
need to?

– bk

··· On 11/26/2013 11:49 AM, Justin Sherrill wrote: > On 11/22/2013 11:30 AM, Marek Hulan wrote: >> Hi all >> >> During work on Foreman authorization code we have good chance to >> modify it for >> Katello needs. I'd like to invite anyone interested in authorization >> system of >> Foreman and Katello to a short session on Tue 26th at 9:30 EST. It >> shouldn't >> take longer that 30 minutes. I'd like to investigate whether current >> Foreman >> model is good enough for Katello (according to last meeting in Brno, >> it should >> be) and find out what other features we may add. >> >> I'll start with description of current Foreman model and planned (but not >> final) changes. Then the discussion should follow. >> >> I'll send a hangout link before start via email and irc #theforeman-dev >> >> -- >> Marek >> > Good Job Marek! This looks much better than the previous permission > system and should fit katello's use cases pretty well. > > I did have a couple of comments from a katello perspective: > > * As I mentioned in the demo, I think it's important for users to be > able to physically select specific resources as well as use the scoped > search syntax. Not only is it easier for beginner users, but it would > work across renames without the user having to lookup and type in Ids. > This could be backed by scoped search for sure. > > * Katello has a pre-built read-only role created so that admins can give > an auditing type user read-access to everything on the satellite. Given > the number of permissions that would need to be granted within foreman, > I think this could be useful here too. Within katello we were tracking > whether a particular permission was a read permission or not, and > generated a role with all the 'read' permissions. None of this needs > to be done now, but some discussion/thought on how we could do it would > be useful. Mainly we need someway to know which permissions are > read-only or not. > > * This assumes that katello will need to add scoped search to all models > that need permissions. > > * We need to make sure that the plugin registration continues to work > (and allows new resource types to be added in addition to permissions). > > * To highlight a difference between katello and foreman, accessible orgs > are assigned apart from roles (In katello accessible orgs were derived > from a users roles). I think this is okay, just wanted to highlight the > difference. > > * One main use case with organizations is: > * I should be able to create a user and assign him to Organization A > and give him some role. > * That user should be able to create other users and create & assign > roles that only have access to things in Organization A. > From talking to ohad previously this was possible, I just want to > validate that it still would be possible (I believe it is). This is the > "Organization" admin use case, where by i'm creating an admin that can > manage things in a particular organization. > > Thanks, > > -Justin > > >

>> Hi all
>>
>> During work on Foreman authorization code we have good chance to
>> modify it for
>> Katello needs. I'd like to invite anyone interested in authorization
>> system of
>> Foreman and Katello to a short session on Tue 26th at 9:30 EST. It
>> shouldn't
>> take longer that 30 minutes. I'd like to investigate whether current
>> Foreman
>> model is good enough for Katello (according to last meeting in Brno,
>> it should
>> be) and find out what other features we may add.
>>
>> I'll start with description of current Foreman model and planned (but not
>> final) changes. Then the discussion should follow.
>>
>> I'll send a hangout link before start via email and irc #theforeman-dev
>>
>> –
>> Marek
>>
> Good Job Marek! This looks much better than the previous permission
> system and should fit katello's use cases pretty well.
>
> I did have a couple of comments from a katello perspective:
>
> * As I mentioned in the demo, I think it's important for users to be
> able to physically select specific resources as well as use the scoped
> search syntax. Not only is it easier for beginner users, but it would
> work across renames without the user having to lookup and type in Ids.
> This could be backed by scoped search for sure.

Good point. I think it could be solved by forcing (or by displaying
warning to) users to use only ids instead of names for searching for
particular resource. If auto-completion is modified to be able to search
by name for resource but inserting ids into search string it should make
it user-friendly. E.g.

filter/search on hosts: "hostgroup.id = HG"
auto-completion: "1 (HG1)", "2 (HG2)"
When you select "1 (HG1)" then search string would complete to
"hostgroup.id = 1" and it would use id for searching.

Would be something like this possible?

> * Katello has a pre-built read-only role created so that admins can give
> an auditing type user read-access to everything on the satellite. Given
> the number of permissions that would need to be granted within foreman,
> I think this could be useful here too. Within katello we were tracking
> whether a particular permission was a read permission or not, and
> generated a role with all the 'read' permissions. None of this needs
> to be done now, but some discussion/thought on how we could do it would
> be useful. Mainly we need someway to know which permissions are
> read-only or not.

Yes, we've talked about this shortly. There should be a default roles
(admin, read-only) created for each organization assuming that Filters
are scoped by taxonomy which is determining in which Organizations is
the filter valid. Meaning each Organization has its own Admin and
Read-only role but not preventing creation of global Admin or global
Read-only role.

> * This assumes that katello will need to add scoped search to all models
> that need permissions.

I would vote for it. It has benefits:

  • unified UX with searching over Katello and Foreman
  • Katello would not have its own system for full-text search
  • we could elastic-search usage only for errata and packages (big-ish data).
  • we would not need to keep ES index up to date for other resources -
    simplification of orchestration, no need to deal with situations where
    index is inconsistent, only one storage of data (DB)

> * We need to make sure that the plugin registration continues to work
> (and allows new resource types to be added in addition to permissions).
>
> * To highlight a difference between katello and foreman, accessible orgs
> are assigned apart from roles (In katello accessible orgs were derived
> from a users roles). I think this is okay, just wanted to highlight the
> difference.
>
> * One main use case with organizations is:
> * I should be able to create a user and assign him to Organization A
> and give him some role.

I think possible. The user would be given Admin role which is limited to
OrgA which is achieved by assigning Admin-role's Filter to OrgA (using
taxonomy). The admin-role does not apply outside of assigned organizations.

> * That user should be able to create other users and create & assign
> roles that only have access to things in Organization A.

I think possible. Let user A be the one assigning roles to
user/user-group B. Options:

  1. Users are not allowed to configure filters on roles unless they have
    another permission for that (reserved for organization-admins, who could
    only edit filters assigned to the same organization). Then A can only
    assign to B roles he is in.

  2. Users are allowed to configure filters on roles. Then filters need to
    be limited so A cannot create filter for B with searched_scope where its
    result is super-set of A's searched_scope of his filter.
    2.1) This can be achieved by only allowing A to create filters only for
    permissions where A does not have any searched_scope
    2.2) or by chaining A's searched_scope with the one being assigned to B
    with 'AND' which ensures that newly created filter is always generating
    a sub-set.

I think 1) is simple, straightforward and sufficient for our
requirements. 2) could be added if there is a need for it.

> From talking to ohad previously this was possible, I just want to
> validate that it still would be possible (I believe it is). This is the
> "Organization" admin use case, where by i'm creating an admin that can
> manage things in a particular organization.
>
> Thanks,
>
> -Justin
>
>
>

Petr

··· On 26.11.13 17:49, Justin Sherrill wrote: > On 11/22/2013 11:30 AM, Marek Hulan wrote:

> From: "Petr Chalupa" <pchalupa@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Wednesday, November 27, 2013 4:40:43 AM
> Subject: Re: [foreman-dev] Katello and Foreman permissions systems
>
>
>
> >> Hi all
> >>
> >> During work on Foreman authorization code we have good chance to
> >> modify it for
> >> Katello needs. I'd like to invite anyone interested in authorization
> >> system of
> >> Foreman and Katello to a short session on Tue 26th at 9:30 EST. It
> >> shouldn't
> >> take longer that 30 minutes. I'd like to investigate whether current
> >> Foreman
> >> model is good enough for Katello (according to last meeting in Brno,
> >> it should
> >> be) and find out what other features we may add.
> >>
> >> I'll start with description of current Foreman model and planned (but not
> >> final) changes. Then the discussion should follow.
> >>
> >> I'll send a hangout link before start via email and irc #theforeman-dev
> >>
> >> –
> >> Marek
> >>
> > Good Job Marek! This looks much better than the previous permission
> > system and should fit katello's use cases pretty well.
> >
> > I did have a couple of comments from a katello perspective:
> >
> > * As I mentioned in the demo, I think it's important for users to be
> > able to physically select specific resources as well as use the scoped
> > search syntax. Not only is it easier for beginner users, but it would
> > work across renames without the user having to lookup and type in Ids.
> > This could be backed by scoped search for sure.
>
> Good point. I think it could be solved by forcing (or by displaying
> warning to) users to use only ids instead of names for searching for
> particular resource. If auto-completion is modified to be able to search
> by name for resource but inserting ids into search string it should make
> it user-friendly. E.g.
>
> filter/search on hosts: "hostgroup.id = HG"
> auto-completion: "1 (HG1)", "2 (HG2)"
> When you select "1 (HG1)" then search string would complete to
> "hostgroup.id = 1" and it would use id for searching.
>
> Would be something like this possible?

Perhaps add unchanging katello-style labels to objects? Labels have stricter syntax requirements than names do in katello. For example, an organization can be named "ビッグ·ビジネス" with a label of "big_business". Search string would complete to "organization.label = big_business".

··· ----- Original Message ----- > On 26.11.13 17:49, Justin Sherrill wrote: > > On 11/22/2013 11:30 AM, Marek Hulan wrote:
  • Katello has a pre-built read-only role created so that admins can give
    an auditing type user read-access to everything on the satellite. Given
    the number of permissions that would need to be granted within foreman,
    I think this could be useful here too. Within katello we were tracking
    whether a particular permission was a read permission or not, and
    generated a role with all the ‘read’ permissions. None of this needs
    to be done now, but some discussion/thought on how we could do it would
    be useful. Mainly we need someway to know which permissions are
    read-only or not.

Yes, we’ve talked about this shortly. There should be a default roles
(admin, read-only) created for each organization assuming that Filters
are scoped by taxonomy which is determining in which Organizations is
the filter valid. Meaning each Organization has its own Admin and
Read-only role but not preventing creation of global Admin or global
Read-only role.

  • This assumes that katello will need to add scoped search to all models
    that need permissions.

I would vote for it. It has benefits:

  • unified UX with searching over Katello and Foreman
  • Katello would not have its own system for full-text search
  • we could elastic-search usage only for errata and packages (big-ish data).
  • we would not need to keep ES index up to date for other resources -
    simplification of orchestration, no need to deal with situations where
    index is inconsistent, only one storage of data (DB)
  • We need to make sure that the plugin registration continues to work
    (and allows new resource types to be added in addition to permissions).

  • To highlight a difference between katello and foreman, accessible orgs
    are assigned apart from roles (In katello accessible orgs were derived
    from a users roles). I think this is okay, just wanted to highlight the
    difference.

  • One main use case with organizations is:

    • I should be able to create a user and assign him to Organization A
      and give him some role.

I think possible. The user would be given Admin role which is limited to
OrgA which is achieved by assigning Admin-role’s Filter to OrgA (using
taxonomy). The admin-role does not apply outside of assigned organizations.

  • That user should be able to create other users and create & assign
    roles that only have access to things in Organization A.

I think possible. Let user A be the one assigning roles to
user/user-group B. Options:

  1. Users are not allowed to configure filters on roles unless they have
    another permission for that (reserved for organization-admins, who could
    only edit filters assigned to the same organization). Then A can only
    assign to B roles he is in.

  2. Users are allowed to configure filters on roles. Then filters need to
    be limited so A cannot create filter for B with searched_scope where its
    result is super-set of A’s searched_scope of his filter.
    2.1) This can be achieved by only allowing A to create filters only for
    permissions where A does not have any searched_scope
    2.2) or by chaining A’s searched_scope with the one being assigned to B
    with ‘AND’ which ensures that newly created filter is always generating
    a sub-set.

I think 1) is simple, straightforward and sufficient for our
requirements. 2) could be added if there is a need for it.

From talking to ohad previously this was possible, I just want to
validate that it still would be possible (I believe it is). This is the
"Organization" admin use case, where by i’m creating an admin that can
manage things in a particular organization.

Thanks,

-Justin

Petr


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

> 1) Users are not allowed to configure filters on roles unless they have
> another permission for that (reserved for organization-admins, who could
> only edit filters assigned to the same organization). Then A can only
> assign to B roles he is in.
>
> 2) Users are allowed to configure filters on roles. Then filters need to
> be limited so A cannot create filter for B with searched_scope where its
> result is super-set of A's searched_scope of his filter.
> 2.1) This can be achieved by only allowing A to create filters only for
> permissions where A does not have any searched_scope
> 2.2) or by chaining A's searched_scope with the one being assigned to B
> with 'AND' which ensures that newly created filter is always generating
> a sub-set.
>
> I think 1) is simple, straightforward and sufficient for our
> requirements. 2) could be added if there is a need for it.

Thanks Petr, I think you sum up all points nicely. I think we should just make
sure that 1) is sufficient for our needs. Does anyone see a problem with it?

··· -- Marek

On Wednesday 27 of November 2013 10:40:43 Petr Chalupa wrote:

On 26.11.13 17:49, Justin Sherrill wrote:

On 11/22/2013 11:30 AM, Marek Hulan wrote:

Hi all

During work on Foreman authorization code we have good chance to
modify it for
Katello needs. I’d like to invite anyone interested in authorization
system of
Foreman and Katello to a short session on Tue 26th at 9:30 EST. It
shouldn’t
take longer that 30 minutes. I’d like to investigate whether current
Foreman
model is good enough for Katello (according to last meeting in Brno,
it should
be) and find out what other features we may add.

I’ll start with description of current Foreman model and planned (but not
final) changes. Then the discussion should follow.

I’ll send a hangout link before start via email and irc #theforeman-dev


Marek

Good Job Marek! This looks much better than the previous permission
system and should fit katello’s use cases pretty well.

I did have a couple of comments from a katello perspective:

  • As I mentioned in the demo, I think it’s important for users to be
    able to physically select specific resources as well as use the scoped
    search syntax. Not only is it easier for beginner users, but it would
    work across renames without the user having to lookup and type in Ids.
    This could be backed by scoped search for sure.

Good point. I think it could be solved by forcing (or by displaying
warning to) users to use only ids instead of names for searching for
particular resource. If auto-completion is modified to be able to search
by name for resource but inserting ids into search string it should make
it user-friendly. E.g.

filter/search on hosts: "hostgroup.id = HG"
auto-completion: “1 (HG1)”, "2 (HG2)“
When you select “1 (HG1)” then search string would complete to
"hostgroup.id = 1” and it would use id for searching.

Would be something like this possible?

  • Katello has a pre-built read-only role created so that admins can give
    an auditing type user read-access to everything on the satellite. Given
    the number of permissions that would need to be granted within foreman,
    I think this could be useful here too. Within katello we were tracking
    whether a particular permission was a read permission or not, and
    generated a role with all the ‘read’ permissions. None of this needs
    to be done now, but some discussion/thought on how we could do it would
    be useful. Mainly we need someway to know which permissions are
    read-only or not.

Yes, we’ve talked about this shortly. There should be a default roles
(admin, read-only) created for each organization assuming that Filters
are scoped by taxonomy which is determining in which Organizations is
the filter valid. Meaning each Organization has its own Admin and
Read-only role but not preventing creation of global Admin or global
Read-only role.

  • This assumes that katello will need to add scoped search to all models
    that need permissions.

I would vote for it. It has benefits:

  • unified UX with searching over Katello and Foreman
  • Katello would not have its own system for full-text search
  • we could elastic-search usage only for errata and packages (big-ish data).
  • we would not need to keep ES index up to date for other resources -
    simplification of orchestration, no need to deal with situations where
    index is inconsistent, only one storage of data (DB)
  • We need to make sure that the plugin registration continues to work
    (and allows new resource types to be added in addition to permissions).

  • To highlight a difference between katello and foreman, accessible orgs
    are assigned apart from roles (In katello accessible orgs were derived
    from a users roles). I think this is okay, just wanted to highlight the
    difference.

  • One main use case with organizations is:

    • I should be able to create a user and assign him to Organization A

and give him some role.

I think possible. The user would be given Admin role which is limited to
OrgA which is achieved by assigning Admin-role’s Filter to OrgA (using
taxonomy). The admin-role does not apply outside of assigned organizations.

  • That user should be able to create other users and create & assign

roles that only have access to things in Organization A.

I think possible. Let user A be the one assigning roles to
user/user-group B. Options:

  1. Users are not allowed to configure filters on roles unless they have
    another permission for that (reserved for organization-admins, who could
    only edit filters assigned to the same organization). Then A can only
    assign to B roles he is in.

  2. Users are allowed to configure filters on roles. Then filters need to
    be limited so A cannot create filter for B with searched_scope where its
    result is super-set of A’s searched_scope of his filter.
    2.1) This can be achieved by only allowing A to create filters only for
    permissions where A does not have any searched_scope
    2.2) or by chaining A’s searched_scope with the one being assigned to B
    with ‘AND’ which ensures that newly created filter is always generating
    a sub-set.

I think 1) is simple, straightforward and sufficient for our
requirements. 2) could be added if there is a need for it.

From talking to ohad previously this was possible, I just want to

validate that it still would be possible (I believe it is). This is the
"Organization" admin use case, where by i’m creating an admin that can
manage things in a particular organization.

Thanks,

-Justin

Petr

>
> > From: "Petr Chalupa" <pchalupa@redhat.com>
> > To: foreman-dev@googlegroups.com
> > Sent: Wednesday, November 27, 2013 4:40:43 AM
> > Subject: Re: [foreman-dev] Katello and Foreman permissions systems
> >
> >
> >
> >
> > >
> > >> Hi all
> > >>
> > >>
> > >>
> > >> During work on Foreman authorization code we have good chance to
> > >> modify it for
> > >> Katello needs. I'd like to invite anyone interested in authorization
> > >> system of
> > >> Foreman and Katello to a short session on Tue 26th at 9:30 EST. It
> > >> shouldn't
> > >> take longer that 30 minutes. I'd like to investigate whether current
> > >> Foreman
> > >> model is good enough for Katello (according to last meeting in Brno,
> > >> it should
> > >> be) and find out what other features we may add.
> > >>
> > >>
> > >>
> > >> I'll start with description of current Foreman model and planned (but
> > >> not
> > >> final) changes. Then the discussion should follow.
> > >>
> > >>
> > >>
> > >> I'll send a hangout link before start via email and irc
> > >> #theforeman-dev
> > >>
> > >>
> > >>
> > >> –
> > >> Marek
> > >>
> > >>
> > >>
> > > Good Job Marek! This looks much better than the previous permission
> > > system and should fit katello's use cases pretty well.
> > >
> > >
> > >
> > > I did have a couple of comments from a katello perspective:
> > >
> > >
> > >
> > > * As I mentioned in the demo, I think it's important for users to be
> > > able to physically select specific resources as well as use the scoped
> > > search syntax. Not only is it easier for beginner users, but it would
> > > work across renames without the user having to lookup and type in Ids.
> > > This could be backed by scoped search for sure.
> >
> >
> > Good point. I think it could be solved by forcing (or by displaying
> > warning to) users to use only ids instead of names for searching for
> > particular resource. If auto-completion is modified to be able to search
> > by name for resource but inserting ids into search string it should make
> > it user-friendly. E.g.
> >
> > filter/search on hosts: "hostgroup.id = HG"
> > auto-completion: "1 (HG1)", "2 (HG2)"
> > When you select "1 (HG1)" then search string would complete to
> > "hostgroup.id = 1" and it would use id for searching.
> >
> > Would be something like this possible?
>
>
> Perhaps add unchanging katello-style labels to objects? Labels have stricter
> syntax requirements than names do in katello. For example, an organization
> can be named "ビッグ・ビジネス" with a label of "big_business". Search string would
> complete to "organization.label = big_business".

Well the problem is with renaming. So we'd end up in a situation, that there
would be organization with name "Small business" labeled "big_business" after
someone renamed it?

I'd like to use id to identify. What Petr suggests has only one drawback,
users wouldn't know what such scoped_search string means. Maybe by editing it,
autocompletion would display it again.

>
> >
> >
> > > * Katello has a pre-built read-only role created so that admins can
> > > give
> > > an auditing type user read-access to everything on the satellite.
> > > Given
> > > the number of permissions that would need to be granted within foreman,
> > > I think this could be useful here too. Within katello we were tracking
> > > whether a particular permission was a read permission or not, and
> > > generated a role with all the 'read' permissions. None of this needs
> > > to be done now, but some discussion/thought on how we could do it would
> > > be useful. Mainly we need someway to know which permissions are
> > > read-only or not.
> >
> >
> > Yes, we've talked about this shortly. There should be a default roles
> > (admin, read-only) created for each organization assuming that Filters
> > are scoped by taxonomy which is determining in which Organizations is
> > the filter valid. Meaning each Organization has its own Admin and
> > Read-only role but not preventing creation of global Admin or global
> > Read-only role.
> >
> >
> > > * This assumes that katello will need to add scoped search to all
> > > models
> > > that need permissions.
> >
> >
> > I would vote for it. It has benefits:
> > * unified UX with searching over Katello and Foreman
> > * Katello would not have its own system for full-text search
> > * we could elastic-search usage only for errata and packages (big-ish
> > data).

  • we would not need to keep ES index up to date for other
··· On Wednesday 27 of November 2013 13:58:19 Tom McKay wrote: > ----- Original Message ----- > > On 26.11.13 17:49, Justin Sherrill wrote: > > > On 11/22/2013 11:30 AM, Marek Hulan wrote: > > resources - simplification of orchestration, no need to deal with > > situations where index is inconsistent, only one storage of data (DB) > > > > > > > * We need to make sure that the plugin registration continues to work > > > (and allows new resource types to be added in addition to permissions). > > > > > > > > > > > > * To highlight a difference between katello and foreman, accessible > > > orgs > > > are assigned apart from roles (In katello accessible orgs were derived > > > from a users roles). I think this is okay, just wanted to highlight > > > the > > > difference. > > > > > > > > > > > > * One main use case with organizations is: > > > > > > * I should be able to create a user and assign him to Organization A > > > > > > and give him some role. > > > > > > I think possible. The user would be given Admin role which is limited to > > OrgA which is achieved by assigning Admin-role's Filter to OrgA (using > > taxonomy). The admin-role does not apply outside of assigned > > organizations.
  • That user should be able to create other users and create & assign

roles that only have access to things in Organization A.

I think possible. Let user A be the one assigning roles to
user/user-group B. Options:

  1. Users are not allowed to configure filters on roles unless they have
    another permission for that (reserved for organization-admins, who could
    only edit filters assigned to the same organization). Then A can only
    assign to B roles he is in.

  2. Users are allowed to configure filters on roles. Then filters need to
    be limited so A cannot create filter for B with searched_scope where its
    result is super-set of A’s searched_scope of his filter.
    2.1) This can be achieved by only allowing A to create filters only for
    permissions where A does not have any searched_scope
    2.2) or by chaining A’s searched_scope with the one being assigned to B
    with ‘AND’ which ensures that newly created filter is always generating
    a sub-set.

I think 1) is simple, straightforward and sufficient for our
requirements. 2) could be added if there is a need for it.

From talking to ohad previously this was possible, I just want to

validate that it still would be possible (I believe it is). This is
the
"Organization" admin use case, where by i’m creating an admin that can
manage things in a particular organization.

Thanks,

-Justin

Petr


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Marek

>>
>> > From: "Petr Chalupa" <pchalupa@redhat.com>
>> > To: foreman-dev@googlegroups.com
>> > Sent: Wednesday, November 27, 2013 4:40:43 AM
>> > Subject: Re: [foreman-dev] Katello and Foreman permissions systems
>> >
>> >
>> >
>> >
>> > >
>> > >> Hi all
>> > >>
>> > >>
>> > >>
>> > >> During work on Foreman authorization code we have good chance to
>> > >> modify it for
>> > >> Katello needs. I'd like to invite anyone interested in authorization
>> > >> system of
>> > >> Foreman and Katello to a short session on Tue 26th at 9:30 EST. It
>> > >> shouldn't
>> > >> take longer that 30 minutes. I'd like to investigate whether current
>> > >> Foreman
>> > >> model is good enough for Katello (according to last meeting in Brno,
>> > >> it should
>> > >> be) and find out what other features we may add.
>> > >>
>> > >>
>> > >>
>> > >> I'll start with description of current Foreman model and planned (but
>> > >> not
>> > >> final) changes. Then the discussion should follow.
>> > >>
>> > >>
>> > >>
>> > >> I'll send a hangout link before start via email and irc
>> > >> #theforeman-dev
>> > >>
>> > >>
>> > >>
>> > >> –
>> > >> Marek
>> > >>
>> > >>
>> > >>
>> > > Good Job Marek! This looks much better than the previous permission
>> > > system and should fit katello's use cases pretty well.
>> > >
>> > >
>> > >
>> > > I did have a couple of comments from a katello perspective:
>> > >
>> > >
>> > >
>> > > * As I mentioned in the demo, I think it's important for users to be
>> > > able to physically select specific resources as well as use the scoped
>> > > search syntax. Not only is it easier for beginner users, but it would
>> > > work across renames without the user having to lookup and type in Ids.
>> > > This could be backed by scoped search for sure.
>> >
>> >
>> > Good point. I think it could be solved by forcing (or by displaying
>> > warning to) users to use only ids instead of names for searching for
>> > particular resource. If auto-completion is modified to be able to search
>> > by name for resource but inserting ids into search string it should make
>> > it user-friendly. E.g.
>> >
>> > filter/search on hosts: "hostgroup.id = HG"
>> > auto-completion: "1 (HG1)", "2 (HG2)"
>> > When you select "1 (HG1)" then search string would complete to
>> > "hostgroup.id = 1" and it would use id for searching.
>> >
>> > Would be something like this possible?
>>
>>
>> Perhaps add unchanging katello-style labels to objects? Labels have stricter
>> syntax requirements than names do in katello. For example, an organization
>> can be named "ビッグ・ビジネス" with a label of "big_business". Search string would
>> complete to "organization.label = big_business".
>
> Well the problem is with renaming. So we'd end up in a situation, that there
> would be organization with name "Small business" labeled "big_business" after
> someone renamed it?
>
> I'd like to use id to identify. What Petr suggests has only one drawback,
> users wouldn't know what such scoped_search string means. Maybe by editing it,
> autocompletion would display it again.

the nice thing about scope search, is that its just a scope, meaning
you can join it to any existing scope. for example:

Orgs.my_orgs.scoped_search(params).

Would that be good enough?

Ohad

··· On Thu, Nov 28, 2013 at 10:38 AM, Marek Hulan wrote: > On Wednesday 27 of November 2013 13:58:19 Tom McKay wrote: >> ----- Original Message ----- >> > On 26.11.13 17:49, Justin Sherrill wrote: >> > > On 11/22/2013 11:30 AM, Marek Hulan wrote: > > >> >> > >> > >> > > * Katello has a pre-built read-only role created so that admins can >> > > give >> > > an auditing type user read-access to everything on the satellite. >> > > Given >> > > the number of permissions that would need to be granted within foreman, >> > > I think this could be useful here too. Within katello we were tracking >> > > whether a particular permission was a read permission or not, and >> > > generated a role with all the 'read' permissions. None of this needs >> > > to be done now, but some discussion/thought on how we could do it would >> > > be useful. Mainly we need someway to know which permissions are >> > > read-only or not. >> > >> > >> > Yes, we've talked about this shortly. There should be a default roles >> > (admin, read-only) created for each organization assuming that Filters >> > are scoped by taxonomy which is determining in which Organizations is >> > the filter valid. Meaning each Organization has its own Admin and >> > Read-only role but not preventing creation of global Admin or global >> > Read-only role. >> > >> > >> > > * This assumes that katello will need to add scoped search to all >> > > models >> > > that need permissions. >> > >> > >> > I would vote for it. It has benefits: >> > * unified UX with searching over Katello and Foreman >> > * Katello would not have its own system for full-text search >> > * we could elastic-search usage only for errata and packages (big-ish >> > data). > * we would not need to keep ES index up to date for other >> > resources - simplification of orchestration, no need to deal with >> > situations where index is inconsistent, only one storage of data (DB) >> > >> > >> > > * We need to make sure that the plugin registration continues to work >> > > (and allows new resource types to be added in addition to permissions). >> > > >> > > >> > > >> > > * To highlight a difference between katello and foreman, accessible >> > > orgs >> > > are assigned apart from roles (In katello accessible orgs were derived >> > > from a users roles). I think this is okay, just wanted to highlight >> > > the >> > > difference. >> > > >> > > >> > > >> > > * One main use case with organizations is: >> > > >> > > * I should be able to create a user and assign him to Organization A >> > > >> > > and give him some role. >> > >> > >> > I think possible. The user would be given Admin role which is limited to >> > OrgA which is achieved by assigning Admin-role's Filter to OrgA (using >> > taxonomy). The admin-role does not apply outside of assigned >> > organizations. > >> > >> > > * That user should be able to create other users and create & assign >> > > >> > > roles that only have access to things in Organization A. >> > >> > >> > I think possible. Let user A be the one assigning roles to >> > user/user-group B. Options: >> > >> > 1) Users are not allowed to configure filters on roles unless they have >> > another permission for that (reserved for organization-admins, who could >> > only edit filters assigned to the same organization). Then A can only >> > assign to B roles he is in. >> > >> > 2) Users are allowed to configure filters on roles. Then filters need to >> > be limited so A cannot create filter for B with searched_scope where its >> > result is super-set of A's searched_scope of his filter. >> > 2.1) This can be achieved by only allowing A to create filters only for >> > permissions where A does not have any searched_scope >> > 2.2) or by chaining A's searched_scope with the one being assigned to B >> > with 'AND' which ensures that newly created filter is always generating >> > a sub-set. >> > >> > I think 1) is simple, straightforward and sufficient for our >> > requirements. 2) could be added if there is a need for it. >> > >> > >> > > From talking to ohad previously this was possible, I just want to >> > > >> > > validate that it still would be possible (I believe it is). This is >> > > the >> > > "Organization" admin use case, where by i'm creating an admin that can >> > > manage things in a particular organization. >> > > >> > > >> > > >> > > Thanks, >> > > >> > > >> > > >> > > -Justin >> > > >> > > >> > > >> > > >> > >> > >> > Petr >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "foreman-dev" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> > email to foreman-dev+unsubscribe@googlegroups.com. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> >> > > -- > Marek > > -- > You received this message because you are subscribed to the Google Groups "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.

> From: "Marek Hulan" <mhulan@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Thursday, November 28, 2013 3:38:28 AM
> Subject: Re: [foreman-dev] Katello and Foreman permissions systems
>
> >
> > > From: "Petr Chalupa" <pchalupa@redhat.com>
> > > To: foreman-dev@googlegroups.com
> > > Sent: Wednesday, November 27, 2013 4:40:43 AM
> > > Subject: Re: [foreman-dev] Katello and Foreman permissions systems
> > >
> > >
> > >
> > >
> > > >
> > > >> Hi all
> > > >>
> > > >>
> > > >>
> > > >> During work on Foreman authorization code we have good chance to
> > > >> modify it for
> > > >> Katello needs. I'd like to invite anyone interested in authorization
> > > >> system of
> > > >> Foreman and Katello to a short session on Tue 26th at 9:30 EST. It
> > > >> shouldn't
> > > >> take longer that 30 minutes. I'd like to investigate whether current
> > > >> Foreman
> > > >> model is good enough for Katello (according to last meeting in Brno,
> > > >> it should
> > > >> be) and find out what other features we may add.
> > > >>
> > > >>
> > > >>
> > > >> I'll start with description of current Foreman model and planned (but
> > > >> not
> > > >> final) changes. Then the discussion should follow.
> > > >>
> > > >>
> > > >>
> > > >> I'll send a hangout link before start via email and irc
> > > >> #theforeman-dev
> > > >>
> > > >>
> > > >>
> > > >> –
> > > >> Marek
> > > >>
> > > >>
> > > >>
> > > > Good Job Marek! This looks much better than the previous permission
> > > > system and should fit katello's use cases pretty well.
> > > >
> > > >
> > > >
> > > > I did have a couple of comments from a katello perspective:
> > > >
> > > >
> > > >
> > > > * As I mentioned in the demo, I think it's important for users to be
> > > > able to physically select specific resources as well as use the scoped
> > > > search syntax. Not only is it easier for beginner users, but it would
> > > > work across renames without the user having to lookup and type in Ids.
> > > > This could be backed by scoped search for sure.
> > >
> > >
> > > Good point. I think it could be solved by forcing (or by displaying
> > > warning to) users to use only ids instead of names for searching for
> > > particular resource. If auto-completion is modified to be able to search
> > > by name for resource but inserting ids into search string it should make
> > > it user-friendly. E.g.
> > >
> > > filter/search on hosts: "hostgroup.id = HG"
> > > auto-completion: "1 (HG1)", "2 (HG2)"
> > > When you select "1 (HG1)" then search string would complete to
> > > "hostgroup.id = 1" and it would use id for searching.
> > >
> > > Would be something like this possible?
> >
> >
> > Perhaps add unchanging katello-style labels to objects? Labels have
> > stricter
> > syntax requirements than names do in katello. For example, an organization
> > can be named "ビッグ・ビジネス" with a label of "big_business". Search string would
> > complete to "organization.label = big_business".
>
> Well the problem is with renaming. So we'd end up in a situation, that there
> would be organization with name "Small business" labeled "big_business" after
> someone renamed it?

Correct, there is a chance that the editable name can stray from the uneditable label. (That said, most objects could also allow editing of the label without issues, if desired.)

The other benefit of labels is that they are more readily usable on the CLI.

% hammer organization info --name ビッグ・ビジネス <-- error
% hammer organization info --id 12
vs.
% hammer organization info --id big_business

I know product management has been asking for a reduction in the need to specify (or even see) internal IDs. I'll let them comment directly.

··· ----- Original Message ----- > On Wednesday 27 of November 2013 13:58:19 Tom McKay wrote: > > ----- Original Message ----- > > > On 26.11.13 17:49, Justin Sherrill wrote: > > > > On 11/22/2013 11:30 AM, Marek Hulan wrote:

I’d like to use id to identify. What Petr suggests has only one drawback,
users wouldn’t know what such scoped_search string means. Maybe by editing
it,
autocompletion would display it again.

  • Katello has a pre-built read-only role created so that admins can
    give
    an auditing type user read-access to everything on the satellite.
    Given
    the number of permissions that would need to be granted within foreman,
    I think this could be useful here too. Within katello we were tracking
    whether a particular permission was a read permission or not, and
    generated a role with all the ‘read’ permissions. None of this needs
    to be done now, but some discussion/thought on how we could do it would
    be useful. Mainly we need someway to know which permissions are
    read-only or not.

Yes, we’ve talked about this shortly. There should be a default roles
(admin, read-only) created for each organization assuming that Filters
are scoped by taxonomy which is determining in which Organizations is
the filter valid. Meaning each Organization has its own Admin and
Read-only role but not preventing creation of global Admin or global
Read-only role.

  • This assumes that katello will need to add scoped search to all
    models
    that need permissions.

I would vote for it. It has benefits:

  • unified UX with searching over Katello and Foreman
  • Katello would not have its own system for full-text search
  • we could elastic-search usage only for errata and packages (big-ish
    data).
  • we would not need to keep ES index up to date for other

resources - simplification of orchestration, no need to deal with
situations where index is inconsistent, only one storage of data (DB)

  • We need to make sure that the plugin registration continues to work
    (and allows new resource types to be added in addition to permissions).

  • To highlight a difference between katello and foreman, accessible
    orgs
    are assigned apart from roles (In katello accessible orgs were derived
    from a users roles). I think this is okay, just wanted to highlight
    the
    difference.

  • One main use case with organizations is:

    • I should be able to create a user and assign him to Organization A

and give him some role.

I think possible. The user would be given Admin role which is limited to
OrgA which is achieved by assigning Admin-role’s Filter to OrgA (using
taxonomy). The admin-role does not apply outside of assigned
organizations.

  • That user should be able to create other users and create & assign

roles that only have access to things in Organization A.

I think possible. Let user A be the one assigning roles to
user/user-group B. Options:

  1. Users are not allowed to configure filters on roles unless they have
    another permission for that (reserved for organization-admins, who could
    only edit filters assigned to the same organization). Then A can only
    assign to B roles he is in.

  2. Users are allowed to configure filters on roles. Then filters need to
    be limited so A cannot create filter for B with searched_scope where its
    result is super-set of A’s searched_scope of his filter.
    2.1) This can be achieved by only allowing A to create filters only for
    permissions where A does not have any searched_scope
    2.2) or by chaining A’s searched_scope with the one being assigned to B
    with ‘AND’ which ensures that newly created filter is always generating
    a sub-set.

I think 1) is simple, straightforward and sufficient for our
requirements. 2) could be added if there is a need for it.

From talking to ohad previously this was possible, I just want to

validate that it still would be possible (I believe it is). This is
the
"Organization" admin use case, where by i’m creating an admin that can
manage things in a particular organization.

Thanks,

-Justin

Petr


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Marek


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

> Well the problem is with renaming. So we'd end up in a situation, that there
> would be organization with name "Small business" labeled "big_business" after
> someone renamed it?

The problem Katello is trying to solve is it is not possible to rename
some objects. For example it is not possible to rename Pulp
repositories. While it is technically possible to rename already
published repositories, the problem is with certificates that has been
already issued. They are bound to pulp's URLs, it's part of the
certificate validation. It could be solved with some redirects maybe
(not saying that is not possible - it's just tough I guess).

For this reason, labels were introduced. Also it has strict rules
because then they are directly used in URLs (pulp repositories being
published). Labels are immutable.

So you can get to situation that something gets renamed while it's label
(and repositories) are being unchanged. That is not a bug, but a
feature.

LZ

··· -- Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman

> >>
> >> > From: "Petr Chalupa" <pchalupa@redhat.com>
> >> > To: foreman-dev@googlegroups.com
> >> > Sent: Wednesday, November 27, 2013 4:40:43 AM
> >> > Subject: Re: [foreman-dev] Katello and Foreman permissions systems
> >> >
> >> > >> Hi all
> >> > >>
> >> > >>
> >> > >>
> >> > >> During work on Foreman authorization code we have good chance to
> >> > >> modify it for
> >> > >> Katello needs. I'd like to invite anyone interested in authorization
> >> > >> system of
> >> > >> Foreman and Katello to a short session on Tue 26th at 9:30 EST. It
> >> > >> shouldn't
> >> > >> take longer that 30 minutes. I'd like to investigate whether current
> >> > >> Foreman
> >> > >> model is good enough for Katello (according to last meeting in Brno,
> >> > >> it should
> >> > >> be) and find out what other features we may add.
> >> > >>
> >> > >>
> >> > >>
> >> > >> I'll start with description of current Foreman model and planned
> >> > >> (but
> >> > >> not
> >> > >> final) changes. Then the discussion should follow.
> >> > >>
> >> > >>
> >> > >>
> >> > >> I'll send a hangout link before start via email and irc
> >> > >> #theforeman-dev
> >> > >>
> >> > >>
> >> > >>
> >> > >> –
> >> > >> Marek
> >> > >
> >> > > Good Job Marek! This looks much better than the previous permission
> >> > > system and should fit katello's use cases pretty well.
> >> > >
> >> > >
> >> > >
> >> > > I did have a couple of comments from a katello perspective:
> >> > >
> >> > >
> >> > >
> >> > > * As I mentioned in the demo, I think it's important for users to be
> >> > > able to physically select specific resources as well as use the
> >> > > scoped
> >> > > search syntax. Not only is it easier for beginner users, but it
> >> > > would
> >> > > work across renames without the user having to lookup and type in
> >> > > Ids.
> >> > > This could be backed by scoped search for sure.
> >> >
> >> > Good point. I think it could be solved by forcing (or by displaying
> >> > warning to) users to use only ids instead of names for searching for
> >> > particular resource. If auto-completion is modified to be able to
> >> > search
> >> > by name for resource but inserting ids into search string it should
> >> > make
> >> > it user-friendly. E.g.
> >> >
> >> > filter/search on hosts: "hostgroup.id = HG"
> >> > auto-completion: "1 (HG1)", "2 (HG2)"
> >> > When you select "1 (HG1)" then search string would complete to
> >> > "hostgroup.id = 1" and it would use id for searching.
> >> >
> >> > Would be something like this possible?
> >>
> >> Perhaps add unchanging katello-style labels to objects? Labels have
> >> stricter syntax requirements than names do in katello. For example, an
> >> organization can be named "ビッグ・ビジネス" with a label of "big_business".
> >> Search string would complete to "organization.label = big_business".
> >
> > Well the problem is with renaming. So we'd end up in a situation, that
> > there would be organization with name "Small business" labeled
> > "big_business" after someone renamed it?
> >
> > I'd like to use id to identify. What Petr suggests has only one drawback,
> > users wouldn't know what such scoped_search string means. Maybe by editing
> > it, autocompletion would display it again.
>
> the nice thing about scope search, is that its just a scope, meaning
> you can join it to any existing scope. for example:
>
> Orgs.my_orgs.scoped_search(params).
>
> Would that be good enough?

For organizations yes, but the same problem with the naming exists for e.g.
hostgroups. Organizations are to be set outside of scoped search strings. But
we must point to specific hostgroup. Id seems the best but users won't
understand it so we should be able to interpret it using current name value
somehow.

··· On Thursday 28 of November 2013 10:40:13 Ohad Levy wrote: > On Thu, Nov 28, 2013 at 10:38 AM, Marek Hulan wrote: > > On Wednesday 27 of November 2013 13:58:19 Tom McKay wrote: > >> ----- Original Message ----- > >> > On 26.11.13 17:49, Justin Sherrill wrote: > >> > > On 11/22/2013 11:30 AM, Marek Hulan wrote:

Ohad

  • Katello has a pre-built read-only role created so that admins can
    give
    an auditing type user read-access to everything on the satellite.
    Given
    the number of permissions that would need to be granted within
    foreman,
    I think this could be useful here too. Within katello we were
    tracking
    whether a particular permission was a read permission or not, and
    generated a role with all the ‘read’ permissions. None of this
    needs
    to be done now, but some discussion/thought on how we could do it
    would
    be useful. Mainly we need someway to know which permissions are
    read-only or not.

Yes, we’ve talked about this shortly. There should be a default roles
(admin, read-only) created for each organization assuming that Filters
are scoped by taxonomy which is determining in which Organizations is
the filter valid. Meaning each Organization has its own Admin and
Read-only role but not preventing creation of global Admin or global
Read-only role.

  • This assumes that katello will need to add scoped search to all
    models
    that need permissions.

I would vote for it. It has benefits:

  • unified UX with searching over Katello and Foreman
  • Katello would not have its own system for full-text search
  • we could elastic-search usage only for errata and packages (big-ish
    data).
  • we would not need to keep ES index up to date for other

resources - simplification of orchestration, no need to deal with
situations where index is inconsistent, only one storage of data (DB)

  • We need to make sure that the plugin registration continues to work
    (and allows new resource types to be added in addition to
    permissions).

  • To highlight a difference between katello and foreman, accessible
    orgs
    are assigned apart from roles (In katello accessible orgs were
    derived
    from a users roles). I think this is okay, just wanted to highlight
    the
    difference.

  • One main use case with organizations is:

    • I should be able to create a user and assign him to Organization
      A

and give him some role.

I think possible. The user would be given Admin role which is limited
to
OrgA which is achieved by assigning Admin-role’s Filter to OrgA (using
taxonomy). The admin-role does not apply outside of assigned
organizations.

  • That user should be able to create other users and create &
    assign

roles that only have access to things in Organization A.

I think possible. Let user A be the one assigning roles to
user/user-group B. Options:

  1. Users are not allowed to configure filters on roles unless they have
    another permission for that (reserved for organization-admins, who
    could
    only edit filters assigned to the same organization). Then A can only
    assign to B roles he is in.

  2. Users are allowed to configure filters on roles. Then filters need
    to
    be limited so A cannot create filter for B with searched_scope where
    its
    result is super-set of A’s searched_scope of his filter.
    2.1) This can be achieved by only allowing A to create filters only for
    permissions where A does not have any searched_scope
    2.2) or by chaining A’s searched_scope with the one being assigned to B
    with ‘AND’ which ensures that newly created filter is always generating
    a sub-set.

I think 1) is simple, straightforward and sufficient for our
requirements. 2) could be added if there is a need for it.

From talking to ohad previously this was possible, I just want to

validate that it still would be possible (I believe it is). This is
the
"Organization" admin use case, where by i’m creating an admin that
can
manage things in a particular organization.

Thanks,

-Justin

Petr


You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Marek


You received this message because you are subscribed to the Google Groups
"foreman-dev" group. To unsubscribe from this group and stop receiving
emails from it, send an email to
foreman-dev+unsubscribe@googlegroups.com. For more options, visit
https://groups.google.com/groups/opt_out.


Marek

>>>>
>>>>> From: "Petr Chalupa" <pchalupa@redhat.com>
>>>>> To: foreman-dev@googlegroups.com
>>>>> Sent: Wednesday, November 27, 2013 4:40:43 AM
>>>>> Subject: Re: [foreman-dev] Katello and Foreman permissions systems
>>>>>
>>>>>>> Hi all
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> During work on Foreman authorization code we have good chance to
>>>>>>> modify it for
>>>>>>> Katello needs. I'd like to invite anyone interested in authorization
>>>>>>> system of
>>>>>>> Foreman and Katello to a short session on Tue 26th at 9:30 EST. It
>>>>>>> shouldn't
>>>>>>> take longer that 30 minutes. I'd like to investigate whether current
>>>>>>> Foreman
>>>>>>> model is good enough for Katello (according to last meeting in Brno,
>>>>>>> it should
>>>>>>> be) and find out what other features we may add.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'll start with description of current Foreman model and planned
>>>>>>> (but
>>>>>>> not
>>>>>>> final) changes. Then the discussion should follow.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'll send a hangout link before start via email and irc
>>>>>>> #theforeman-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> –
>>>>>>> Marek
>>>>>>
>>>>>> Good Job Marek! This looks much better than the previous permission
>>>>>> system and should fit katello's use cases pretty well.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I did have a couple of comments from a katello perspective:
>>>>>>
>>>>>>
>>>>>>
>>>>>> * As I mentioned in the demo, I think it's important for users to be
>>>>>> able to physically select specific resources as well as use the
>>>>>> scoped
>>>>>> search syntax. Not only is it easier for beginner users, but it
>>>>>> would
>>>>>> work across renames without the user having to lookup and type in
>>>>>> Ids.
>>>>>> This could be backed by scoped search for sure.
>>>>>
>>>>> Good point. I think it could be solved by forcing (or by displaying
>>>>> warning to) users to use only ids instead of names for searching for
>>>>> particular resource. If auto-completion is modified to be able to
>>>>> search
>>>>> by name for resource but inserting ids into search string it should
>>>>> make
>>>>> it user-friendly. E.g.
>>>>>
>>>>> filter/search on hosts: "hostgroup.id = HG"
>>>>> auto-completion: "1 (HG1)", "2 (HG2)"
>>>>> When you select "1 (HG1)" then search string would complete to
>>>>> "hostgroup.id = 1" and it would use id for searching.
>>>>>
>>>>> Would be something like this possible?
>>>>
>>>> Perhaps add unchanging katello-style labels to objects? Labels have
>>>> stricter syntax requirements than names do in katello. For example, an
>>>> organization can be named "ビッグ・ビジネス" with a label of "big_business".
>>>> Search string would complete to "organization.label = big_business".
>>>
>>> Well the problem is with renaming. So we'd end up in a situation, that
>>> there would be organization with name "Small business" labeled
>>> "big_business" after someone renamed it?
>>>
>>> I'd like to use id to identify. What Petr suggests has only one drawback,
>>> users wouldn't know what such scoped_search string means. Maybe by editing
>>> it, autocompletion would display it again.
>>
>> the nice thing about scope search, is that its just a scope, meaning
>> you can join it to any existing scope. for example:
>>
>> Orgs.my_orgs.scoped_search(params).
>>
>> Would that be good enough?
>
> For organizations yes, but the same problem with the naming exists for e.g.
> hostgroups. Organizations are to be set outside of scoped search strings. But
> we must point to specific hostgroup. Id seems the best but users won't
> understand it so we should be able to interpret it using current name value
> somehow.
>

I think we can broke this down to 2 problems.
A) How can user input ids easily?
B) How to show existing or edited searches so user can see what the ids
represents.

Solutions:

A) As mentioned before, by adding description string to auto-completion.
e.g.
1 (HG small)
4 (HG big)

B.1) Enrich scoped_search syntax to be able to insert inline comments
which would be used for inserting the names.

host search: hostgroup.id = 1 HG small OR domain.id = 3 foreman.org

Where is a comment. Comments would not be stored in DB in Filter
but inserted dynamically for each viewing by user. Comments would be
stripped before saving to DB.

B.2) Show only ids in the search string: "hostgroup.id = 1 OR domain.id
= 3" and display meaning of the ids elsewhere on the page. It could be by:
B.2a) tool-tip with name over each id
B.2b) add table of ids translation to resource names
B.2c) repeat search-string underneath input with ids switched for names
It should be reloaded after each search-string change.

Personally I like B.1 and B.2a.

··· On 28.11.13 10:22, Marek Hulan wrote: > On Thursday 28 of November 2013 10:40:13 Ohad Levy wrote: >> On Thu, Nov 28, 2013 at 10:38 AM, Marek Hulan wrote: >>> On Wednesday 27 of November 2013 13:58:19 Tom McKay wrote: >>>> ----- Original Message ----- >>>>> On 26.11.13 17:49, Justin Sherrill wrote: >>>>>> On 11/22/2013 11:30 AM, Marek Hulan wrote:

Ohad

  • Katello has a pre-built read-only role created so that admins can
    give
    an auditing type user read-access to everything on the satellite.
    Given
    the number of permissions that would need to be granted within
    foreman,
    I think this could be useful here too. Within katello we were
    tracking
    whether a particular permission was a read permission or not, and
    generated a role with all the ‘read’ permissions. None of this
    needs
    to be done now, but some discussion/thought on how we could do it
    would
    be useful. Mainly we need someway to know which permissions are
    read-only or not.

Yes, we’ve talked about this shortly. There should be a default roles
(admin, read-only) created for each organization assuming that Filters
are scoped by taxonomy which is determining in which Organizations is
the filter valid. Meaning each Organization has its own Admin and
Read-only role but not preventing creation of global Admin or global
Read-only role.

  • This assumes that katello will need to add scoped search to all
    models
    that need permissions.

I would vote for it. It has benefits:

  • unified UX with searching over Katello and Foreman
  • Katello would not have its own system for full-text search
  • we could elastic-search usage only for errata and packages (big-ish
    data).
  • we would not need to keep ES index up to date for other

resources - simplification of orchestration, no need to deal with
situations where index is inconsistent, only one storage of data (DB)

  • We need to make sure that the plugin registration continues to work
    (and allows new resource types to be added in addition to
    permissions).

  • To highlight a difference between katello and foreman, accessible
    orgs
    are assigned apart from roles (In katello accessible orgs were
    derived
    from a users roles). I think this is okay, just wanted to highlight
    the
    difference.

  • One main use case with organizations is:

    • I should be able to create a user and assign him to Organization
      A

and give him some role.

I think possible. The user would be given Admin role which is limited
to
OrgA which is achieved by assigning Admin-role’s Filter to OrgA (using
taxonomy). The admin-role does not apply outside of assigned
organizations.

* That user should be able to create other users and create &
assign

roles that only have access to things in Organization A.

I think possible. Let user A be the one assigning roles to
user/user-group B. Options:

  1. Users are not allowed to configure filters on roles unless they have
    another permission for that (reserved for organization-admins, who
    could
    only edit filters assigned to the same organization). Then A can only
    assign to B roles he is in.

  2. Users are allowed to configure filters on roles. Then filters need
    to
    be limited so A cannot create filter for B with searched_scope where
    its
    result is super-set of A’s searched_scope of his filter.
    2.1) This can be achieved by only allowing A to create filters only for
    permissions where A does not have any searched_scope
    2.2) or by chaining A’s searched_scope with the one being assigned to B
    with ‘AND’ which ensures that newly created filter is always generating
    a sub-set.

I think 1) is simple, straightforward and sufficient for our
requirements. 2) could be added if there is a need for it.

From talking to ohad previously this was possible, I just want to

validate that it still would be possible (I believe it is). This is
the
"Organization" admin use case, where by i’m creating an admin that
can
manage things in a particular organization.

Thanks,

-Justin

Petr


You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Marek


You received this message because you are subscribed to the Google Groups
"foreman-dev" group. To unsubscribe from this group and stop receiving
emails from it, send an email to
foreman-dev+unsubscribe@googlegroups.com. For more options, visit
https://groups.google.com/groups/opt_out.

for some background and history on object labels you can go here:

https://fedorahosted.org/katello/wiki/ObjectLabelDesign

the requirements and need for human readable ASCII restricted
identifiers hasn't changed for Katello so we still need to maintain them
for objects that get populated in Pulp and Candlepin. It definitely
introduces some pain for the user so you want to limit what objects you
add this field to.

Mike

··· On 12/02/2013 05:23 AM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Marek Hulan" >> To: foreman-dev@googlegroups.com >> Sent: Thursday, November 28, 2013 3:38:28 AM >> Subject: Re: [foreman-dev] Katello and Foreman permissions systems >> >> On Wednesday 27 of November 2013 13:58:19 Tom McKay wrote: >>> ----- Original Message ----- >>> >>>> From: "Petr Chalupa" >>>> To: foreman-dev@googlegroups.com >>>> Sent: Wednesday, November 27, 2013 4:40:43 AM >>>> Subject: Re: [foreman-dev] Katello and Foreman permissions systems >>>> >>>> >>>> >>>> On 26.11.13 17:49, Justin Sherrill wrote: >>>> >>>>> On 11/22/2013 11:30 AM, Marek Hulan wrote: >>>>> >>>>>> Hi all >>>>>> >>>>>> >>>>>> >>>>>> During work on Foreman authorization code we have good chance to >>>>>> modify it for >>>>>> Katello needs. I'd like to invite anyone interested in authorization >>>>>> system of >>>>>> Foreman and Katello to a short session on Tue 26th at 9:30 EST. It >>>>>> shouldn't >>>>>> take longer that 30 minutes. I'd like to investigate whether current >>>>>> Foreman >>>>>> model is good enough for Katello (according to last meeting in Brno, >>>>>> it should >>>>>> be) and find out what other features we may add. >>>>>> >>>>>> >>>>>> >>>>>> I'll start with description of current Foreman model and planned (but >>>>>> not >>>>>> final) changes. Then the discussion should follow. >>>>>> >>>>>> >>>>>> >>>>>> I'll send a hangout link before start via email and irc >>>>>> #theforeman-dev >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Marek >>>>>> >>>>>> >>>>>> >>>>> Good Job Marek! This looks much better than the previous permission >>>>> system and should fit katello's use cases pretty well. >>>>> >>>>> >>>>> >>>>> I did have a couple of comments from a katello perspective: >>>>> >>>>> >>>>> >>>>> * As I mentioned in the demo, I think it's important for users to be >>>>> able to physically select specific resources as well as use the scoped >>>>> search syntax. Not only is it easier for beginner users, but it would >>>>> work across renames without the user having to lookup and type in Ids. >>>>> This could be backed by scoped search for sure. >>>> >>>> >>>> Good point. I think it could be solved by forcing (or by displaying >>>> warning to) users to use only ids instead of names for searching for >>>> particular resource. If auto-completion is modified to be able to search >>>> by name for resource but inserting ids into search string it should make >>>> it user-friendly. E.g. >>>> >>>> filter/search on hosts: "hostgroup.id = HG" >>>> auto-completion: "1 (HG1)", "2 (HG2)" >>>> When you select "1 (HG1)" then search string would complete to >>>> "hostgroup.id = 1" and it would use id for searching. >>>> >>>> Would be something like this possible? >>> >>> >>> Perhaps add unchanging katello-style labels to objects? Labels have >>> stricter >>> syntax requirements than names do in katello. For example, an organization >>> can be named "ビッグ・ビジネス" with a label of "big_business". Search string would >>> complete to "organization.label = big_business". >> >> Well the problem is with renaming. So we'd end up in a situation, that there >> would be organization with name "Small business" labeled "big_business" after >> someone renamed it? > > Correct, there is a chance that the editable name can stray from the uneditable label. (That said, most objects could also allow editing of the label without issues, if desired.) > > The other benefit of labels is that they are more readily usable on the CLI. > > % hammer organization info --name ビッグ・ビジネス <-- error > % hammer organization info --id 12 > vs. > % hammer organization info --id big_business > > I know product management has been asking for a reduction in the need to specify (or even see) internal IDs. I'll let them comment directly. >


Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248

In this thread I feel we ve way over discussed about the model and adding search to dynamically allocated permissions. I may be wrong but I believe the more common way a user will create permissions on resources is via selecting them manually as stated by Justin. As long as there is a reasonable enough interface to handle this basic case, I am ok with the proposed model.

Partha

··· > > > > On 26.11.13 17:49, Justin Sherrill wrote: > > > > > > > > > > I did have a couple of comments from a katello perspective: > > > > > > > > > > > > > > > > > > > > * As I mentioned in the demo, I think it's important for users to be > > > > > able to physically select specific resources as well as use the > > > > > scoped search syntax. Not only is it easier for beginner users, but it > > > > > would work across renames without the user having to lookup and type in Ids.

I'm not happy with either of ways. If I had to choose, I'd go with B.2c), some
kind of a live preview. I like the idea of simplified form where you can select
resources by checkboxes (or similarly). I know you limit scoped_search but it
will work for most cases. You could still let the filter be editable by
advanced users by specifying scoper_search string. As long as users don't
modify the filter manually they can use the checkbox form.

Also I think we can solve this later when we have some feedback after it gets
to nightly. Until that we can provide just a way to specify the scoped_search
string.

··· On Monday 02 of December 2013 10:10:17 Petr Chalupa wrote: > On 28.11.13 10:22, Marek Hulan wrote: > > On Thursday 28 of November 2013 10:40:13 Ohad Levy wrote: > >> On Thu, Nov 28, 2013 at 10:38 AM, Marek Hulan wrote: > >>> On Wednesday 27 of November 2013 13:58:19 Tom McKay wrote: > >>>> ----- Original Message ----- > >>>> > >>>>> From: "Petr Chalupa" > >>>>> To: foreman-dev@googlegroups.com > >>>>> Sent: Wednesday, November 27, 2013 4:40:43 AM > >>>>> Subject: Re: [foreman-dev] Katello and Foreman permissions systems > >>>>> > >>>>> On 26.11.13 17:49, Justin Sherrill wrote: > >>>>>> On 11/22/2013 11:30 AM, Marek Hulan wrote: > >>>>>>> Hi all > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> During work on Foreman authorization code we have good chance to > >>>>>>> modify it for > >>>>>>> Katello needs. I'd like to invite anyone interested in authorization > >>>>>>> system of > >>>>>>> Foreman and Katello to a short session on Tue 26th at 9:30 EST. It > >>>>>>> shouldn't > >>>>>>> take longer that 30 minutes. I'd like to investigate whether current > >>>>>>> Foreman > >>>>>>> model is good enough for Katello (according to last meeting in Brno, > >>>>>>> it should > >>>>>>> be) and find out what other features we may add. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I'll start with description of current Foreman model and planned > >>>>>>> (but > >>>>>>> not > >>>>>>> final) changes. Then the discussion should follow. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I'll send a hangout link before start via email and irc > >>>>>>> #theforeman-dev > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Marek > >>>>>> > >>>>>> Good Job Marek! This looks much better than the previous permission > >>>>>> system and should fit katello's use cases pretty well. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I did have a couple of comments from a katello perspective: > >>>>>> > >>>>>> > >>>>>> > >>>>>> * As I mentioned in the demo, I think it's important for users to be > >>>>>> able to physically select specific resources as well as use the > >>>>>> scoped > >>>>>> search syntax. Not only is it easier for beginner users, but it > >>>>>> would > >>>>>> work across renames without the user having to lookup and type in > >>>>>> Ids. > >>>>>> This could be backed by scoped search for sure. > >>>>> > >>>>> Good point. I think it could be solved by forcing (or by displaying > >>>>> warning to) users to use only ids instead of names for searching for > >>>>> particular resource. If auto-completion is modified to be able to > >>>>> search > >>>>> by name for resource but inserting ids into search string it should > >>>>> make > >>>>> it user-friendly. E.g. > >>>>> > >>>>> filter/search on hosts: "hostgroup.id = HG" > >>>>> auto-completion: "1 (HG1)", "2 (HG2)" > >>>>> When you select "1 (HG1)" then search string would complete to > >>>>> "hostgroup.id = 1" and it would use id for searching. > >>>>> > >>>>> Would be something like this possible? > >>>> > >>>> Perhaps add unchanging katello-style labels to objects? Labels have > >>>> stricter syntax requirements than names do in katello. For example, an > >>>> organization can be named "ビッグ・ビジネス" with a label of "big_business". > >>>> Search string would complete to "organization.label = big_business". > >>> > >>> Well the problem is with renaming. So we'd end up in a situation, that > >>> there would be organization with name "Small business" labeled > >>> "big_business" after someone renamed it? > >>> > >>> I'd like to use id to identify. What Petr suggests has only one > >>> drawback, > >>> users wouldn't know what such scoped_search string means. Maybe by > >>> editing > >>> it, autocompletion would display it again. > >> > >> the nice thing about scope search, is that its just a scope, meaning > >> you can join it to any existing scope. for example: > >> > >> Orgs.my_orgs.scoped_search(params). > >> > >> Would that be good enough? > > > > For organizations yes, but the same problem with the naming exists for > > e.g. > > hostgroups. Organizations are to be set outside of scoped search strings. > > But we must point to specific hostgroup. Id seems the best but users > > won't understand it so we should be able to interpret it using current > > name value somehow. > > I think we can broke this down to 2 problems. > A) How can user input ids easily? > B) How to show existing or edited searches so user can see what the ids > represents. > > Solutions: > > A) As mentioned before, by adding description string to auto-completion. > e.g. > 1 (HG small) > 4 (HG big) > > B.1) Enrich scoped_search syntax to be able to insert inline comments > which would be used for inserting the names. > > host search: hostgroup.id = 1 *HG small* OR domain.id = 3 *foreman.org* > > Where *...* is a comment. Comments would not be stored in DB in Filter > but inserted dynamically for each viewing by user. Comments would be > stripped before saving to DB. > > B.2) Show only ids in the search string: "hostgroup.id = 1 OR domain.id > = 3" and display meaning of the ids elsewhere on the page. It could be by: > B.2a) tool-tip with name over each id > B.2b) add table of ids translation to resource names > B.2c) repeat search-string underneath input with ids switched for names > It should be reloaded after each search-string change. > > Personally I like B.1 and B.2a.


Marek

Ohad

  • Katello has a pre-built read-only role created so that admins can
    give
    an auditing type user read-access to everything on the satellite.
    Given
    the number of permissions that would need to be granted within
    foreman,
    I think this could be useful here too. Within katello we were
    tracking
    whether a particular permission was a read permission or not, and
    generated a role with all the ‘read’ permissions. None of this
    needs
    to be done now, but some discussion/thought on how we could do it
    would
    be useful. Mainly we need someway to know which permissions are
    read-only or not.

Yes, we’ve talked about this shortly. There should be a default roles
(admin, read-only) created for each organization assuming that Filters
are scoped by taxonomy which is determining in which Organizations is
the filter valid. Meaning each Organization has its own Admin and
Read-only role but not preventing creation of global Admin or global
Read-only role.

  • This assumes that katello will need to add scoped search to all
    models
    that need permissions.

I would vote for it. It has benefits:

  • unified UX with searching over Katello and Foreman
  • Katello would not have its own system for full-text search
  • we could elastic-search usage only for errata and packages (big-ish
    data).
  • we would not need to keep ES index up to date for other

resources - simplification of orchestration, no need to deal with
situations where index is inconsistent, only one storage of data (DB)

  • We need to make sure that the plugin registration continues to work
    (and allows new resource types to be added in addition to
    permissions).

  • To highlight a difference between katello and foreman, accessible
    orgs
    are assigned apart from roles (In katello accessible orgs were
    derived
    from a users roles). I think this is okay, just wanted to highlight
    the
    difference.

  • One main use case with organizations is:

    • I should be able to create a user and assign him to
      Organization
      A

and give him some role.

I think possible. The user would be given Admin role which is limited
to
OrgA which is achieved by assigning Admin-role’s Filter to OrgA (using
taxonomy). The admin-role does not apply outside of assigned
organizations.

* That user should be able to create other users and create &
assign

roles that only have access to things in Organization A.

I think possible. Let user A be the one assigning roles to
user/user-group B. Options:

  1. Users are not allowed to configure filters on roles unless they
    have
    another permission for that (reserved for organization-admins, who
    could
    only edit filters assigned to the same organization). Then A can only
    assign to B roles he is in.

  2. Users are allowed to configure filters on roles. Then filters need
    to
    be limited so A cannot create filter for B with searched_scope where
    its
    result is super-set of A’s searched_scope of his filter.
    2.1) This can be achieved by only allowing A to create filters only
    for
    permissions where A does not have any searched_scope
    2.2) or by chaining A’s searched_scope with the one being assigned to
    B
    with ‘AND’ which ensures that newly created filter is always
    generating
    a sub-set.

I think 1) is simple, straightforward and sufficient for our
requirements. 2) could be added if there is a need for it.

From talking to ohad previously this was possible, I just want to

validate that it still would be possible (I believe it is). This is
the
"Organization" admin use case, where by i’m creating an admin that
can
manage things in a particular organization.

Thanks,

-Justin

Petr


You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Marek


You received this message because you are subscribed to the Google
Groups
"foreman-dev" group. To unsubscribe from this group and stop receiving
emails from it, send an email to
foreman-dev+unsubscribe@googlegroups.com. For more options, visit
https://groups.google.com/groups/opt_out.

Just a few notes:

  • Scoped_search filters will be usually only used by admins, common user
    will be only assigning by-admin-predefined roles to other users which
    will be simple. I think we can expect that an admin knows Foreman better.
  • Scoped_search filters cannot be omitted otherwise it would implement
    only a subset of current feature set.
  • To add "physical selecting of specific resources" will generate more
    work and make data model more complicated unless it is translated to
    scoped_search filter when saving.
··· On 02.12.13 20:11, Partha Aji wrote: >>>>> On 26.11.13 17:49, Justin Sherrill wrote: >>>>>> >>>>>> I did have a couple of comments from a katello perspective: >>>>>> >>>>>> >>>>>> >>>>>> * As I mentioned in the demo, I think it's important for users to be >>>>>> able to physically select specific resources as well as use the >>>>>> scoped search syntax. Not only is it easier for beginner users, but it >>>>>> would work across renames without the user having to lookup and type in Ids. > > In this thread I feel we ve way over discussed about the model and adding search to dynamically allocated permissions. I may be wrong but I believe the more common way a user will create permissions on resources is via selecting them manually as stated by Justin. As long as there is a reasonable enough interface to handle this basic case, I am ok with the proposed model. > > Partha >

>>>>>>
>>>>>>> From: "Petr Chalupa" <pchalupa@redhat.com>
>>>>>>> To: foreman-dev@googlegroups.com
>>>>>>> Sent: Wednesday, November 27, 2013 4:40:43 AM
>>>>>>> Subject: Re: [foreman-dev] Katello and Foreman permissions systems
>>>>>>>
>>>>>>>>> Hi all
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> During work on Foreman authorization code we have good chance to
>>>>>>>>> modify it for
>>>>>>>>> Katello needs. I'd like to invite anyone interested in authorization
>>>>>>>>> system of
>>>>>>>>> Foreman and Katello to a short session on Tue 26th at 9:30 EST. It
>>>>>>>>> shouldn't
>>>>>>>>> take longer that 30 minutes. I'd like to investigate whether current
>>>>>>>>> Foreman
>>>>>>>>> model is good enough for Katello (according to last meeting in Brno,
>>>>>>>>> it should
>>>>>>>>> be) and find out what other features we may add.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'll start with description of current Foreman model and planned
>>>>>>>>> (but
>>>>>>>>> not
>>>>>>>>> final) changes. Then the discussion should follow.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'll send a hangout link before start via email and irc
>>>>>>>>> #theforeman-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> –
>>>>>>>>> Marek
>>>>>>>>
>>>>>>>> Good Job Marek! This looks much better than the previous permission
>>>>>>>> system and should fit katello's use cases pretty well.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I did have a couple of comments from a katello perspective:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> * As I mentioned in the demo, I think it's important for users to be
>>>>>>>> able to physically select specific resources as well as use the
>>>>>>>> scoped
>>>>>>>> search syntax. Not only is it easier for beginner users, but it
>>>>>>>> would
>>>>>>>> work across renames without the user having to lookup and type in
>>>>>>>> Ids.
>>>>>>>> This could be backed by scoped search for sure.
>>>>>>>
>>>>>>> Good point. I think it could be solved by forcing (or by displaying
>>>>>>> warning to) users to use only ids instead of names for searching for
>>>>>>> particular resource. If auto-completion is modified to be able to
>>>>>>> search
>>>>>>> by name for resource but inserting ids into search string it should
>>>>>>> make
>>>>>>> it user-friendly. E.g.
>>>>>>>
>>>>>>> filter/search on hosts: "hostgroup.id = HG"
>>>>>>> auto-completion: "1 (HG1)", "2 (HG2)"
>>>>>>> When you select "1 (HG1)" then search string would complete to
>>>>>>> "hostgroup.id = 1" and it would use id for searching.
>>>>>>>
>>>>>>> Would be something like this possible?
>>>>>>
>>>>>> Perhaps add unchanging katello-style labels to objects? Labels have
>>>>>> stricter syntax requirements than names do in katello. For example, an
>>>>>> organization can be named "ビッグ・ビジネス" with a label of "big_business".
>>>>>> Search string would complete to "organization.label = big_business".
>>>>>
>>>>> Well the problem is with renaming. So we'd end up in a situation, that
>>>>> there would be organization with name "Small business" labeled
>>>>> "big_business" after someone renamed it?
>>>>>
>>>>> I'd like to use id to identify. What Petr suggests has only one
>>>>> drawback,
>>>>> users wouldn't know what such scoped_search string means. Maybe by
>>>>> editing
>>>>> it, autocompletion would display it again.
>>>>
>>>> the nice thing about scope search, is that its just a scope, meaning
>>>> you can join it to any existing scope. for example:
>>>>
>>>> Orgs.my_orgs.scoped_search(params).
>>>>
>>>> Would that be good enough?
>>>
>>> For organizations yes, but the same problem with the naming exists for
>>> e.g.
>>> hostgroups. Organizations are to be set outside of scoped search strings.
>>> But we must point to specific hostgroup. Id seems the best but users
>>> won't understand it so we should be able to interpret it using current
>>> name value somehow.
>>
>> I think we can broke this down to 2 problems.
>> A) How can user input ids easily?
>> B) How to show existing or edited searches so user can see what the ids
>> represents.
>>
>> Solutions:
>>
>> A) As mentioned before, by adding description string to auto-completion.
>> e.g.
>> 1 (HG small)
>> 4 (HG big)
>>
>> B.1) Enrich scoped_search syntax to be able to insert inline comments
>> which would be used for inserting the names.
>>
>> host search: hostgroup.id = 1 HG small OR domain.id = 3 foreman.org
>>
>> Where is a comment. Comments would not be stored in DB in Filter
>> but inserted dynamically for each viewing by user. Comments would be
>> stripped before saving to DB.
>>
>> B.2) Show only ids in the search string: "hostgroup.id = 1 OR domain.id
>> = 3" and display meaning of the ids elsewhere on the page. It could be by:
>> B.2a) tool-tip with name over each id
>> B.2b) add table of ids translation to resource names
>> B.2c) repeat search-string underneath input with ids switched for names
>> It should be reloaded after each search-string change.
>>
>> Personally I like B.1 and B.2a.
>
> I'm not happy with either of ways. If I had to choose, I'd go with B.2c), some
> kind of a live preview. I like the idea of simplified form where you can select
> resources by checkboxes (or similarly). I know you limit scoped_search but it
> will work for most cases. You could still let the filter be editable by
> advanced users by specifying scoper_search string. As long as users don't
> modify the filter manually they can use the checkbox form.
>
> Also I think we can solve this later when we have some feedback after it gets
> to nightly. Until that we can provide just a way to specify the scoped_search
> string.

+1 for simple implementation first, better UI later

··· On 03.12.13 8:50, Marek Hulan wrote: > On Monday 02 of December 2013 10:10:17 Petr Chalupa wrote: >> On 28.11.13 10:22, Marek Hulan wrote: >>> On Thursday 28 of November 2013 10:40:13 Ohad Levy wrote: >>>> On Thu, Nov 28, 2013 at 10:38 AM, Marek Hulan wrote: >>>>> On Wednesday 27 of November 2013 13:58:19 Tom McKay wrote: >>>>>> ----- Original Message ----- >>>>>>> On 26.11.13 17:49, Justin Sherrill wrote: >>>>>>>> On 11/22/2013 11:30 AM, Marek Hulan wrote:


Marek

Ohad

  • Katello has a pre-built read-only role created so that admins can
    give
    an auditing type user read-access to everything on the satellite.
    Given
    the number of permissions that would need to be granted within
    foreman,
    I think this could be useful here too. Within katello we were
    tracking
    whether a particular permission was a read permission or not, and
    generated a role with all the ‘read’ permissions. None of this
    needs
    to be done now, but some discussion/thought on how we could do it
    would
    be useful. Mainly we need someway to know which permissions are
    read-only or not.

Yes, we’ve talked about this shortly. There should be a default roles
(admin, read-only) created for each organization assuming that Filters
are scoped by taxonomy which is determining in which Organizations is
the filter valid. Meaning each Organization has its own Admin and
Read-only role but not preventing creation of global Admin or global
Read-only role.

  • This assumes that katello will need to add scoped search to all
    models
    that need permissions.

I would vote for it. It has benefits:

  • unified UX with searching over Katello and Foreman
  • Katello would not have its own system for full-text search
  • we could elastic-search usage only for errata and packages (big-ish
    data).
  • we would not need to keep ES index up to date for other

resources - simplification of orchestration, no need to deal with
situations where index is inconsistent, only one storage of data (DB)

  • We need to make sure that the plugin registration continues to work
    (and allows new resource types to be added in addition to
    permissions).

  • To highlight a difference between katello and foreman, accessible
    orgs
    are assigned apart from roles (In katello accessible orgs were
    derived
    from a users roles). I think this is okay, just wanted to highlight
    the
    difference.

  • One main use case with organizations is:

    • I should be able to create a user and assign him to
      Organization
      A

and give him some role.

I think possible. The user would be given Admin role which is limited
to
OrgA which is achieved by assigning Admin-role’s Filter to OrgA (using
taxonomy). The admin-role does not apply outside of assigned
organizations.

 * That user should be able to create other users and create &
 assign

roles that only have access to things in Organization A.

I think possible. Let user A be the one assigning roles to
user/user-group B. Options:

  1. Users are not allowed to configure filters on roles unless they
    have
    another permission for that (reserved for organization-admins, who
    could
    only edit filters assigned to the same organization). Then A can only
    assign to B roles he is in.

  2. Users are allowed to configure filters on roles. Then filters need
    to
    be limited so A cannot create filter for B with searched_scope where
    its
    result is super-set of A’s searched_scope of his filter.
    2.1) This can be achieved by only allowing A to create filters only
    for
    permissions where A does not have any searched_scope
    2.2) or by chaining A’s searched_scope with the one being assigned to
    B
    with ‘AND’ which ensures that newly created filter is always
    generating
    a sub-set.

I think 1) is simple, straightforward and sufficient for our
requirements. 2) could be added if there is a need for it.

From talking to ohad previously this was possible, I just want to

validate that it still would be possible (I believe it is). This is
the
"Organization" admin use case, where by i’m creating an admin that
can
manage things in a particular organization.

Thanks,

-Justin

Petr


You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Marek


You received this message because you are subscribed to the Google
Groups
"foreman-dev" group. To unsubscribe from this group and stop receiving
emails from it, send an email to
foreman-dev+unsubscribe@googlegroups.com. For more options, visit
https://groups.google.com/groups/opt_out.