[Freeipa-devel] Some thoughts about login services

[Dmitri Pal]

Simo Sorce wrote:
> 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 where ugliness comes to play.

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

It is not that simple. All the membership is represented by concept
"facets" in the UI.
Using the facets in the UI for the hbac groups does not look good and
intuitive. Ben and I were trying to find a different approach and not
use facets for HBAC and SUDO. Keep in mind that we plan to reuse the
same UI concepts for SUDO and HBAC since from the UI POW the logic and
work flow is very similar. But the underlaying structure is not due to
the schema difference we have so we would have to implement different UI
approaches for them and deign them conceptually differently. I want to
avoid that.
Also the hbac services and groups do not make much sense outside the
context of HBAC so for UI navigation it does not make sense to have them
on the second level menu in parallel to HBAC as it makes sense to have
users and group under identities. That suggests having a third level of
navigation this is where the complications come and both Ben and I do
not see so far a good way of solving it. Facets approach just does not
seem to work well in that case.

The problem is that CLI does not have navigation hierarchy but UI does
and things should be group logically and intuitively and not necessarily
in the same way as CLI would suggest.

> Simo.
>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/