Symfony2CookBook：高级ACL概念

Design Concepts（设计思路）

Symfony2's object instance security capabilities are based on the concept of an Access Control List. Every domain object instance has its own ACL. The ACL instance holds a detailed list of Access Control Entries (ACEs) which are used to make access decisions. Symfony2's ACL system focuses on two main objectives:

Symfony2的对象实例安全功能是建立在访问控制列表概念之上的。所有的域对象实例都拥有自己的ACL。ACL实例有着一个访问控制项的详细列表（ACEs），该列表用来指定访问权限。Symfony2的ACL系统专注于两个主要目标：

• providing a way to efficiently retrieve a large amount of ACLs/ACEs for your domain objects, and to modify them;
• 为你的域对象提供一个有效的方法去检索和更改大量的ACLs/ACEs。
• providing a way to easily make decisions of whether a person is allowed to perform an action on a domain object or not.
• 提供一个方法，可以方便地确定用户是否被允许在一个域对象上具备执行相关操作的权限。

As indicated by the first point, one of the main capabilities of Symfony2's ACL system is a high-performance way of retrieving ACLs/ACEs. This is extremely important since each ACL might have several ACEs, and inherit from another ACL in a tree-like fashion. Therefore, we specifically do not leverage any ORM, but the default implementation interacts with your connection directly using Doctrine's DBAL.

第一点明确表明，Symfony2中ACL系统的主要功能之一就是高效检索ACLs/ACEs。这非常重要，因为每个ACL有多条ACEs、同时它还以类树型的方式从其他ACL中继承。因此，虽然我们没有指定ORM，但是默认与你的连接交互实现是直接使用Doctrine的DBAL。

Database Table Structure（数据表结构）

The default implementation uses five database tables as listed below. The tables are ordered from least rows to most rows in a typical application:

（ACL系统）缺省使用下列五个数据表来实现。在一个典型的应用程序中这些表按记录数从小到大排列。

• acl_security_identities: This table records all security identities (SID) which hold ACEs. The default implementation ships with two security identities: RoleSecurityIdentity, and UserSecurityIdentity
• acl_security_identities：该表记录所有拥有ACEs的安全标识（SID）。并缺省实现两个安全标识：RoleSecurityIdentity和UserSecurityIdentity之间的关系。
• acl_classes: This table maps class names to a unique id which can be referenced from other tables.
• acl_classes：该表将类名映射成唯一id，该id可以被其他数据表引用。
• acl_object_identities: Each row in this table represents a single domain object instance.
• acl_object_identities:数据表中的每条记录都表示一个单独的域对象实例。
• acl_object_identity_ancestors: This table allows us to determine all the ancestors of an ACL in a very efficient way.
• acl_object_identity_ancestors:该表允许我们用一种非常高效的方式去确定一条ACL的所有祖先。（校者注：也就是可以迭代地确定该ACL继承了哪些ACL）
• acl_entries: This table contains all ACEs. This is typically the table with the most rows. It can contain tens of millions without significantly impacting performance.
• acl_entries：该数据表包含所有的ACEs。该表通常拥有最多的记录。在包含数千万条记录的情况下不会显著影响性能。

Scope of Access Control Entries（访问控制项范围）

Access control entries can have different scopes in which they apply. In Symfony2, we have basically two different scopes:

访问控制项在应用时有不同的范围。在Symfony2中我们有两个基本的范围。

• Class-Scope: These entries apply to all objects with the same class.
• 类范围：这些项应用于拥有相同类的所有对象上。
• Object-Scope: This was the scope we solely used in the previous chapter, and it only applies to one specific object.
• 对象范围：在前面的章节中我们使用过这个范围，它仅用于指定的对象。

Sometimes, you will find the need to apply an ACE only to a specific field of the object. Let's say you want the ID only to be viewable by an administrator, but not by your customer service. To solve this common problem, we have added two more sub-scopes:

有时候，你只能将ACE应用到对象的特定字段里。比如说，你想ID只能被管理员而不是客户服务查看。那么要解决这个问题，我们需要添加两个额外的子范围：

• Class-Field-Scope: These entries apply to all objects with the same class, but only to a specific field of the objects.
• 类字段范围：这些项应用于拥有相同类的所有对象上，但仅仅是对象的特定字段。
• Object-Field-Scope: These entries apply to a specific object, and only to a specific field of that object.
• 对象字段范围：这些项应用于指定对象，但仅限于该对象的特定字段。

Pre-Authorization Decisions（预授权判断）

For pre-authorization decisions, that is decisions before any method, or secure action is invoked, we rely on the proven AccessDecisionManager service that is also used for reaching authorization decisions based on roles. Just like roles, the ACL system adds several new attributes which may be used to check for different permissions.

预授权判断是指任何方法或安全动作执行前就已判断，这有赖于AccessDecisionManager证明服务，该服务也用于基于角色的达到授权判断。像角色一样，ACL系统添加一些新的属性去检查不同的权限。

Post Authorization Decisions（后授权判断）

Post authorization decisions are made after a secure method has been invoked, and typically involve the domain object which is returned by such a method. After invocation providers also allow to modify, or filter the domain object before it is returned.

后授权判断是发生在安全方法执行之后，通常还包含该方法返回的域对象。在调用提供器之后照样允许去修改或过滤返回前的域对象。

Due to current limitations of the PHP language, there are no post-authorization capabilities build into the core Security component. However, there is an experimental SecurityExtraBundle which adds these capabilities. See its documentation for further information on how this is accomplished.

由于PHP语言的限制，已授权功能还未被纳入到核心安全组件中。尽管如此，实验性质的SecurityExtraBundle已经添加了这些功能。查看它的文档以便进一步了解它是怎么实现的。

Process for Reaching Authorization Decisions(达到授权判断的处理)

The ACL class provides two methods for determining whether a security identity has the required bitmasks, isGranted and isFieldGranted. When the ACL receives an authorization request through one of these methods, it delegates this request to an implementation of PermissionGrantingStrategy. This allows you to replace the way access decisions are reached without actually modifying the ACL class itself.

ACL类提供两种方法去判断一个安全标识是否具有要求的掩码，isGranted和isFieldGranted。当ACL从这两种方法之一接收到授权请求，它就把这个请求委派给PermissionGrantingStrategy的实现。这样就允许你替换掉已达到但未实际更改的ACL类自身的权限判断方式。

The PermissionGrantingStrategy first checks all your object-scope ACEs if none is applicable, the class-scope ACEs will be checked, if none is applicable, then the process will be repeated with the ACEs of the parent ACL. If no parent ACL exists, an exception will be thrown.