​
Identities

Email-based ARMS accounts. Access is granted through roles on resources across ARMS products (e.g., inventory, transload, intermodal, mobile).
UsernameIdentifier
Mikeuser:mike@cedx.rail
Kaceyuser:kecey@cedx.rail
Heatheruser:heather@monstersugar.net
Bobuser:bob@monstersugar.net

​
Resources

Equipment, groups, waybills, sites, terminals, operators, workflows, and more. Permissions can be granted at an organization/site/operator level, at a sub‑area (e.g., terminal or group/track), or at an individual resource level.

​
Resource hierarchy and inheritance

Permissions granted at a higher‑level resource are inherited by child resources.
  • Organization / Operator / Site → applies to all sub‑resources below
  • Terminal / Group / Track → applies to resources in that sub‑area only
  • Specific resource → applies only to that one resource

​
Permissions and roles

  • Permissions: service.resource.verb (e.g., inventorymanagement.equipment.list)
  • Roles: collections of permissions
    • Predefined roles (curated)
    • Custom roles (tailored)

​
How IAM works

Policies attach to resources and bind members to roles, with optional conditions. On access, ARMS evaluates the target resource’s policy to allow or deny—consistently across all ARMS modules.

Policy evaluation

Policy = Bindings of { role, members, optional condition }. Conditions use a simplified CEL expression syntax.
IAM diagram

​
Conditions (optional)

Scope access by attributes. Examples: 
{
  "description": "Only BNSF cars",
  "expression": "resource.equipmentInitial == 'BNSF'"
}

{
  "description": "Tracks A or B",
  "expression": "resource.track in ['A','B']"
}