This page explains the conceptual foundation of IAM. To manage these concepts in practice, use the Admin Portal.
Identities
- Users
- Groups
- Example resources
Email-based ARMS accounts. Access is granted through roles on resources across ARMS products (e.g., inventory, transload, intermodal, mobile).
| Username | Identifier | |
|---|---|---|
 | Mike | user:[email protected] |
 | Kacey | user:[email protected] |
 | Heather | user:[email protected] |
 | Bob | user:[email protected] |
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.