[Freeipa-devel] [PATCH] 767-770 webui: hide applied to hosts tab for Default Trust View

[Tomas Babej]

On 10/20/2014 12:30 PM, Alexander Bokovoy wrote:
> On Mon, 20 Oct 2014, Tomas Babej wrote:
>>
>> On 10/20/2014 08:09 AM, Alexander Bokovoy wrote:
>>> On Mon, 20 Oct 2014, Endi Sukma Dewata wrote:
>>>> On 10/17/2014 4:55 PM, Petr Vobornik wrote:
>>>>> On 17.10.2014 22:51, Endi Sukma Dewata wrote:
>>>>>> On 10/10/2014 6:44 AM, Petr Vobornik wrote:
>>>>>>> Web UI part of:
>>>>>>>
>>>>>>> https://fedorahosted.org/freeipa/ticket/4615
>>>>>>>
>>>>>>> Patch 767 is a little refactoring needed for $pre_op(as plain
>>>>>>> object)
>>>>>>> work as intended even with instantiated objects + fixes a bug where
>>>>>>> Evented objects were not considered a framework object.
>>>>>>>
>>>>>>> Patch 768 switches tabs so we can hide it later
>>>>>>>
>>>>>>> Patch 769 hides the tab
>>>>>>>
>>>>>>> PAtch 770 is not really needed(would like to hear options
>>>>>>> whether to
>>>>>>> include it). It's in effect only if user somehow manages to open
>>>>>>> 'Applies to hosts' facet for 'Default trust view'. Maybe
>>>>>>> redirection
>>>>>>> would be better - if we need to act.
>>>>>>
>>>>>> For some reason I don't see the Default Trust View in the
>>>>>> database/CLI/UI with a brand new server installation. Alexander
>>>>>> said he
>>>>>> will investigate on Monday.
>>>>>>
>>>>>> The patches seem to be fine, I don't have any objections, feel
>>>>>> free to
>>>>>> push. The missing Default Trust View is most likely unrelated to UI.
>>>>>
>>>>> It should be added when you run ipa-adtrust-install.
>>>>
>>>> OK, that fixed it. Some comments:
>>>>
>>>> 1. Shouldn't the Default Trust View entry be added during the initial
>>>> installation? Although it's unlikely to conflict with user-defined
>>>> entries, it's kind of strange to add a 'built-in' entry after the
>>>> initial installation.
>>> It only can contain entries from the trusted domains. Adding it before
>>> we can serve trusted domains, i.e. before ipa-adtrust-install, makes
>>> it more complicated as users will not be able to add overrides to it.
>>>
>>> On the other hand, users will not be able to add entries there until
>>> actual trust is created so may be adding it as part of default
>>> configuration, even before ipa-adtrust-install isn't a big issue at
>>> all,
>>> if we would provide proper help/hint message.
>>>
>>
>> I think the reasoning behind adding it as part of adtrust-install was
>> the following scenario, which can happen for IPA installs without
>> adtrust component.
>>
>> 1.) User installs IPA
>> 2.) Tries to override some IPA users
>> 3.) Sees "Default Trust View" and is confused, since he has no trusts or
>> no AD in his environment
> Even after ipa-adtrust-install run you would still not be able to
> resolve AD users unless trust is added. It does not mean we should move
> creating 'Default Trust View' to the first trust.
>
> What about filtering out 'Default Trust View' if no trusts are in place?
> This would be a bit problematic for the case when you had trusts and
> deleted them and currently have none of them but overrides are in place,
> but at least it would be consistent -- you don't see default view and
> you are not able to add there anything.
>
> However, it raises another question: if no trusts exist right now but
> there are some AD user overrides in any view, how would we display them?
> We cannot resolve SIDs to names at this point so overrides will look
> ugly anyway. We can use ipaOriginalUid for users but we don't have
> anything like that for groups.

I think we should fail in the trust-del if there are any overrides tied
to this particular trust, unless --forced (which should be used only for
recreation of the trust).

Currently, we rely on resolving the user/group name to do any operation
on the ID override, so having the trust removed, you'd have to use LDAP
directly to remove the entries.

>
>> We actually add more built-in entries during the adtrust-install, e.g.
>> "Default SMB group".
> We don't use these entries in the UI, so they don't create any specific
> issue.

-- 
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org