Identity, access and permissions

Treat access as several distinct decisions

An ADOM project, its connected sources and the delivered application each have their own access boundary. Granting access to one does not imply approval for the others. Establish who may view work, make changes, administer the environment and authorize releases.

Apply least privilege in the proposed environment

Give people and service identities the access needed for the approved work. Separate read access from changes, and development permissions from production authority. Scope credentials to the intended systems and operations. Use the organization’s approved identity and credential-management arrangements; confirm the available identity-provider integration during onboarding.

Verify the permissions with realistic tests

• A permitted user can complete the intended workflow.
• An unauthorized role cannot perform the same action.
• A user cannot reach another project or organization’s restricted information through a direct link or request.
• Revocation removes access within the agreed operating process.
• Sensitive administrative and release actions are limited to the intended owners.

Manage access through the project lifecycle

Review access when someone joins, changes responsibility or leaves. Name an owner for credentials, rotation and removal. Record which identities are used for integrations and deployment so access can be withdrawn without relying on a former team member’s personal account.

The application’s visible navigation is not the security boundary. Acceptance should include denied operations as well as the screens a role is expected to see.