2026-08-18 - Backend User and RBAC Data

From Izara Wiki
Jump to navigation Jump to search

User Data Handling

Overview

How to pass around userId and targetIdentifiers for permissions/account limits/resource use, and for creating automatic data such as createdBy and belongTo relationships in graph database.

updated idea

  • baseUserId can stay in _izContext because it should not change during processing
  • maybe change baseUserId to submittedByUserId to be more clear, but see baseUserId reason for name below
  • however consider if future flows will handle many submittedByUserIds, eg automated tasks that handle many submitted tasks, if that is common it might be better to allow generated code to pass the submittedByUserId as a flow input param
  • targetId change to identifer object {fieldname: fieldValue} named targetIdentifiers
  • generated code can where possible add this automatically when initializing flows, and can check received valid identifiers according to flowSchema

RBAC

  • RBAC actions are basically list of flows, with target coming from the flows base objType (using either that objTypes rbac additional addOnDataStructure or if that objType has belongTo following that)
  • generated code automatically validates submittedByUserId and targetIdentifiers, sends to permissionHandler/RBAC

Account Limits

  • standardize checking of accountLimits so generated code can check per flow
  • probably allow for additional developer added accountLimits to be checked anywhere in code

Resource use

  • ? connected to target user if belongTo = user, but if not connect to submittedByUserId

old attempts

First design

  • url paths sent from frontend had the service/resource/action and targetId in the url path, extracted by API Gateway
  • submittedBy userId was extracted/confirmed from the Cognito token/sub
  • RBAC was handled by a Lambda authorizer that used the above extracted variables
  • submittedBy and targetIds were saved into iz_Context and automatically passed to proceeding logic

limitations

  • requests must pass API Gateway to extract values
  • Lambda authorizers can have limitations that complicated processing

Second design

  • using schemas and generated code
  • RBAC moved out of authorizers and implemented inside handler lambdas
  • still in _izContext
  • variable name is baseUserId, because accountLimits/resourceUse are connected to target userId if belong to User, but baseUserId if not

limitations

  • targetId is a concat string for composite identifiers, want all handling of identifiers to be an object, only change to concat when required (eg save to database that requires single string)
  • some flows might need to adjust target according to steps, eg importBatch submission belongTo user but each pending element may have different belongTo objType/instances, this complicates targetId management in _izContext
Retrieved from "https://izara.io/wiki/index.php?title=2026-08-18_-_Backend_User_and_RBAC_Data&oldid=4607"