From Free IPA

Contents 1 Policy Enforcement 1.1 Introduction 1.2 Use Cases 1.3 Architecture Overview 1.4 Requirements

Policy Enforcement

THIS EFFORT IS DEFERRED

Introduction

IPA v2 and beyond want to offer tools for policy enforcement. Enterprise wide policy is one of the most difficult challenges facing administrators. Administrators lack a consistent, organization wide view of policy because of many factors:

• A multitude of policy languages for different systems and applications. Allowing a user access to login to a system is usually vastly different from allowing that same user access to modify a database.
• Per-application or per-system policy stores - there is no consistent, centralized policy store.
• Centralized policy solutions usually require replacing or circumventing native access control mechanisms, resulting in additional complexity, compatibility problems, or the native and custom systems "fighting" each other.
• Lack of widely available, standard policy engines or shortcomings in the available engines often drive application developers to invent their own solutions. These solutions are, at best, incompatible with other systems and often lack critical features. The result is access control mechanism that are more work to develop but have fewer features.
• Inconsistent identity (user, machine, and server) and groupings used in the policy.

Use Cases

• Adam is a network admin for a mixed Windows/Linux/MacOS network. He needs to control who logs into systems:
  • Carla needs to log into the Linux webservers via ssh
  • John needs to log into the Windows file servers via remote desktop.
  • Don needs to log into all systems via any method.

• Dan is an application developer creating a client / server backup application. He needs to control access to the backup server based on user/role. He has a sophisticated set of permissions controlling what the clients can do. He would like a library to handle the authorization for him to get more features. He would also like the policy to be centrally managed, but must also allow it to be locally set on the backup server for smaller installations.

Architecture Overview

The IPA policy infrastructure will have 6 main components:

1. A high-level IPA policy language. This will be suitable for direct enforcement by applications or used to generated OS / app native policy.
2. Policy tools for editing and conversion of IPA policy (i.e., generating out native policy).
3. A central policy store for storing native and non-native policy.
4. A policy distribution mechanism to transfer the latest policy from the central policy to the local client.
5. A library for authorization decisions that can be integrated into applications to use native IPA policy.
6. A client daemon to provide access control decisions to the client applications.

Requirements

Centralized Policy Store

• Provide a central repository for policies
  • Both IPA and native policies (e.g., application specific) should be stored.
  • The policies should be stored by system / service group to allow different policies to be stored for different types of systems (e.g., a web server vs an executive laptop).
• Tools for distributing the policy for local enforcement on systems. This will support offline enforcement on laptops and improve performance.

Policy Language

• A high-level policy language that can either be enforced directly or used to generate other policies (e.g., we might generate SELinux policy and Windows group policy from the same abstract policy).
• The ability to 'call out' to native policy languages when the high-level policy is inadequate.
• The policy language should enforce based on: user, role/group, network properties, system applications, and time. Applications should be able to define custom resource types and permissions.

Authorization Library

• A library that can be embedded in applications that enforces the IPA policy language.
  • Allow the use of a local policy store for when the application is not part of an IPA realm (ideally using simple local text files).
  • Easily bound to multiple languages (java, python, etc.).
• Flexible auditing of denials and access should be possible.