>> 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:
-
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.
-
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:
