[Freeipa-devel] Some thoughts about login services

[Simo Sorce]

On Fri, 15 Oct 2010 13:18:18 -0400
Dmitri Pal <dpal at redhat.com> wrote:

> Simo Sorce wrote:
> > On Fri, 15 Oct 2010 11:36:50 -0400
> > Dmitri Pal <dpal at redhat.com> wrote:
> >
> >   
> >> Hello,
> >>
> >> Currently HBAC login group is defined as:
> >> objectClasses: (2.16.840.1.113730.3.8.4.11 NAME
> >> 'ipaHBACServiceGroup' DESC 'IPA HBAC service group object class'
> >> SUP nestedGroup STRUCTURAL X-ORIGIN 'IPA v2' )
> >>
> >> Which means it can be nested.
> >>
> >> In the recent discussion about SUDO and groups of SUDO commands we
> >> settled down on the
> >> objectClasses: (2.16.840.1.113730.3.8.8.3 NAME 'ipaSudoCmdGrp' DESC
> >> 'IPA object class to store groups of SUDO commands' SUP
> >> groupOfNames MUST ( ipaUniqueID ) STRUCTURAL X-ORIGIN 'IPA v2' )
> >>
> >> Which we decided should not support nesting.
> >> Looking at the UI for the HBAC and complexity of the manipulation
> >> with the HBAC object and related hbac services and groups of those
> >> it occurred to me that one of the simplifications that we can have
> >> is disallowing nesting of the HBAC login groups. It is expected
> >> that there will be not many of those anyways. If we need it later
> >> we will change it to support nesting. However the nesting is
> >> already implemented in CLI and actually works. I tried and
> >> everything is documented and seems ok.
> >>
> >> But group nesting in UI is a bit of nightmare. It is unclear
> >> whether the nesting is actually a use case that we need to support
> >> here.
> >>
> >> Thoughts?
> >>     
> >
> > Unless there is a good reason to prevent nesting then I don't think
> > it makes sense to undo what has already been done.
> > If complexity is perceived as problematic than what we can do is
> > provide guidelines on how/when it is or not appropriate to use
> > nesting.
> >
> > Simo.
> >
> >   
> The dilemma here is:
> * Undo schema and CLI to simplify UI
> Pros: less work in UI
> Cons: reduces functionality and undoes what is already done (affects
> help and CLI)
> * Implement UI to handle nesting and do not touch schema and CLI
> Pros: Does not undo anything and does not reduce functionality that
> someone might want at some point
> Con: Much more work in UI
> * Leave CLI and schema as is but in UI not support nesting
> Pros: Medium amount of work
> Cons: Ugly
> 
> I do not know what is the best approach here.
> IMO first option is less risky and less work.

I'd go for the last one, may be ugly, but does not undo anything that
already works and has the effect of simplifying the UI which is what
you are after right now. Of course that also means the UI will have to
cope (maybe disabling editing) with any entry that has been nested
through the CLI or over LDAP directly.

This is assuming the UI work would really be more complex. We have
nesting to support for other things already so I am not sure it would
really be substantially less work to do the same thing elsewhere, I bet
a lot of code could simply be reused.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York