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.


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:


  • 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.


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.


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_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:


  • 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:


  • 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.


Built-in Permission Map(内建权限映射)

属性 代表的意思 整数位掩码

Whether someone is allowed to view the domain object.



Whether someone is allowed to make changes to the domain object.



Whether someone is allowed to delete the domain object.



Whether someone is allowed to restore a previously deleted domain object.



Whether someone is allowed to perform all of the above actions.



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.



Whether someone owns the domain object. An owner can perform any of the above actions.



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.



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.


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.


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.


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.


本文转自 firehare 51CTO博客,原文链接:,如需转载请自行联系原作者

云安全基础课 - 访问控制概述
课程大纲 课程目标和内容介绍视频时长 访问控制概述视频时长 身份标识和认证技术视频时长 授权机制视频时长 访问控制的常见攻击视频时长
存储 NoSQL 安全
hydra-microservice 中文手册(下篇)(二)
hydra-microservice 中文手册(下篇)(二)
121 0
消息中间件 存储 NoSQL
hydra-microservice 中文手册(下篇)(一)
hydra-microservice 中文手册(下篇)(一)
176 0
net netcore2 netcore3 HtmlHelper扩展(checkboxlistfor)为例
net HtmlHelper扩展(checkboxlistfor)为例 netcore2 IHtmlHelper扩展(checkboxlistfor)为例 netcore3 IHtmlHelper扩展(checkboxlistfor)为例
862 0
一起谈.NET技术,Visual Studio DSL 入门 3---创建一个简单的DSL模型
从这节开始我们就开始我们的DSL之旅, 首先确保你已经安装了Visual Studio Sdk,并且使用的是Visual Studio 2008.我们先大概创建一个简单的DSL项目,通过这个项目来了解dsl的开发环境和流程.
1420 0
一起谈.NET技术,预览:Visual Basic与C#中的异步语法
  在最近的博客文章中,Visual Basic团队发布了一条简单的消息,声称在Visual Basic和C#中将会增加异步编程语法。两种语言新增的Async和Await关键字的实现将基于.NET 4.0中的任务并行库(Task Parallel Library,TPL)。
908 0
SQL 存储 关系型数据库
【.NET Core项目实战-统一认证平台】第九章 授权篇-使用Dapper持久化IdentityServer4
原文:【.NET Core项目实战-统一认证平台】第九章 授权篇-使用Dapper持久化IdentityServer4 【.NET Core项目实战-统一认证平台】开篇及目录索引 上篇文章介绍了IdentityServer4的源码分析的内容,让我们知道了IdentityServer4的一些运行原理,这篇将介绍如何使用dapper来持久化Identityserver4,让我们对IdentityServer4理解更透彻,并优化下数据请求,减少不必要的开销。
1386 0
负载均衡 中间件 .NET
【.NET Core项目实战-统一认证平台】第八章 授权篇-IdentityServer4源码分析
原文:【.NET Core项目实战-统一认证平台】第八章 授权篇-IdentityServer4源码分析 【.NET Core项目实战-统一认证平台】开篇及目录索引 上篇文章我介绍了如何在网关上实现客户端自定义限流功能,基本完成了关于网关的一些自定义扩展需求,后面几篇将介绍基于IdentityServer4(后面简称Ids4)的认证相关知识,在具体介绍ids4实现我们统一认证的相关功能前,我们首先需要分析下Ids4源码,便于我们彻底掌握认证的原理以及后续的扩展需求。
2753 0