banners
From Free IPA
Contents |
Access Control in FreeIPA v1
Use Cases
1) Alice works in Human Resources and needs to create new user accounts when employees are hired. Bob uses the FreeIPA web console to grant her the rights to:
- Create new users
- Set the initial password for the users
- Add users to common groups
Alice is not allowed to:
- Create new groups
- Add users to all groups (e.g., she can't add users to groups that give administrative access to servers or FreeIPA)
- Change the password for existing users
2) Bob is the FreeIPA admin and wants to allow users to make certain changes to their own account information. He allows them to:
- Reset their own password
- Change their telephone number, home address, etc.
- Allow them to change the custom attributes he added to FreeIPA storing their pet names and favorite James Bond movie.
The are not allowed to change anything else about their accounts.
3) Bob hired a new junior FreeIPA admin Carlton. He wants to give him all access to FreeIPA except the ability to give any FreeIPA administrative access to other users.
4) Dave is a manager of a division and is reorganizing his staff. Bob needs to give him access to change the job title and manager fields for all of the users in his division.
Available Controls
Users
- Adding
- Deleting
- Writing (per field)
- Reading (per field)
- Searching (per field)
Everything other than adding needs to be able to scoped down to a subset of users. For example, Dave might only be able to delete the users in his organization or Alice might be able to modify all of the users in her local office. TODO: how should this scoping work?
The per-field controls are necessary so that sensitive attributes (like password) can be handled correctly. These controls must extend to custom attributes.
Groups
- Adding
- Deleting
- Reading (show members)
- Writing (add members)
User Interface Concerns
Access control will require its own user interface, but it will also effect other user interfaces. The access that a user has must be reflected in the interface and wherever possible attempts to make changes should be prohibited early rather than resulting in errors.
- When creating or modifying a user or group only those fields that the user has access to write should be editable in the interface.
- When searching or displaying entries attributes that the user cannot read or search against should be optionally displayed (we are not attempting to hide the existence of attributes).
- In general, we are not concerned with concealing the existence of entries (like users or groups), just specific attributes of those entries. For example, it is less important to conceal the existence of the SuperAdmin group than it is to prevent the disclosure of its members.
TODO: how can access be determined when presenting a form for editing?
