Hi,
we are looking into reworking the users filters (when editing a user, one
can apply filters to the hosts he will be able to act upon).
the main goal of this rework, is simply to:
- optimize / clean up the code.
- apply filters on the group level too.
- simplify things before we start adding locations / org units / tenants
into foreman.
when looking at the filters, I kinda asked my self, if it wont be easier
simply to define a search condition (or a bookmark) instead of a multiple
checkboxes etc.
so, for example, instead of saying:
manage own hosts
AND / OR
manage hosts in domain x.y
…
we could simply use a search condition:
domain = x.y or hostgroup = z and …
What do you guys think?
Ohad
> Hi,
>
> we are looking into reworking the users filters (when editing a
> user, one can apply filters to the hosts he will be able to act
> upon).
>
> the main goal of this rework, is simply to: 1. optimize / clean up
> the code. 2. apply filters on the group level too. 3. simplify
> things before we start adding locations / org units / tenants into
> foreman.
As Foreman gets the ability to manage more complex environments, we
need to consider how User Roles fit into that. At present, we cannot
give a user differing permissions for different groups of hosts. It's
"all these permissions" on "exactly these hosts" - the user doesn't
even see the other hosts.
We need to be able to say a user can (for example):
Fully edit host.foo.com
Edit parameters only on hostgroup foo
View hosts/reports in hostgroup bar
Cannot see host puppetmaster
Right now I want to give something like this to my Tier2 - so they can
play with their own test hosts, fix simple problems in production
machines, and escalate any issues they see in other hosts because they
won't have the permissions to change it.
I realise that's a fairly complex change, but I think it's a goal to
work to.
> we could simply use a search condition:
>
> domain = x.y or hostgroup = z and …
Sounds good. We could end up writing some complex and long queries
here, so at least make the textbox bigger 
Finally, someone (bgupa?) suggested using User Groups for everything,
and Users just belong to a Group. I think we should do that - right
now I have to do a lot of manually permissions editing for new Users,
which gets really irritating.
Cheers,
Greg
···
On 16/07/12 08:14, Ohad Levy wrote:
>
> Hi,
>
> we are looking into reworking the users filters (when editing a user, one
> can apply filters to the hosts he will be able to act upon).
>
> the main goal of this rework, is simply to:
> 1. optimize / clean up the code.
> 2. apply filters on the group level too.
>
Is this apply filters on the "group of users" level too. If so great.
> 3. simplify things before we start adding locations / org units / tenants
> into foreman.
>
> when looking at the filters, I kinda asked my self, if it wont be easier
> simply to define a search condition (or a bookmark) instead of a multiple
> checkboxes etc.
> so, for example, instead of saying:
>
> manage own hosts
> AND / OR
> manage hosts in domain x.y
> …
>
> we could simply use a search condition:
>
> domain = x.y or hostgroup = z and …
>
> What do you guys think?
>
>
Possibly unrelated is that we are starting to have hosts interact with
foreman quite often now.
e.g hosts adding themselves into foreman via curl call or something.
Up to now this has been done creating a special account in forman but
identifying with
with host certificates or kerberos at apache can be done of course. foreman
would need
to know that once a host entity is authenticated then it can edit its own
entry in foreman
or whatever.
···
On Monday, 16 July 2012 09:14:43 UTC+2, ohadlevy wrote:
Ohad
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > Hi,
> >
> > we are looking into reworking the users filters (when editing a
> > user, one can apply filters to the hosts he will be able to act
> > upon).
> >
> > the main goal of this rework, is simply to: 1. optimize / clean up
> > the code. 2. apply filters on the group level too. 3. simplify
> > things before we start adding locations / org units / tenants into
> > foreman.
>
> As Foreman gets the ability to manage more complex environments, we
> need to consider how User Roles fit into that. At present, we cannot
> give a user differing permissions for different groups of hosts. It's
> "all these permissions" on "exactly these hosts" - the user doesn't
> even see the other hosts.
>
> We need to be able to say a user can (for example):
>
> Fully edit host.foo.com
> Edit parameters only on hostgroup foo
> View hosts/reports in hostgroup bar
> Cannot see host puppetmaster
>
> Right now I want to give something like this to my Tier2 - so they can
> play with their own test hosts, fix simple problems in production
> machines, and escalate any issues they see in other hosts because they
> won't have the permissions to change it.
>
> I realise that's a fairly complex change, but I think it's a goal to
> work to.
>
so if I got that right, you want to move the filter per user/group into the
mapped roles?
>
> > we could simply use a search condition:
> >
> > domain = x.y or hostgroup = z and …
>
> Sounds good. We could end up writing some complex and long queries
> here, so at least make the textbox bigger
>
> Finally, someone (bgupa?) suggested using User Groups for everything,
> and Users just belong to a Group. I think we should do that - right
> now I have to do a lot of manually permissions editing for new Users,
> which gets really irritating.
>
yeah, thats part of the motivation.
···
On Mon, Jul 16, 2012 at 1:12 PM, Greg Sutcliffe wrote:
> On 16/07/12 08:14, Ohad Levy wrote:
Cheers,
Greg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAD6R4ACgkQ8O7RN8oK65OagwCfRnA1cXZcEsipYxTFbtDOTIMQ
4t8AoKSa48mB5caiVWTqQ3scEH8m4zss
=xZCQ
-----END PGP SIGNATURE-----
>>
>> Hi,
>>
>> we are looking into reworking the users filters (when editing a user, one
>> can apply filters to the hosts he will be able to act upon).
>>
>> the main goal of this rework, is simply to:
>> 1. optimize / clean up the code.
>> 2. apply filters on the group level too.
>>
>
> Is this apply filters on the "group of users" level too. If so great.
>
yep, that's one of the main motivations.
>
>
>> 3. simplify things before we start adding locations / org units / tenants
>> into foreman.
>>
>> when looking at the filters, I kinda asked my self, if it wont be easier
>> simply to define a search condition (or a bookmark) instead of a multiple
>> checkboxes etc.
>> so, for example, instead of saying:
>>
>> manage own hosts
>> AND / OR
>> manage hosts in domain x.y
>> …
>>
>> we could simply use a search condition:
>>
>> domain = x.y or hostgroup = z and …
>>
>> What do you guys think?
>>
>>
> Possibly unrelated is that we are starting to have hosts interact with
> foreman quite often now.
> e.g hosts adding themselves into foreman via curl call or something.
>
interesting, care to share / provide more info?
>
> Up to now this has been done creating a special account in forman but
> identifying with
> with host certificates or kerberos at apache can be done of course.
> foreman would need
> to know that once a host entity is authenticated then it can edit its own
> entry in foreman
> or whatever.
>
there is a way to ask apache to authenticate, so you could delegate the
authentication (needs to be turned on in settings).
Ohad
···
On Tue, Jul 24, 2012 at 3:20 PM, Steve Traylen wrote:
> On Monday, 16 July 2012 09:14:43 UTC+2, ohadlevy wrote:
Ohad
Wouldnt you want group membership to come from LDAP/AD instead of Foreman?
– bk
···
On 07/16/2012 07:09 AM, Greg Sutcliffe wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 16/07/12 11:57, Ohad Levy wrote:
>>> so if I got that right, you want to move the filter per
>>> user/group into the mapped roles?
>
> Thinking about it (and given the UserGroup motivation), would it make
> more sense to allow a User to be a member of multiple UserGroups? Then
> all the existing logic applies to a UserGroup, but I can satisfy my
> requirements by creating:
>
> UserGroup: Foo-admin
> Full rights on Hosts in Hostgroup Foo
> UserGroup: Bar-viewer
> View-only rights on Hosts in Hostgroup Bar
> User: Jim
> Member of: Foo-admin, Bar-viewer
>
> Does that make more sense?
>
> While we're generating requirements, I think it also makes sense to be
> able to say what Groups an on-the-fly-created User should be a member
> of. Perhaps in the Settings menu?
I think that it's important for the groups to come from LDAP in some cases,
but having Foreman be able to act as both the single source of internal
authentication and utilize remote auth (like LDAP, AD, or SAML) is key.
Having LDAP as a requirement to use authentication in Foreman will likely
serve as a barrier to entry, though.
···
On Mon, Jul 16, 2012 at 10:03 AM, Bryan Kearney wrote:
On 07/16/2012 07:09 AM, Greg Sutcliffe wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 16/07/12 11:57, Ohad Levy wrote:
so if I got that right, you want to move the filter per
user/group into the mapped roles?
Thinking about it (and given the UserGroup motivation), would it make
more sense to allow a User to be a member of multiple UserGroups? Then
all the existing logic applies to a UserGroup, but I can satisfy my
requirements by creating:
UserGroup: Foo-admin
Full rights on Hosts in Hostgroup Foo
UserGroup: Bar-viewer
View-only rights on Hosts in Hostgroup Bar
User: Jim
Member of: Foo-admin, Bar-viewer
Does that make more sense?
While we’re generating requirements, I think it also makes sense to be
able to say what Groups an on-the-fly-created User should be a member
of. Perhaps in the Settings menu?
Wouldnt you want group membership to come from LDAP/AD instead of Foreman?
– bk
Thinking about it (and given the UserGroup motivation), would it make
more sense to allow a User to be a member of multiple UserGroups? Then
all the existing logic applies to a UserGroup, but I can satisfy my
requirements by creating:
UserGroup: Foo-admin
Full rights on Hosts in Hostgroup Foo
UserGroup: Bar-viewer
View-only rights on Hosts in Hostgroup Bar
User: Jim
Member of: Foo-admin, Bar-viewer
Does that make more sense?
While we're generating requirements, I think it also makes sense to be
able to say what Groups an on-the-fly-created User should be a member
of. Perhaps in the Settings menu?
Greg
···
On 16/07/12 11:57, Ohad Levy wrote:
>> so if I got that right, you want to move the filter per
>> user/group into the mapped roles?
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >> so if I got that right, you want to move the filter per
> >> user/group into the mapped roles?
>
> Thinking about it (and given the UserGroup motivation), would it make
> more sense to allow a User to be a member of multiple UserGroups? Then
> all the existing logic applies to a UserGroup, but I can satisfy my
> requirements by creating:
>
AFAIR, a user can belong to multiple groups today.
>
> UserGroup: Foo-admin
> Full rights on Hosts in Hostgroup Foo
> UserGroup: Bar-viewer
> View-only rights on Hosts in Hostgroup Bar
> User: Jim
> Member of: Foo-admin, Bar-viewer
>
> Does that make more sense?
>
> While we're generating requirements, I think it also makes sense to be
> able to say what Groups an on-the-fly-created User should be a member
> of. Perhaps in the Settings menu?
>
thats another feature request
···
On Mon, Jul 16, 2012 at 2:09 PM, Greg Sutcliffe wrote:
> On 16/07/12 11:57, Ohad Levy wrote:
Greg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAD9moACgkQ8O7RN8oK65OtTQCfdzNe0LHyOS4uFGBN/ssPe8iq
GVQAnjk1fEI29RNEfxRMTUqDtIKxjAfT
=TQEW
-----END PGP SIGNATURE-----
Agreed, optionally pulling more data from LDAP is a good idea if
you're using LDAP authentication. If you're not, you still might want
multi-group users and so on.
Optional is a key word too I think. Here, our LDAP is actually a
BindDN to an ActiveDirectory server, and the amount of groups it seems
to create is insane - I wouldn't want all of that in Foreman, but the
ability to pull in selected groups would be nice.
Greg
···
On 16/07/12 15:10, Sam Kottler wrote:
> I think that it's important for the groups to come from LDAP in
> some cases, but having Foreman be able to act as both the single
> source of internal authentication and utilize remote auth (like
> LDAP, AD, or SAML) is key. Having LDAP as a requirement to use
> authentication in Foreman will likely serve as a barrier to entry,
> though.
>> AFAIR, a user can belong to multiple groups today.
So it seems. Well, then I guess the proposed work covers my needs 
>> thats another feature request
Heh, you ask for input, you get input. One feature request coming up
Greg
···
On 16/07/12 12:12, Ohad Levy wrote:
