[Freeipa-users] Question about administrative granularity

[Dmitri Pal]

Hello,

Please join the discussion around the following ticket:
https://fedorahosted.org/freeipa/ticket/47

Instead of adding a comment there I would comment here:

Approach 1: Identify privileged and non privileged uses by dynamically
looking at their ACIs, show the UI that is applicable to the user based
on this dynamic evaluation
Pros: Most dynamic approach
Cons: can get too complex and performance costly

Approach 2: Create fixed views of the items in the system (that can in
future be adjusted)
Unprivileged view - brings user right to sef service screen. In future
it can be extended to other screens like: what hosts I am allowed to
access; search for user contact information etc.
Low level privileged user - this user probably can mange some identities
(users, user groups, hosts, host groups, and netgroups) but he will not
see other menu choices so he will be brought to choose an item under the
"identities" panel right away. Top level choices will not be available
to him.
Medium level privileged user - will see identities and policies
High level user - sees everything.

Now we can say this actually each of the 4 described  UI  views can be
represented by a configuration entry in the back end that would describe
which menu items are available in each of the four views. We can come
up  with the schema - it is not a problem. If we go this route we will
have 4 configurable layouts that  can be adjusted by admins based on the
specific deployment use cases. The actual fields that will be shown to
the users depend on his ACI. This is a separate discussion.
If we go this route we will need some smarts around the cases when the
top level menu has just one item or there is just one item left in the
sub menu panel but I think we can work it out.

Next step is to say that we in future would allow creation of the new
configurations so that we are not limited to just 4 predefined. May be
we should allow it right away? It is a separate topic that can be deferred.

Next we need to associate the user with the view. There are
traditionally two ways of doing it:
* Via groups
* Via attributes

In the case of groups we would effectively have to create a
corresponding group for each of the configuration entries we have.
The view config entry will have a reference to the DN of the
corresponding group.
Placing the user into the group will relate him to the corresponding view.
The logic of the resolution which view to use will be the following:
* Get current user based on his kerberos ticket
* Get the list of views in the ascending priority order
* For each view get a referenced group entry
* Check if user is a member of the group
* The first group he is found in will identify the view to use
* If user is not found in any group assume lowest level view

The group entry can be created automatically using managed entry plugin
when the view config entry is created.



If we decide to use the attributes we have to add an attribute to each
user entry (or to some and assume absence as unprivileged) .
We would have to invent the method of doing bulk assignments in UI and CLI.
This approach seems less straightforward than using groups.

 So I would vote for the config entry + managed group approach described
above.
If there are no objections I will come up with the schema for those.

Comments welcome!

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


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