[katello-devel] ldap integration expected behavior with a 1:2 User:Group scenario.

Eric Sammons esammons at redhat.com
Wed Sep 5 18:05:31 UTC 2012


----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Justin Sherrill" <jsherril at redhat.com>
> > To: katello-devel at redhat.com
> > Sent: Wednesday, September 5, 2012 1:44:13 PM
> > Subject: Re: [katello-devel] ldap integration expected behavior
> > with a 1:2 User:Group scenario.
> > 
> > On 09/05/2012 01:31 PM, Eric Sammons wrote:
> > > I have a scenario where i have a user, lets call him user1, and
> > > user1 is a member of two LDAP groups; groupReadOnly and
> > > groupAdmin.  Yes this is odd but it could happen.  In Katello, I
> > > have setup ldap groups as follow:  groupReadOnly is a member of
> > > role Read Everything and groupAdmin is a member of the
> > > Administrator role.  In this setup, it appears that when user1
> > > logs in they will get the permissions of Administrator, if I did
> > > my ABCs correctly.
> > >
> > > Are there any plans to address this scenario, it may be that I
> > > want
> > > user1 to have Read Everything permissions and with the current
> > > behavior this would not be possible
> > Why would you put user1 in the groupAdmin ldap group and associate
> > with
> > the Administer role if you did not want to give user1 all
> > permissions
> > associated with that role?
> 
> I concur: If you assign roles by group and stuff a user in that
> group, they get the roles.

Ok I have modified my scenario, ldap group7 is in role Administrator and ldap group6 (which alphabetically comes before group7) is associated with Read Everything.  Testing this setup it appears I am wrong about the alphabetical order deal, thankfully so.  This does appear to be a cumulative behavior.

Thanks for clarifying and forcing me to go back and double check.

--Eric

> 
> > 
> > Roles in katello are additive.  So in the above scenario I would
> > fully
> > expect the user to be able to do everything that either the "Read
> > Everything" role and the "Administer" role can do together.
> > 
> > 
> > 
> > > as roles applied are based on the first ldap group returned that
> > > matches a role (ABCs).   This may be a matter of simply
> > > documenting the behavior so that users are aware they may need to
> > > establish specific LDAP groups to satisfy internal security
> > > compliance.  With that, there are at least 3 options...
> > >
> > > Solution 1: The LDAP admin would need to create a unique group,
> > > perhaps KatelloAdmin and KatelloReadEverything and then assign
> > > the
> > > appropriate users to that group. (Document)
> > >
> > > Solution 2: Katello could pull back all results and then apply
> > > policy (role) with least permission.
> > >
> > > Solution 3: Katello could pull back all results and then apply
> > > policy (role) with greatest permission.
> > Katello doesn't really have a way to determine which role has the
> > "Greatest permission" or "Least Permission".  I'm not sure that
> > there
> > is
> > a concrete way to do this.  You could have a role A with read on
> > FOO
> > and
> > write on BAR and role B with write on FOO and Read on BAR.  How
> > would
> > we
> > know which was 'greatest'?
> 
> If it ain't broke (see previous comment), don't fix it.
> 
> > 
> > >
> > > Also, as a side note, in my testing it looks like user1 is placed
> > > into both roles as a user based on the application of the group
> > > role.  i.e. user1 is now a user member in Read Everything and
> > > Administrator.  So my question is, do we need to clutter up the
> > > user role membership if the ldap group membership already has the
> > > information?  This may be desired behavior but wanted to put this
> > > out there
> > 
> > _______________________________________________
> > katello-devel mailing list
> > katello-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/katello-devel
> > 
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
> 




More information about the katello-devel mailing list