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

2011-02-21 Thread David O'Brien

Dmitri Pal wrote:

On 02/11/2011 10:12 AM, Rob Crittenden wrote:

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@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?)


This mean he can read HBAC rules


 * 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




How about this layout

Helpdesk Engineer
* Edit users
* Reset passwords
* Add/remove group membership
* Troubleshoot the HBAC (in future but not modify the HBAC rules themselves)

User administrator - the person who is responsible for creating users
and groups. This is instead IPA administrator above.
* Users - full control
* Groups - full control

IT Specialist
* Hosts full control
* Hostgroups full control
* Services full control
* DNS full control
* Automount

IT Security Specialist - includes all of the above +
* Netgroups
* SUDO
* HBAC

Security Architect
 * IPA config
 * Password policies
 * Kerberos config
 * Replication
 * Define delegation of roles to other, lower-level administrators



Did I miss anything?


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel






Any updates on this?

I'm up to my neck in Access Control doc at the moment and looking for 
any and all information, especially when it comes to what IPA provides 
by default. It gives me something to build on.


thanks

--

David O'Brien
Red Hat Asia Pacific Pty Ltd
+61 7 3514 8189


"He who asks is a fool for five minutes, but he who does not ask remains 
a fool forever."

 ~ Chinese proverb

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2011-02-11 Thread Dmitri Pal
On 02/11/2011 10:12 AM, Rob Crittenden wrote:
> 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@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?)

This mean he can read HBAC rules

>  * 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
>


How about this layout

Helpdesk Engineer
* Edit users
* Reset passwords
* Add/remove group membership
* Troubleshoot the HBAC (in future but not modify the HBAC rules themselves)

User administrator - the person who is responsible for creating users
and groups. This is instead IPA administrator above.
* Users - full control
* Groups - full control

IT Specialist
* Hosts full control
* Hostgroups full control
* Services full control
* DNS full control
* Automount

IT Security Specialist - includes all of the above +
* Netgroups
* SUDO
* HBAC

Security Architect
 * IPA config
 * Password policies
 * Kerberos config
 * Replication
 * Define delegation of roles to other, lower-level administrators



Did I miss anything?

> ___
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>


-- 
Thank you,
Dmitri Pal

Sr. 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


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

2011-02-11 Thread 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@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

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2011-02-11 Thread Dmitri Pal
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@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.

-- 
Thank you,
Dmitri Pal

Sr. 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


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

2011-02-10 Thread David O'Brien

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@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
--

David O'Brien
Red Hat Asia Pacific Pty Ltd
+61 7 3514 8189


"He who asks is a fool for five minutes, but he who does not ask remains 
a fool forever."

 ~ Chinese proverb

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2011-02-10 Thread Dmitri Pal
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@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.

-- 
Thank you,
Dmitri Pal

Sr. 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


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

2011-02-10 Thread Jakub Hrozek

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


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

2011-02-10 Thread Dmitri Pal
On 02/10/2011 01:11 PM, Jan Zeleny wrote:
> Rob Crittenden  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@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/



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

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

2011-02-10 Thread Adam Young

On 02/10/2011 01:11 PM, Jan Zeleny wrote:

Rob Crittenden  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@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Desktop support:  needs to be able to add a new host to the server.  
Probably means they need delete host as well.  Can't mess with the user 
info.  Right now, they would also need to be able to create the A 
record, too.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2011-02-10 Thread Jan Zeleny
Rob Crittenden  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@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2011-02-10 Thread Gowrishankar Rajaiyan

On 02/10/2011 09:42 PM, Rob Crittenden 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.


Thinking about helpdesk and whenever a user joins/leaves a company the 
helpdesk needs the privileges to add/delete their user accounts.


I would suggest all the privileges like:
- creating users
- resetting passwords
- deleting users
- disabling user accounts
- unlocking user accounts
- modifying user accounts

Groups are something that are more involved with their respective 
departments and can be left out for the administrators to decide on if 
they would like to upgrade the helpdesk role/ or create new roles as per 
their department listings.



thanks

rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



--
regards
/shanks

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel