When any of the authentication providers (see Authentication Providers)
has verified the still-unauthenticated token, an authenticated token will
be returned. The authentication listener should set this token directly
in the Symfony\Component\Security\Core\SecurityContextInterface
using its setToken()
From then on, the user is authenticated, i.e. identified. Now, other parts
of the application can use the token to decide whether or not the user may
request a certain URI, or modify a certain object. This decision will be made
by an instance of Symfony\Component\Security\Core\Authorization\AccessDecisionManagerInterface.
An authorization decision will always be based on a few things:
The current token
For instance, the token’s getRoles()
method may be used to retrieve the roles of the current user (e.g.
ROLE_SUPER_ADMIN), or a decision may be based on the class of the token.
A set of attributes
Each attribute stands for a certain right the user should have, e.g.
ROLE_ADMIN to make sure the user is an administrator.
An object (optional)
Any object for which access control needs to be checked, like
an article or a comment object.
Since deciding whether or not a user is authorized to perform a certain
action can be a complicated process, the standard Symfony\Component\Security\Core\Authorization\AccessDecisionManager
itself depends on multiple voters, and makes a final verdict based on all
the votes (either positive, negative or neutral) it has received. It
recognizes several strategies:
grant access as soon as there is one voter granting access;
grant access if there are more voters granting access than there are denying;
only grant access if none of the voters has denied access;
useSymfony\Component\Security\Core\Authorization\AccessDecisionManager;// instances of Symfony\Component\Security\Core\Authorization\Voter\VoterInterface$voters=array(...);// one of "affirmative", "consensus", "unanimous"$strategy=...;// whether or not to grant access when all voters abstain$allowIfAllAbstainDecisions=...;// whether or not to grant access when there is no majority (applies only to the "consensus" strategy)$allowIfEqualGrantedDeniedDecisions=...;$accessDecisionManager=newAccessDecisionManager($voters,$strategy,$allowIfAllAbstainDecisions,$allowIfEqualGrantedDeniedDecisions);
this method will do the actual voting and return a value equal to one
of the class constants of Symfony\Component\Security\Core\Authorization\Voter\VoterInterface,
i.e. VoterInterface::ACCESS_GRANTED, VoterInterface::ACCESS_DENIED
The Security component contains some standard voters which cover many use
voter supports the attributes IS_AUTHENTICATED_FULLY, IS_AUTHENTICATED_REMEMBERED,
and IS_AUTHENTICATED_ANONYMOUSLY and grants access based on the current
level of authentication, i.e. is the user fully authenticated, or only based
on a “remember-me” cookie, or even authenticated anonymously?
useSymfony\Component\Security\Core\Authentication\AuthenticationTrustResolver;$anonymousClass='Symfony\Component\Security\Core\Authentication\Token\AnonymousToken';$rememberMeClass='Symfony\Component\Security\Core\Authentication\Token\RememberMeToken';$trustResolver=newAuthenticationTrustResolver($anonymousClass,$rememberMeClass);$authenticatedVoter=newAuthenticatedVoter($trustResolver);// instance of Symfony\Component\Security\Core\Authentication\Token\TokenInterface$token=...;// any object$object=...;$vote=$authenticatedVoter->vote($token,$object,array('IS_AUTHENTICATED_FULLY'));
supports attributes starting with ROLE_ and grants access to the user
when the required ROLE_* attributes can all be found in the array of
roles returned by the token’s getRoles()
and provides some additional functionality: it knows how to handle a
hierarchy of roles. For instance, a ROLE_SUPER_ADMIN role may have subroles
ROLE_ADMIN and ROLE_USER, so that when a certain object requires the
user to have the ROLE_ADMIN role, it grants access to users who in fact
have the ROLE_ADMIN role, but also to users having the ROLE_SUPER_ADMIN
Roles are objects that give expression to a certain right the user has.
The only requirement is that they implement Symfony\Component\Security\Core\Role\RoleInterface,
which means they should also have a getRole()
method that returns a string representation of the role itself. The default
Symfony\Component\Security\Core\Role\Role simply returns its
first constructor argument:
useSymfony\Component\Security\Core\Role\Role;$role=newRole('ROLE_ADMIN');// will show 'ROLE_ADMIN'var_dump($role->getRole());
Most authentication tokens extend from Symfony\Component\Security\Core\Authentication\Token\AbstractToken,
which means that the roles given to its constructor will be
automatically converted from strings to these simple Role objects.
The access decision manager can be used at any point in a request to decide whether
or not the current user is entitled to access a given resource. One optional,
but useful, method for restricting access based on a URL pattern is the
which is one of the firewall listeners (see Firewall Listeners) that
is triggered for each request matching the firewall map (see A Firewall for HTTP Requests).
It uses an access map (which should be an instance of Symfony\Component\Security\Http\AccessMapInterface)
which contains request matchers and a corresponding set of attributes that
are required for the current user to get access to the application:
The access decision manager is also available to other parts of the application
via the isGranted()
method of the Symfony\Component\Security\Core\SecurityContext.
A call to this method will directly delegate the question to the access