The Registry Authnz process starts in RegistryAuthComponent which injects a beforeFilter callback into all requests.
- For all requests, RegistryAuthComponent first looks for a
willHandleAuth
function in the target controller. If present, this function can be used by the controller to indicate how it wants to handle authentication and authorization, by returning one of the following strings:authz
: The controller will handle authorization (but not authentication)- The controller should not attempt to perform authorization here, as authentication has not yet taken place
open
: The current request is for a public resource that does not require authentication (eg: PagesController)yes
: The controller will handle both authentication and authorization- If the controller returns
yes
, the expectation is that authnz has already been performed
- If the controller returns
notauth
: The controller has attempted to perform authnz, but failed, so the request is not authorizedno
: The controller will not handle either authentication or authorization, the standard logic should be used
- If
willHandleAuth
returnsopen
oryes
, RegistryAuthComponent returns control to the target controller. Ifnotauth
was returned, an authorization failure is returned. Otherwise, processing continues. - For API requests, RegistryAuthComponent will perform authentication of the API user. If successful, authorization is processed, either natively in RegistryAuthComponent ("standard authorization"), or via the controller if
willHandleAuth
returnedauthz
. - For UI requests
- If there is no authenticated user in the session, control is handed off to TrafficController to trigger a login flow. This process is described in further detail here. Once completed, TrafficController will redirect to the original resource, which will restart the RegistryAuthComponent process, which will pick up at the next step.
- Once there is an authenticated user, authorization is processed. If
willHandleAuth
returnedauthz
, this will be done via the controller, otherwise the standard authorization process will be followed.
Authenticated Identifiers
API Users are bound to specific COs.
For UI logins, the authenticated identifier is mapped to Identifiers flagged for login attached to Person records. A given identifier may be valid in more than one CO.
Standard Authorization
Standard authorization is performed in RegistryAuthComponent based on the rules established within each table. Each table sets an array of permissions using PermissionsTrait::setPermissions
, either directly as an array or as a closure that returns an array. The array has two required keys, entity
and table
, and one optional key, related
.
entity and table are each a hash where the keys are actions that operate over entities (ie: requiring an $id
) or tables, respectively. The values are either false
, indicating that action is never permitted, or an array of roles representing who is authorized to perform the action. Defined roles are
coAdmin
coMember
platformAdmin
related, if provided, is an array (list) of models whose permissions are required, typically for table views to render related actions.
When a closure is provide, the expected function signature of the closure is
function (\Cake\Http\ServerRequest $r, \App\Controller\Component\RegistryAuthComponent $auth, ?int $id): array
StandardController also provides the permissions calculated by RegistryAuthComponent to views.