Module 2docs/iam/identities

Identity Management & Provisioning

Name: SoldierX AI SIEM
Brand: SoldierX

Identity management in SoldierX AI SIEM governs how analysts, engineers, and administrators are onboarded, assigned to organizational units, and governed through their lifecycle.

Team Member Provisioning

Inviting someone new requires the iam:user:create action. The invite form asks for their email first; if they don't already have an account, it expands into a short registration:

Field	Notes
Email	Asked first, before anything else. If the address already has an account, the rest of the registration fields don't appear.
Name	Display name shown throughout the product.
Phone number	Auto-detects the country/dial code as it's typed.
Password	A live strength meter checks five rules as you type: 8+ characters, an uppercase letter, a lowercase letter, a number, and a special character.

Roles, groups, and direct policies are not assigned at invite time - they're attached afterward from the user's own detail page, using iam:user:attachRole, iam:user:attachGroup, or iam:user:attachPolicy.

Visible, but not always openable

In the Users list, an account you don't hold view rights for still shows up, so you know it exists, but its row is visually disabled and unclickable rather than hidden entirely.

User Group Architecture

User Groups are structural administrative containers. They streamline permission management by allowing administrators to grant, modify, or revoke permissions for dozens of operators in a single operation.

STANDING ACCESS ONLY

User Groups grant permanent, standing access. Unlike Assumable Roles, groups cannot be "assumed" or toggled on and off; their attached policies are continuously included in the mathematical union of identity grants.

iam:group:create

Creates a new named group container inside the subscription.

iam:group:attachPolicy

Attaches managed policies directly to the group container.

iam:user:attachGroup

Adds a team member as a member of the group, inheriting its policies.

Revoking Access

There is no separate account-deactivation toggle. Offboarding a team member or narrowing a contractor's access means detaching what was granted, using the same attach actions in reverse:

iam:user:detachRole

Removes a standard or assumable role from the user.

iam:user:detachGroup

Removes the user from a group, dropping the group's inherited policies.

iam:user:detachPolicy

Removes a policy attached directly to the user.

Every removal is confirmed first

Every attach, detach, or membership change in IAM requires an explicit confirmation step. The confirmation dialog names exactly which modules of the product would be affected by the change before you commit to it, so you're never guessing at the blast radius of an access change.

Direct Policy Attachments vs. Group and Role Inheritance

A team member's real, working set of permissions is the union of everything granted by every policy attached to them directly, through every group they belong to, and through every role they hold. An explicit denial always wins: if any attached policy denies an action, that denial overrides any allow from anywhere else. Beyond the user's own attached policies, an organization-wide guardrail and the user's own permission ceiling (if one is set) can further restrict, but never expand, what they can do.

The Effective Permissions panel on a user's detail page shows, module by module, exactly what that person can and can't do, and for each permission, which policy granted it, which denied it, or which guardrail blocked it.

Identity Access Troubleshooting Runbook

If an operator reports missing UI buttons or HTTP 403 Forbidden errors, follow these diagnostic steps:

Open the Effective Permissions panel: Navigate to IAM > Users > [User] > Effective Permissions. Inspect the exact action string (e.g., siem:case:update).
Verify the prerequisite read action: Check if the corresponding read action (e.g., siem:case:read) is also granted. A mutation action without its read dependency is a flagged, likely-unusable grant.
Check the Permission Ceiling (Boundary): If a ceiling is attached, confirm the requested action is within what the ceiling permits.
Scan for an explicit Deny: Check every group, role, and direct policy for a Deny statement covering the action. A single explicit deny overrides all allows from anywhere else.