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/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel