The documentation you are viewing is for an older version of this component.
Switch to the latest (v4) version.
Whenever you request an authorization check on the authenticated identity, the identity will be provided to the AuthorizationService through a registered IdentityProviderInterface service.
This is because identity is authentication-dependent, so the module lets you overwrite this service, depending on your needs.
If you want to get the identity from other sources instead of the dot-authentication service, overwrite the IdentityProviderInterface::class service in the service manager with your own implementation of this interface.
Write your own role provider by implementing the RoleProviderInterface and register it in the RoleProviderPluginManager.
After that, you can use them in the configuration file, as described above.
Assertions are checked after permission is granted, right before returning the authorization result.
Assertions can have the last word in deciding if someone is authorized for the requested action.
A good assertion example could be an edit permission, but with the restriction that it should be able to edit the item just if the user id matches the item's owner id.
It is up to you to write the logic inside an assertion.
An assertion has to implement the AssertionInterface and be registered in the AssertionPluginManager.
This interface defines the following method
public function assert(AuthorizationInterface $authorization, $context = null);
The context variable can be any external data that an assertion needs to decide the authorization status. The assertion must return a boolean value, reflecting the assertion pass or failure status.