Partially revert "fix voting on multiple roles behavior description" due to CVE-2020-5275

Author: ajgarlag

security.rst

@@ -513,7 +513,7 @@ start with ``/admin``, you can:
                 # require ROLE_ADMIN for /admin*
                 - { path: '^/admin', roles: ROLE_ADMIN }
 
-                # or require ROLE_ADMIN or IS_AUTHENTICATED_FULLY for /admin*
+                # or require multiple roles for /admin* (when defining multiple roles, the behavior depends on the strategy used in Access Decission Manager)
                 - { path: '^/admin', roles: [IS_AUTHENTICATED_FULLY, ROLE_ADMIN] }
 
                 # the 'path' value can be any valid regular expression
@@ -540,7 +540,7 @@ start with ``/admin``, you can:
                 <!-- require ROLE_ADMIN for /admin* -->
                 <rule path="^/admin" role="ROLE_ADMIN"/>
 
-                <!-- require ROLE_ADMIN or IS_AUTHENTICATED_FULLY for /admin* -->
+                <!-- require multiple roles for /admin* (when defining multiple roles, the behavior depends on the strategy used in Access Decission Manager) -->
                 <rule path="^/admin">
                     <role>ROLE_ADMIN</role>
                     <role>IS_AUTHENTICATED_FULLY</role>
@@ -568,7 +568,7 @@ start with ``/admin``, you can:
                 // require ROLE_ADMIN for /admin*
                 ['path' => '^/admin', 'roles' => 'ROLE_ADMIN'],
 
-                // require ROLE_ADMIN or IS_AUTHENTICATED_FULLY for /admin*
+                // require multiple roles for /admin* (when defining multiple roles, the behavior depends on the strategy used in Access Decission Manager)
                 ['path' => '^/admin', 'roles' => ['ROLE_ADMIN', 'IS_AUTHENTICATED_FULLY']],
 
                 // the 'path' value can be any valid regular expression

security/access_control.rst

@@ -44,7 +44,7 @@ Take the following ``access_control`` entries as an example:
                 - { path: '^/admin', roles: ROLE_USER_IP, ip: 127.0.0.1 }
                 - { path: '^/admin', roles: ROLE_USER_HOST, host: symfony\.com$ }
                 - { path: '^/admin', roles: ROLE_USER_METHOD, methods: [POST, PUT] }
-                # when defining multiple roles, users must have at least one of them (it's like an OR condition)
+                # when defining multiple roles, the behavior depends on the strategy used in Access Decission Manager
                 - { path: '^/admin', roles: [ROLE_MANAGER, ROLE_ADMIN] }
 
     .. code-block:: xml
@@ -63,7 +63,7 @@ Take the following ``access_control`` entries as an example:
                 <rule path="^/admin" role="ROLE_USER_IP" ip="127.0.0.1"/>
                 <rule path="^/admin" role="ROLE_USER_HOST" host="symfony\.com$"/>
                 <rule path="^/admin" role="ROLE_USER_METHOD" methods="POST, PUT"/>
-                <!-- when defining multiple roles, users must have at least one of them (it's like an OR condition) -->
+                <!-- when defining multiple roles, the behavior depends on the strategy used in Access Decission Manager -->
                 <rule path="^/admin" roles="ROLE_ADMIN, ROLE_MANAGER"/>
             </config>
         </srv:container>
@@ -97,7 +97,7 @@ Take the following ``access_control`` entries as an example:
                 ],
                 [
                     'path' => '^/admin',
-                    // when defining multiple roles, users must have at least one of them (it's like an OR condition)
+                    // when defining multiple roles, the behavior depends on the strategy used in Access Decission Manager
                     'roles' => ['ROLE_MANAGER', 'ROLE_ADMIN'],
                 ],
             ],
@@ -156,8 +156,13 @@ options:
 
 * ``roles`` If the user does not have the given role, then access is denied
   (internally, an :class:`Symfony\\Component\\Security\\Core\\Exception\\AccessDeniedException`
-  is thrown). If this value is an array of multiple roles, the user must have
-  at least one of them.
+  is thrown). If this value is an array of multiple roles, the user must have:
+  
+  * at least one of them when using the default ``affirmative`` strategy.
+  * more granted than denied roles when using the ``consensus`` strategy.
+  * all of them when using the ``unanimous`` strategy.
+  
+  For more details about different strategies, see :ref:`Access Decision Manager <components-security-access-decision-manager>`.
 
 * ``allow_if`` If the expression returns false, then access is denied;