[Freeipa-devel] Help define the roles IPA has by default

[Rob Crittenden]

Dmitri Pal wrote:
> On 02/10/2011 07:25 PM, David O'Brien wrote:
>> Dmitri Pal wrote:
>>> On 02/10/2011 03:05 PM, Jakub Hrozek wrote:
>>>> On 02/10/2011 05:12 PM, Rob Crittenden wrote:
>>>>> But what other roles do we need? The mind boggles and rather than
>>>>> dictating what the initial ones will be I'm looking for some
>>>>> guidance/suggestions.
>>>>>
>>>>> thanks
>>>>>
>>>>> rob
>>>> I'm actually wondering if we need to define many default roles in the
>>>> upstream project. I'm thinking that every organization will have
>>>> different needs and different ways of role delegation anyway, so I
>>>> would rather make sure this feature is well documented with examples
>>>> and use cases.
>>>>
>>>> _______________________________________________
>>>> Freeipa-devel mailing list
>>>> Freeipa-devel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>>
>>> I think that a reasonble set of 3 -5 roles and documentation how to
>>> change them should be sufficient.
>>>
>> I agree. On top of what Dmitri has already sent out, this thread is a
>> really good continuation of documenting delegation, permissions,
>> roles, etc., especially because this area is so different from v1. If
>> we look at it from two perspectives, one being What does IPA need to
>> function?, and the other being What do customers need?, then we can
>> probably come up with a short list and provide some basic use cases,
>> descriptions, and examples.
>>
>> Dmitri's list of 5 is good, although I would suggest settling on a
>> naming format, by which I mean rather than a combination of
>> person-based and role-based names, use a consistent format. Security
>> Architect&  IPA Administrator are people (faiap), while Helpdesk is a
>> department. Anyway, you get the idea.
>>
>> We've already started with Name, Description, Goals; with a few use
>> cases I can put together short sections with links to existing docs on
>> how to use the relevant commands, or write them as needed.
>>
>> cheers
> Sounds like a good idea.
>

Well, some of these roles don't really match what we are shipping in v2. 
There is no place for Application Administrator at all and End User is 
implicit. So that leaves 3 roles. If we go with these we'll need to add 
some additional permissions/privileges to support it.

If we go with this, here is what we're looking at. Also note that the 
role "IPA Administrator" is distinct from the group cn=admins which 
gives pretty much global access. Those that need additional 
permissions/privileges are marked with the ticket number.

* Security Architect
  * IPA config (950)
  * Replication
  * Define delegation of roles to other, lower-level administrators

* IPA Administrator
  * Define and create groups (and delete?)
  * Define the relationships between groups (what does this mean?)
  * Define and create roles for users and groups (what does this mean?)
  * Create nested groups (I don't know if we can have an aci for this)

* Help Desk
  * Review what groups are enabled on what hosts (what does this mean, 
all groups are enabled on all hosts, right?)
  * Set up/manage a user's attributes
  * Place a user in a specific group
  * Reset a user password

This is a good start but it completely leaves out the following:

* Users (helpdesk can modify & reset password, nobody can add/delete)
* Host management
* Service management
* Hostgroups
* SUDO
* HBAC
* netgroups
* DNS
* Automount

rob