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

Dmitri Pal dpal at redhat.com
Thu Feb 10 19:20:07 UTC 2011


On 02/10/2011 01:11 PM, Jan Zeleny wrote:
> Rob Crittenden <rcritten at redhat.com> wrote:
>> One of the features of IPAv2 is it is much easier to delegate
>> permissions to perform tasks (add, delete, modify, etc).
>>
>> This delegation is broken out into three pieces:
>>
>>   * permissions
>>   * privileges
>>   * roles
>>
>> A permission is a very low-level object that says who can do what to
>> whom. These permissions are grouped together into permissions so one can
>> perform a whole task. This is needed for something like adding a user
>> which requires a couple of different permission such as actually writing
>> the user entry, adding the user to the default group and setting the
>> password.
>>
>> A role is a collection of privileges and the users/groups that are
>> granted those privileges.
>>
>> Right now we are defining a single role, helpdesk, and have assigned no
>> privileges to that yet. I was thinking about just assigning it the
>> ability to reset passwords.
>>
>> 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.
> I think a role called something like "IT" might be good. Their privileges 
> would cover mainly access to different parts of the network. They should have 
> privilegese to manage:
> - hosts
> - hostgroups
> - hbac rules
> - sudo rules?
> - dns
> - groups (for example to create new group of users which will have access to a 
> particular machine)
> - services
>
> Now looking at the list, this group can be split into two - one managing the 
> hosts/services and one granting users access.
>
> Jan
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>

There is a superuser who can do anything.
There is also helpdesk supervisor who can do all identity management
There is a security architect who can define the access control but
can't change the system configuration or global policies.

We talked about user person in the past.
Here is what we had in mind:


      Persona 1: /Security Architect/

/Description:/
Oversees the security of a system as a whole. Has access to everything.
A super-user.

/Goals:/

    * IPA configuration
    * Define the policies of IPA itself
    * Replication
    * Define delegation of roles to other, lower-level administrators
    * Management of installed/active plugins?


      Persona 2: /IPA Administrator/

/Description:/
Defines different kinds of objects. Implements and manages roles (mostly
using groups). Does the "heavy lifting" of a system.

/Goals:/

    * Define and create groups
    * Define the relationships between groups
    * Define and create roles for users and groups (in one model or
      another)
    * Create nested groups
    * Define the supported applications


      Persona 3: /Application Administrator/

/Description:/
Utilizes domain knowledge related to applications. Manages applications
and systems as opposed to users and groups.

/Goals:/

    * Define policies for a specific application
    * Define roles for a specific application
    * Define actions for a specific application
    * Apply policies and actions to hosts or group of hosts
    * Apply roles to users and hosts or groups of them


      Persona 4: /Help Desk person/

/Description:/
Person on the front line when problems arise (users can't log in, need
password reset, etc.). Simple user management.

/Goals:/

    * Review user roles (can't modify)
    * Review what groups are enabled on what hosts
    * Set up/manage a user's attributes
    * Place a user in a specific group
    * Reset a user password


      Persona 5: /End User/

/Description:/
End user accessing the system through self-service.

Goals:

    * Reset password via Web UI
    * Set personal properties like phone


    Personas for later consideration


    * Windows admin who has to deal with IPA synch
    * Member of security team who will be looking at the audit logs,
      doing forensics, etc once we have A of IPA
    * End users who deal with the clients could be fleshed out into a
      couple of parts:
          o sysadmins who initially rack and configure the box in the
            first place and connect it to IPA
          o database and application admins who go to the box to take
            care of their stuff on that box
          o security admins who access servers in the database,
            configure the local security, check on it etc.






-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20110210/4ac5b052/attachment.htm>


More information about the Freeipa-devel mailing list