[学习笔记] Symfony2CookBook：高级ACL概念 [转]

• 原文出处：http://symfony.com/doc/current/cookbook/security/acl_advanced.html
• 原文作者：Symfony.com
• 授权许可：创作共用协议
• 翻译人员：StarBear
• 校对人员：FireHare
• 适用版本：Symfony 2
• 文章状态：已校对

The aim of this chapter is to give a more in-depth view of the ACL system, and also explain some of the design decisions behind it.

本章的目的是更加深入地了解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。

Object Identities（对象标识）

The ACL system is completely decoupled from your domain objects. They don't even have to be stored in the same database, or on the same server. In order to achieve this decoupling, in the ACL system your objects are represented through object identity objects. Everytime, you want to retrieve the ACL for a domain object, the ACL system will first create an object identity from your domain object, and then pass this object identity to the ACL provider for further processing.

ACL系统是完全与你的域对象分离的。它们甚至不需要保存在同一个数据库或同一台主机中。为了实现这种分离，在ACL系统里你的对象被认为是对象标识。任何时候，在你想检索域对象的ACL时，ACL系统都会事先为你的域对象创建一个对象标识，然后将该对象标识传递到ACL提供器作进一步处理。

Security Identities（安全标识）

This is analog to the object identity, but represents a user, or a role in your application. Each role, or user has its own security identity.

与对象标识类似，但表现为你应用程序中的用户或角色。每个角色或用户都拥有各自的安全标识。（校者注：与域对象拥有自己的对象标识相似，用户或角色也拥有各自的安全标识）

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系统添加一些新的属性去检查不同的权限。

Built-in Permission Map（内建权限映射）

属性	代表的意思	整数位掩码
VIEW	Whether someone is allowed to view the domain object. 某人是否被允许查看域对象	VIEW、EDIT、OPERATOR、MASTER或OWNER
EDIT	Whether someone is allowed to make changes to the domain object. 某人是否被允许更改域对象	EDIT、OPERATOR、MASTER或OWNER
DELETE	Whether someone is allowed to delete the domain object. 某人是否被允许删除域对象	DELETE、OPERATOR、MASTER或OWNER
UNDELETE	Whether someone is allowed to restore a previously deleted domain object. 某人是否被允许回复先前被删除的域对象	UNDELETE、OPERATOR、MASTER或OWNER
OPERATOR	Whether someone is allowed to perform all of the above actions. 某人是否被允许执行上述的操作。	OPERATOR、MASTER或OWNER
MASTER	Whether someone is allowed to perform all of the above actions, and in addition is allowed to grant any of the above permissions to others. 某人是否被允许执行上述所有的操作，同时也具备将上述的任何一个权限授权给其他人。	MASTER或OWNER
OWNER	Whether someone owns the domain object. An owner can perform any of the above actions. 某人是否拥有该域对象。拥有者能执行上述所有的操作。	OWNER

Permission Attributes vs. Permission Bitmasks（权限属性vs权限位掩码）

Attributes are used by the AccessDecisionManager, just like roles are attributes used by the AccessDecisionManager. Often, these attributes represent in fact an aggregate of integer bitmasks. Integer bitmasks on the other hand, are used by the ACL system internally to efficiently store your users' permissions in the database, and perform access checks using extremely fast bitmask operations.

AccessDecisionManager使用属性和使用角色是一样的。通常，这些属性其实是用一串整型位掩码的总和来表示的。另一方面在ACL系统内部，整数位掩码被用来在数据库中保存用户权限，并且使用位掩码操作执行权限检查非常快速。

Extensibility（扩展性）

The above permission map is by no means static, and theoretically could be completely replaced at will. However, it should cover most problems you encounter, and for interoperability with other bundles, we encourage you to stick to the meaning we have envisaged for them.

上述权限映射并不一成不变，理论上完全可以随意替代。然而，它将涵盖你所遇到的绝大多数问题，并且可以与其它Bundle相互协作。因此，我们还是鼓励你坚持我们对它的期望。

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.

PermissionGrantingStrategy首先检查所有对象范围的ACEs，如果没有匹配，则检查类范围的ACEs，如果还未匹配，将会重复在父ACL上的ACEs的检查过程。如果父ACL不存在，则抛出异常。