Skip to main content

Domain model integrity

Problem​

  1. You use actors and/or nodes to store domain specific information
  2. You want to ensure that only valid data is stored in the actors and nodes. Both in custom parts like customStatus and customAttributes and in the standard parts like name, description and type
  3. You want to protect the calls to Akkess from your frontend application to ensure that only valid data is stored in the actors and nodes

Examples​

Only allowed values for Node type are 'STORE', 'DEPARTMENT', 'GROUP' and 'BUILDING'

Custom Id 'VIN' must be a valid Vehicle Identification Number

Custom status 'STATUS' must be one of 'ENABLED', 'DISABLED', 'DELETED'

Custom attribute 'METRICS' must be a valid JSON object according to your metrics Json-schema

Solution​

  1. Create a facade backend service that validates the data before storing it in the actors and nodes.
  2. Setup Akkess Application Firewall to only allow calls from your backend service. Configure the backend facade to use the application firewall key when doing calls to Akkess.
  3. If needed - setup support roles that have permission to call the Akkess directly for example using the Akkess Tenant Console. The support roles are privileged roles that can be used to fix incorrect data.
  4. If preferred - use your own DTOs as API and map them to Akkess DTOs in the backend service to take a more clear ownership of your API
  5. Akkess also has some built in rules. Like only allow a role to use certain actor and node type. Like Role X is only allowed to create actors of type 'A' and 'B'.

Abbreviations​

  • FE - Customer made frontend application
  • BE - Customer made backend service
  • DTO - Data Transfer Object (data sent forth and back between FE and BE)

Use ActorV1 and NodeV1 as API​

Use a BE service to validate the data before storing it in the actors and nodes. This ensures that your business rules are followed and that the data is correct.

The BE service is totally stateless and only responsible for validating the data before storing it in the actors and nodes.

Note that the FE's Akkess token is used when BE is calling Akkess. This will ensure that only allowed operations will be done. You can let Akkess handle all the access control.

Use your own DTOs as API​

To take it even one level more - to not leak knowledge about that Akkess is used behind the scenes, the BE service could own the API and its DTO definitions and does not expose any Akkess specific information in the responses.

For example : Instead of returning ActorV1 to the FE, the BE service could return a DTO called UserV1 and represent the user in the system.

Support roles​

The Application Firewall can be configured to allow direct calls without using a firewall key. This can be used to allow certain roles to call the Akkess APIs directly.

Conclusion​

By putting a backend facade between "Internet" and Akkess you can implement a custom API with validation and custom business rules evaluation and still let Akkess handle stuff like hierarchical access control and data storage.

Copyright © 2019 Akkess