banners
From Free IPA
As it stands, FreeIPA (version 1.1.0 at time of writing) grants access for all users to all servers, and leaves access control to pam_ , nss_ or access libraries on the server end. The ability to have a central location that determines which users, or group of users, should be allowed access to which host, or group of hosts, would be a great value to add to FreeIPA . To many organizations, it will likely be a 'must have' requirement without which FreeIPA would offer little more than a home-grown solution.
As a general rule, dealing with users or servers individually likely isn't the most efficient way to proceed. Users can usually be grouped, and so can servers. The disadvantage with groups, however, is that there are almost always exceptions, and while exceptions ought to be discouraged, forbidding them often leads to workarounds being developed. Coming up with a solid scheme that allows for exceptions becomes necessary. Arguably, it is as important to come up with a good way to represent and store the data as it is to come up with the actual implementation on the server end. The latter would be easier to stub out and leave to the end user/organization to implement successfully.
And while it's not realistic to expect all features and cases that can be outlined now to be manageable in the next release, the expectation is to avoid making design decisions now that will either make it difficult to implement, or even prohibit supporting them in the future.
Contents |
Concepts
The majority of concepts involved in centralizing host access should be familiar enough to most system administrators, but still bear mentioning.
Users
Users are a simple concept and the current FreeIPA representation seems sufficient.
User collections
Users can usually be grouped logically. Some group examples could be "unixadmins", "qa", "developers". The reason they're described as "collections" here is to avoid confusion with user groups in the UNIX group sense.
User Groups
User groups, the UNIX kind this time, also need to be centrally managed. Whether or not access to certain servers should be based on user group is up for debate, and perhaps best left for FreeIPA users to decide, hence the distinction here between "user groups" and "user collections".
Hosts
Given FreeIPA's tracking of host service principals, it seems more accurate to define a host by its Kerberos identity, and to leave it to system administrators to ensure that each host identifies itself with the correct Kerberos credentials. This does require that hosts use Kerberos (GSSAPI/SASL) when authenticating to look up user authorizations.
Host collections
To remain consistent with the "user collections" terminology, logical grouping of hosts can be called "host collections".
Access grants
Goals
The object of centralized host access controls is to provide a quick and easy way to manage authentication/identification, authorization, group identity and group membership from a single interface. Whether or not delays in the propagation of changes are part of a different discussion.
The feature set that could interest organizations is as follows (Note: some of these are already provided by FreeIPA in its current form):
- User authentication:
- Systems-wide authentication of all users
- User identity:
- Systems-wide uniqueness of UID to user mapping
- Exception system to handle users having different UIDs on different systems.
- Exception system to handle UID conflicts.
- Group identity:
- Systems-wide uniqueness of GID to user group mapping
- Exception system to handle groups having different GIDs on different systems.
- Exception system to handle GID conflicts.
- Authorization/Identification:
- Access grant for any user to any server.
- Presence of user group on any server.
- Membership in any group of any user on any server.
