The Registry Authnz process starts in RegistryAuthComponent which injects a beforeFilter callback into all requests.

  1. 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
    • notauth: The controller has attempted to perform authnz, but failed, so the request is not authorized
    • no: The controller will not handle either authentication or authorization, the standard logic should be used
  2. If willHandleAuth returns open or yes, RegistryAuthComponent returns control to the target controller. If notauth was returned, an authorization failure is returned. Otherwise, processing continues.
  3. 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 returned authz.
  4. For UI requests
    1. 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.
    2. Once there is an authenticated user, authorization is processed. If willHandleAuth returned authz, 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.

See Also

  • No labels