Security¶

Access Levels¶

Access can be granted to a user for a certain resource on several levels. The lowest level is the User level. Being on this level means that users can only access resources that have been assigned to them. At the other end of the hierarchy is the System level. Users at this level have the permission to access all records within the whole system without exception. The security bundle comes with the following five levels (ordered up from the bottom of the hierarchy):

Each record is associated with an owning organization. When a user logs into the system, they work in the scope of one of their organizations. If a user is a member in several organizations, they can switch the organization scope that is used to perform access checks.

Permissions¶

A user can be assigned different modes to a resource. These modes describe what they are allowed to do with the resource. Namely, these permissions are:

Restricting Access to Controller Methods¶

Let us assume that you have configured an entity to be protectable via ACLs. You have granted some of its objects to a set of users. Now you can now control who can enter certain resources through the controller method. Restricting access can be done in two different ways:

1. Use the @Acl annotation on a controller method, providing the entity class name and the permission to check for:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

   // src/Acme/DemoBundle/Controller/ProductController.php namespace Acme\DemoBundle\Controller; use Oro\Bundle\SecurityBundle\Annotation\Acl; use Symfony\Bundle\FrameworkBundle\Controller\Controller; class ProductController extends Controller { /** * @Acl( * id="product_edit", * type="entity", * class="AcmeDemoBundle:Product", * permission="EDIT" * ) */ public function editAction() { // ... } }

2. When you need to perform a particular check repeatedly, writing @Acl over and over again becomes a tedious task. This becomes even a more serious issue when your requirements change and you have to change a lot of ACLs. Luckily, you can configure an ACL globally in your bundle configuration and refer to using the ACL id using the @AclAncestor annotation.

   The ACL configuration from the example above looks like this:

   1 2 3 4 5 6

   # src/Acme/DemoBundle/Resources/config/oro/acls.yml acls: product_edit: type: entity class: AcmeDemoBundle:Product permission: EDIT

   The annotation of your controller method becomes a lot smaller then:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

   // src/Acme/DemoBundle/Controller/ProductController.php namespace Acme\DemoBundle\Controller; use Oro\Bundle\SecurityBundle\Annotation\AclAncestor; use Symfony\Bundle\FrameworkBundle\Controller\Controller; class ProductController extends Controller { /** * @AclAncestor("product_edit") */ public function editAction() { // ... } }

   Sometimes you want to protect a controller method coming from code that you do not control. Therefore, you cannot add the @AclAncestor annotation to it. Use the bindings key in the YAML configuration of your ACL to define which method(s) should be protected:

   1 2 3 4 5 6 7 8 9

   # src/Acme/DemoBundle/Resources/config/oro/acls.yml acls: product_edit: type: entity class: AcmeDemoBundle:Product permission: EDIT bindings: - class: Acme\DemoBundle\Controller\ProductController method: editAction

Using Param Converters¶

When the @Acl annotation is used without a param converter, the user’s permission is checked on the class level. This means that the user is granted access as long as their access level is not NONE.

When using the @ParamConverter annotation from the SensioFrameworkExtraBundle together with the @Acl annotation, the routing parameters are first converted into the corresponding Doctrine entity object. Then, access will be checked based on the queried object.

Data Grids¶

Records that are part of a data grid are automatically protected by the OroSecurityBundle. View permissions are attached to each record of the data grid.

Protecting Custom DQL Queries¶

When building custom Doctrine DQL queries, you may want to reduce the result set being returned to the set of domain objects the user is granted access to. To achieve this, use the ACL helper provided by the OroSecurityBundle:

// src/Acme/DemoBundle/Controller/DemoController.php
namespace Acme\DemoBundle\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\Controller;

class DemoController extends Controller
{
    public function protectedAction()
    {
        $repository = $this->getDoctrine()->getRepository('AcmeDemoBundle:Product');
        $queryBuilder = $repository
            ->createQueryBuilder('p');
            ->where('p.price > :price')
            ->orderBy('p.price', 'ASC')
            ->setParameter('price', 19.99);
        $aclHelper = $this->get('oro_security.acl_helper');
        $query = $aclHelper->apply($queryBuilder, 'VIEW');

        // ...
    }
}

In this example, first, a query is built that selects all products from the database which are more expensive than 19.99 order by their price. Then, the query builder is passed to the apply() method of the oro_security.acl_helper service. This service, an instance of the AclHelper class, modifies the query only to the return entities the user has access to.

Manual Access Checks¶

If you need to manually check the access of the current user to a certain object, you can use the isGranted() method from the security.authorization_checker service for this:

// src/Acme/DemoBundle/Controller/DemoController.php
namespace Acme\DemoBundle\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\Security\Core\Exception\AccessDeniedException;

class DemoController extends Controller
{
    public function protectedAction()
    {
        $entity = ...;

        if (!$this->isGranted('VIEW', $entity)) {
            throw new AccessDeniedException();
        }

        // ...
    }
}

User Ownership¶

Imagine that each user created two accounts (one in Main Organization and one in Second Organization):

The users can now access the accounts depending on the organization context they login into as described below:

Business Unit Ownership¶

When the ownership type is “Business Unit”, access cannot be granted on the user level. The minimum acccess level is the Business Unit level.

Imagine that the following data has been created:

The users can now access the accounts as described below:

Organization Ownership¶

When the ownership type is “Organization”, access cannot be granted on the user level, the business level or the division level. The minimum acccess level is the Organization level.

Imagine that the following data has been created:

The users can now access the accounts as described below: