User Data Handling

Overview

submittedByUserId and targetIdentifiers for permissions/account limits/resource use, and for creating automatic data such as createdBy and belongTo relationships in graph database.

Structure

• baseUserId can stay in iz_Context because it should not change during processing
• targetUserId maybe no longer needed, moves to targetIdentifiers for flows where objType is user or belongsTo user
• 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

Graph

• automatically adds createdBy/versionData updatedBy relationships for objects created/updated by user
• automatically adds createdBy/updatedBy for relationships created/updated by user, relationshipSchema specifies which node to connect this history to
• automatically adds belongTo relationship when creating a node connecting to targetIdentifiers instance of belongTo objType
• relationshipSchema sets which side is belongTo node, that node must have belongTo relationship (ie that node must have belongTo or rbac addOnDataStructure)

RBAC

• RBAC actions are fixed to flowTypes
• RBAC is only checked on initiated by user|systemWithUserId flows
• target/targetIdentifiers are required according to flowTypes base objType (using either that objTypes rbac addOnDataStructure or if that objType has belongTo following that)
• flows that are initiated by user|systemWithUserId but do not have belongTo/rbac check thier permissions from projectLevel RBAC
• flows that are initiated by user|systemWithUserId and have belongTo/rbac check thier permissions from objectLevel RBAC according to target
• generated code automatically validates submittedByUserId and targetIdentifiers, passing permissionHandler/RBAC and AccountLimits

Project level RBAC service

• previously called appLevel
• each user has projectLevel roles, eg basicUser, verifiedUser, AdminUser, restrictedUser
• when a new user is created automatically gets assigned a role/s, eg: basicUser
• roles set in projectLevel RBAC are also used by projectLevel AccountLimits

Object level RBAC

• any objType that has addOnDataStructure rbac setting automatically creates rbac resources/endpoints in that objType's service
• when entering a flow generated code checks if the flow has objType that belongsTo/has rbac and sends to the target objType service rbac endpoint
• when a user creates an object instance of objType with objectLevel rbac, an admin role is automatically created with allow permission for all actions associated with that objType and all objTypes that belongTo it, and the creating user is given that role
• mayb need to create an S3 schema per rbac objType with all flows that point to it

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

Project level Account Limits

• uses roles from projectLevel rbac
• defines limits for that users actions, eg for their own account
• if target is user objType and targetIdentifiers matches submittedBy userid, only check accountLimits target limit (same as submittedBy user)

= Add increase/decrease action

• currently account limits will find the highest limit of all roles attached to a customer
• if some roles are limiting, eg restrictedUser, want to be able to limit account limit
• could add increase/decrease action to each limit
• if action is increase find the highest limit
• if any limit has decrease action force limit to equal the lowest decrease limit, ignoring increase limits
• might need to do a check that the highest increase limit is lower than the lowest decrease limit, return the lowest of the two

Resource use

• is used for billing
• if apply resource use to target does not work for non-billable objects like deliveryMethod
• if apply to submitted user does not work for billable objects like business/organization/operation
• consider having a setting in object schema for addOnDataStructure rbac whether object is billable object
• any flow with objType have belongTo/rbac and billable set true, resource use attaches to target
• any flow objType not set billable and initiated by user|systemWithUserId, resource use attaches to submittedBy user
• any flow not have objType but initiated by user|systemWithUserId resource use is charged to submittedBy user

Creating objects

• creating objects that have belongTo must check RBAC and AccountLimits for target
• creating objects that have addOnDataStructure rbac must check projectLevel RBAC and AccountLimits for submittedBy userid
• creating objects that not have belongTo and not have addOnDataStructure rbac must check projectLevel RBAC and AccountLimits for submittedBy userid

Example Flow handling

userId, belongTo rbac, billable

• check projectLevel rbac for target
• check objectLevel rbac for target+user (unless target objType is user)
• check projectLevel account limit for target
• check objectLevel account limit for target+user (unless target objType is user)
• resource use to target

systemNoUserId, belongTo rbac, billable

• no rbac
• no account limit
• resource use to target

userId, no belongTo

• check projectLevel rbac for user
• check projectLevel account limit for user
• resource use to user

systemNoUserId, no belongTo

• no rbac
• no account limit
• no resource use

userId, belongTo rbac, not billable

• check projectLevel rbac for target
• check objectLevel rbac for target+user (unless target objType is user)
• check projectLevel account limit for target
• check objectLevel account limit for target+user (unless target objType is user)
• resource use to user

systemNoUserId, belongTo rbac, not billable

• no rbac
• no account limit
• no resource use

userId, no belongTo

• check projectLevel rbac for user
• check projectLevel account limit for user
• resource use to user

systemNoUserId, no belongTo

• no rbac
• no account limit
• no resource use

Considerations

userLevel rbac

• connected to user objType
• no admin role with permissions is created automatically when create new user, unlike other objTypes with addOnDataStructure rbac
• if submittedUserId matches targetIdentifers not need to check objectLevel RBAC/objectLevel AccountLimits

Ideas

Remove RBAC

• We could mimic RBAC functionality in AccountLimits
• set action limit to 0 for no permission
• unable to do this yet because rbac includes flow param filters, allowing permissions to limit to eg specific object instances

Working documents

User Data Handling