On 06/04/2014 04:10 PM, Simo Sorce wrote:
On Wed, 2014-06-04 at 20:52 +0200, Martin Kosek wrote:
On 06/04/2014 05:35 PM, Simo Sorce wrote:
On Wed, 2014-06-04 at 08:44 +0200, Martin Kosek wrote:
On 06/04/2014 08:34 AM, Martin Kosek wrote:
...
Users
- Users
- Groups
- SUDO
Hosts
- Hosts
- Host groups
- Services
- Netgroups
- Automount
Authentication
- OTP Tokens
- Password Policy
- Kerberos Ticket Policy
Policy
- HBAC
- SELinux User Maps
- Automember
Alternatively, we could rename Policy to "Authorization" as both HBAC and
SELinux is about authorizing what an authenticated user can do. We would just
need to move Automember to different place, though this one is difficult - it
relates both to Users and Hosts, just like Netgroup.
I do not see the need to do Policy -> Authorization but Automember is in
the wrong place imo.
The first tab should be Users -> Accounts and include automember in it
as automember is about groupings ?
Actually I would merge the current Users and Hosts tabs into
'Accounts' (or maybe 'Identities' ?) and add Automember.
Simo.
Automember is about grouping both users and hosts. I put it under Policy
originally as it basically is a policy, when are certain users/hosts
automember'ed.
I would personally not merge Users and Hosts top level menus to one top level
menu as that would spoil the whole reason why this effort is done, i.e. have at
most 7 items in the second level bar to make things clearer.
To me, it seemed a good idea to split Users and Hosts to achieve the target as
it separates well the intent what one wants to do. Now we have it all under
Identity (including DNS and Realm Domains) which is messy.
Unfortunately some of your groupings make little sense to me:
- why is SUDO under Users ??
It's a security policy and those policies are equally related to users,
groups and hosts.
- why "policies" are under authentication ?
Both password policies and Kerberos Ticket policies have nothing to do
with the authentication part, but with changing password and with which
features are allowed on tickets.
- why automember is in Policy ?
It is just autoconfiguration it doesn't enforce any policy on its own
But I am pretty open to counter-proposals which keeps the UX requirement of 7
second level items.
Martin
This is how it makes sense to me as a logical grouping:
Accounts/Identity (7):
- Users
- Groups
- Hosts
- Host Groups
- Netgroups
- Services
- Automember
^ These are all identity or identity-grouping related objects/actions
+1
Policies (6):
- Sudo
- HBAC
- SELinux User Maps
- OTP Tokens (*)
- Password Policies
- Kerberos ticket Policies
^ These are all Security Policies an admin cares about
+1, with the note, i.e. OTP does not belong there
Directory (6):
- Permissions
- Privileges
- Roles
- Delegation
NOTE: the 4 above can be merged into a single 'Authorization' entry
perhaps
May be it should be and "Administration" tab, I do not like the title. I
understand where the directory comes from but this is IMo not intuitive
for someone who does not know what is under the hood.
- Replication Topology
- Views (future)
^ Everything that deals with direct LDAP access/view
I think views do not belong here. They belong in the same place where
the trusts are.
Network Services (4):
- Automount
- DNS
- CA
- Vault (future)
^ All the additional network services or configuration of network
related services
+1
Configuration (3):
- Trusts
- ID Ranges
- Realm Domains
- Global
^ Anything that does not fit the above categories.
+1
Docs:
- whatever :)
(*) The only doubt I have is about OTP Tokens, it may be worth taking
them off Policies and putting them into a new tab which in future may
also sport a pointer to user certificates management:
Yeah, may be for now we put OTP as a top level for now and have tokens
and create a RADIUS page to manage radius proxies?
In future when we add other credentials we can rename it and add smart
card related options.
Authentication:
- OTP Tokens
- User Certificates (future)
HTH,
Simo.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
