On Thu, Oct 06, 2016 at 04:41:10PM +0200, Jakub Hrozek wrote:
> Hi,
>
> with Alexander's help, I wrote up a design page about how SSSD should
> read Fleet Commander data from IPA and present them to the FC client
> component. The SSSD part is described here:
>
https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration
> and the IPA part is here:
>
https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Featu...
>
> For convenience, I copied the SSSD wiki page below. Comments are welcome!
>
...
>
> ==== Looking up the Fleet Commander profiles and storing the JSON profile data ====
> Since the first implementation will only fetch rules that are linked to
> this host and the user in question, the SSSD's session provider will issue
> an LDAP search along these lines:
> {{{
>
(&(objectclass=ipadeskprofilerule)(memberHost=my_fqdn_or_my_host_group)(memberUser=user_login_or_group))
> }}}
>
> All host groups the IPA client is a member of must be included in the
> `memberHost` part of the filter. Additionally, all user groups must be
> included in the `memberUser` part of the filter. Since in most cases,
> the user's groups will be resolved during the login, we will only issue
> an initgroups request in case the user's initgroups are expired already
> to cover cases where the sessions provider was invoked separately.
I wonder if it would be more efficient to read all profiles which apply
to the host in a single run store them in the cache and do the remaining
part of the processing locally? Iirc this is what we do with HBAC rules
and there might be a chance to reuse some of the HBAC code but just look
for objectclass ipadeskprofilerule instead of ipahbacrule?
Since there are host and user categories mentioned on the server side
design page I guess the underlying objectclass is ipaAssociation and
because of this it makes even more sense to reuse as much of the HBAC
lookup code as possible.
Yes, of course you are right, fetching the per-host data is almost always
a good idea. I changed the wiki page: