[Freeipa-users] User Roles and access in GUI

[Chandan Kumar]

I agree it won't be a security feature nor you are doing wrong by not
adding it. However, it might come as nice to have feature. Let me explain
you my condition.

We host web application where lot of DNS entries (Public and Internal) are
created for different kind of requests and features. Now we already have a
separate DNS server, Separate Manual Linux User/Access Control management
by puppet. Linux users   ACL have no relationship with the web application
user (which is internal to the web app).

So FreeIPA can help me to centralize the Linux user-management as well as
(Public and Internal) DNS. However, the problem is : traditionally the
access levels were different for DNS users (support guys) and user
management (sysadmins). Now bring both system together even the Host based
access control, sudoers rule everything becomes visible to non-sysadmin
group.

You are right that every user could query all entries from command line and
hence it won't help  to secure the system, but not having it on GUI may
help to avoid "obvious" visibility of the whole directory.

I believe similar GUI "views" could be applied for discussion

http://osdir.com/ml/freeipa-users/2013-03/msg00218.html

where geographically separate Organization units may share the same
directory with limited visibility on other branches.


Having said that, I am not sure how feasible/logical my view is owing to my
limited knowledge in 389 directory server and IPA.

Thanks
Chandan


On Monday, April 15, 2013, Dmitri Pal wrote:

>  On 04/15/2013 11:11 AM, Chandan Kumar wrote:
>
>
>  I think controlling Visibility of tabs would be the best option, if
> possible, based on Roles as mentioned by Rob. As long as other entries are
> not visible in UI, even though they have read only access with command
> line, should be enough.
>
>
> It would not be a security feature though. Just a convenience because the
> same admin would be able to bind directly to ldap and run a search. This is
> why we did not go this route. Yes we can hide panels but it would not mean
> that the user can't easily get that info. So is there really a value in
> hiding? So far we did not see any this is why we did not do it, but may be
> you have some arguments that might convince us that we are wrong. Can you
> please share these arguments with us?
>
>
> On Monday, April 15, 2013, Alexander Bokovoy wrote:
>
>> On Mon, 15 Apr 2013, Petr Spacek wrote:
>>
>>> On 15.4.2013 15:39, Rob Crittenden wrote:
>>>
>>>> There is no easy way to do this. We start with granting all
>>>> authenticated
>>>> users read access to the tree with the exception of certain attributes
>>>> (like
>>>> passwords).
>>>>
>>>> You'd have to start by removing that, then one by one granting read
>>>> access to
>>>> the various containers based on, well, something.
>>>>
>>>
>>> Would it be possible to create a new role to allow current 'read-all
>>> access' and add this role to all users by default?
>>>
>>> It could be much simpler to change the behaviour with this role, or not?
>>> :-)
>>>
>> It would affect service accounts (include host/fqdn at REALM) since roles
>> cannot be applied to them, if I remember correctly. We would need to
>> make an exclusive ACI that allows all services to gain read only access...
>>
>> --
>> / Alexander Bokovoy
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>
>
> --
>
> --
> http://about.me/chandank
>
>
>
> _______________________________________________
> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?www.redhat.com/carveoutcosts/
>
>

-- 

--
http://about.me/chandank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130415/9c0b4269/attachment.htm>