--- schema_version: "1" id: aae7291a71ae155a626d5d04b98eb139284d7b91774161959aa16278c4c516cd title: Identity and Access Management - Patterns collection: architect version: next locale: en-us portal_url: https://docs.salesforce.com/architect/next/en-us/well-architected/guides/trust-identity-access-patterns.md canonical_url: https://staging.architect.salesforce.com/docs/architect/well-architected/guide/trust-identity-access-patterns.html source_site: staging.architect.salesforce.com content_type: documentation content_hash: 089edbf493bdbe80fa4a87e326c378be40f9275bb313331542f21a1c712a486b products: - Well-Architected Framework - Architect Site Content Repo --- # Identity and Access Management - Patterns
Learn more about Well-Architected [Trust](/docs/architect/well-architected/guide/trust.html) → [Identity and Access Management](/docs/architect/well-architected/guide/trust.html#identity-and-access-management) ## Identity as Primary Perimeter **Patterns** | Where to look | What good looks like | | --- | --- | | Platform \| Architecture | ✅ Access controls verify identity explicitly on every request, independent of network location or device | | Platform \| Architecture | ✅ Identity-based security controls replace network-based trust assumptions | | Platform \| Org | ✅ Access decisions consider who is requesting access (authentication), what they are authorized to do (authorization), and context (device, location) | | Platform \| Documentation | ✅ Security architecture documents identity as the primary trust boundary, not network perimeter | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | Platform \| Architecture | ⚠️ Users on corporate network or VPN are assumed trustworthy and granted broader access based on network position alone | | Platform \| Architecture | ⚠️ Access controls rely on network perimeter rather than identity verification | | Platform \| Org | ⚠️ Access decisions do not consider context signals (device, location, time, behavior patterns) | | Platform \| Documentation | ⚠️ Security architecture treats network location as primary trust boundary | ## Salesforce Four-Layer Access Model **Patterns** | Where to look | What good looks like | | --- | --- | | Platform \| Org | ✅ Solutions leverage all four Salesforce access layers: Organization (licenses, features), Object (CRUD), Field (FLS), Record (sharing) | | Platform \| Org | ✅ Access model is designed top-down (org → object → field → record) and validated bottom-up | | Platform \| Org | ✅ Organization-wide defaults (OWD) are set to Private for objects containing sensitive data | | Platform \| Org | ✅ OWDs set to Public Read Only are limited to reference objects (products, price books) where broad visibility supports business without exposing risk | | Platform \| Org | ✅ Organization-level constraints (licenses, IP ranges, login hours, feature permissions) define baseline capabilities for user populations | | Platform \| Org | ✅ Object permissions (via profiles and permission sets) control create, read, edit, and delete access to each object for user segments | | Platform \| Org | ✅ Field-level security protects sensitive fields even when object access is granted | | Platform \| Org | ✅ Record-level sharing uses role hierarchy and sharing rules based on documented business requirements | | Platform \| Org | ✅ Access is expanded deliberately from restrictive baseline, not restricted after permissive defaults | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | Platform \| Org | ⚠️ Access model does not leverage all four layers (organization, object, field, record) | | Platform \| Org | ⚠️ OWDs are set to Public Read/Write for convenience during development without restriction plans | | Platform \| Org | ⚠️ Overly permissive OWDs set early become exponentially harder to restrict as data volume grows and business processes crystallize | | Platform \| Org | ⚠️ Field-level security is not configured, relying solely on object or record-level access controls | ## Authentication Architecture **Patterns** | Where to look | What good looks like | | --- | --- | | Platform \| Org | ✅ Multi-factor authentication (MFA) is enforced for all users accessing production environments (mandatory for UI access) | | Platform \| Org | ✅ MFA is extended to privileged operations including bulk data exports, permission changes, and administrative configuration | | Platform \| Org | ✅ Single sign-on (SSO) uses SAML 2.0 or OpenID Connect protocols | | Platform \| Org | ✅ Session timeout is configured appropriately: 2 hours for standard users, 15-30 minutes for administrators and users accessing Restricted data | | Platform \| Org | ✅ IP restrictions are enforced for administrative profiles and integration users | | Platform \| Org | ✅ Login hours restrict service accounts to expected operational windows | | Platform \| Org | ✅ Native device activation verifies logins from unrecognized devices; MFA and IP restrictions add protection for high-privilege accounts | | Platform \| Org | ✅ If SSO is enabled, approved admin users have direct login access (break-glass procedures) | | Platform \| Org | ✅ The relationship between users and entities logging into Salesforce is 1:1 (no shared user accounts) | | Platform \| Org | ✅ API Access Control prevents users from authenticating via unauthorized connected apps | | Platform \| Named Credentials | ✅ Named credentials and external credentials manage authentication centrally with rotation capabilities | | Platform \| Named Credentials | ✅ Named credentials abstract authentication details from code, enabling credential updates without code changes | | Platform \| Named Credentials | ✅ Credentials are never embedded in code, configuration files, or version control | | Platform \| Apex | ✅ Methods that execute authentication use named credentials to handle username/password flows | | Platform \| Apex | ✅ No usernames or passwords appear in code in readable formats (no hard-coded values or strings) | | Platform \| Aura | ✅ Methods that execute authentication use named credentials to handle username/password flows | | Platform \| Aura | ✅ No usernames or passwords appear in code in readable formats | | Platform \| Lightning Web Components (LWC) | ✅ Methods that execute authentication use named credentials | | Platform \| Lightning Web Components (LWC) | ✅ No usernames or passwords appear in code | | Integration \| API | ✅ OAuth 2.0 JWT bearer flow is used for server-to-server integrations in trusted environments (preferred for production integrations) | | Integration \| API | ✅ OAuth 2.0 web server flow is used for server-to-server integrations requiring user context | | Integration \| API | ✅ OAuth 2.0 device flow is used for headless devices; CLI and CI/CD tooling use web server flow (`sf org login web`) or JWT bearer flow (`sf org login jwt`) — device flow was blocked for the default Salesforce CLI connected app as of Aug 28, 2025 | | Integration \| API | ✅ Username-password OAuth flow is not used; existing integrations that rely on it are migrated to JWT bearer or client credentials flow | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | Platform \| Org | ⚠️ MFA is not enforced for production environment access | | Platform \| Org | ⚠️ Login configurations do not align to Salesforce MFA requirements | | Platform \| Org | ⚠️ MFA is not extended to privileged operations (bulk exports, permission changes, administrative configuration) | | Platform \| Org | ⚠️ Session timeout is not configured or is excessively permissive (>24 hours) | | Platform \| Org | ⚠️ Session policies do not differentiate between standard users and administrators/users accessing Restricted data | | Platform \| Org | ⚠️ IP restrictions are not enforced for administrative profiles and integration users | | Platform \| Org | ⚠️ Service accounts do not have login hours restricted to expected operational windows | | Platform \| Org | ⚠️ High-privilege accounts rely on nothing beyond device activation — no MFA or IP restrictions added | | Platform \| Org | ⚠️ If SSO is enabled, no approved admin users have direct login access (no break-glass procedures) | | Platform \| Org | ⚠️ The relationship between users and entities is not 1:1 (shared user accounts exist) | | Platform \| Org | ⚠️ API Access Control is not enabled | | Platform \| Named Credentials | ⚠️ Credentials are embedded directly in code, configuration files, or version control | | Platform \| Apex | ⚠️ Usernames and passwords appear in code in readable formats | | Platform \| Apex | ⚠️ Authentication is handled ad hoc without consistent implementation | | Platform \| Aura | ⚠️ Authentication is handled ad hoc without named credentials | | Platform \| Aura | ⚠️ Usernames and passwords appear in code | | Platform \| Lightning Web Components (LWC) | ⚠️ Authentication is handled ad hoc without named credentials | | Platform \| Lightning Web Components (LWC) | ⚠️ Usernames and passwords appear in code | | Platform \| Business | ⚠️ User provisioning and deprovisioning SLAs and requirements do not exist | | Integration \| API | ⚠️ Username-password OAuth flow is used when more secure OAuth flows are available | | Integration \| API | ⚠️ OAuth scopes are overly permissive (full access when limited scope is sufficient) | | Integration \| API | ⚠️ Client credentials (client ID, client secret) are stored insecurely in code or config files | ## Authorization and Access Control **Patterns** | Where to look | What good looks like | | --- | --- | | Platform \| Org | ✅ Role hierarchy depth is 5-7 levels maximum (avoiding performance overhead and troubleshooting complexity) | | Platform \| Org | ✅ Permission sets and permission set groups provide flexible, additive access without profile proliferation | | Platform \| Org | ✅ Permission sets grant access for specific job functions, applications, or temporary elevated privileges | | Platform \| Org | ✅ Permission set groups combine related permission sets with muting capabilities for exceptions | | Platform \| Org | ✅ All functional access is granted through permission sets and permission set groups (not profiles), providing flexibility as job roles evolve | | Platform \| Org | ✅ Transaction Security policies extend authorization with real-time contextual evaluation | | Platform \| Org | ✅ Transaction Security policies detect and block anomalous behavior (bulk data downloads exceeding patterns, login from unexpected geographies, permission changes outside change windows) | | Platform \| Org | ✅ IP restrictions are configured for highly sensitive operations or data access | | Platform \| Org | ✅ A unique API-only integration user is configured for every integration | | Platform \| Apex | ✅ All code accessing data enforces CRUD and FLS using WITH USER_MODE, WITH SYSTEM_MODE keywords or Security.stripInaccessible() methods | | Platform \| Apex | ✅ SOQL queries use WITH USER_MODE or WITH SYSTEM_MODE keywords explicitly based on business requirements | | Platform \| Apex | ✅ DML operations use Security.stripInaccessible() for access enforcement before insert/update/upsert operations | | Platform \| Apex | ✅ Database DML statements declare user or system mode explicitly for data operations | | Platform \| Apex | ✅ Database operations use stripInaccessible() methods to filter query and subquery results | | Platform \| Apex | ✅ Sharing keywords (with sharing, without sharing, inherited sharing) are used appropriately based on business security requirements | | Platform \| Design Standards | ✅ Use cases for granting elevated privileges (Modify All Data, View All Data) are clearly documented with business justification | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | Platform \| Org | ⚠️ Role hierarchy is deeper than 5-7 levels, creating performance overhead in sharing calculations and troubleshooting complexity | | Platform \| Org | ⚠️ Role hierarchy grants broad access without business justification | | Platform \| Org | ⚠️ Profiles are cloned repeatedly for minor permission variations, creating dozens of profiles with unclear distinctions | | Platform \| Org | ⚠️ Profiles contain access controls for metadata (should use permission sets) | | Platform \| Org | ⚠️ Transaction Security policies are not implemented to detect anomalous behavior | | Platform \| Org | ⚠️ IP restrictions are not configured for highly sensitive operations or data access | | Platform \| Org | ⚠️ API-only users are not configured or are shared across multiple integrations | | Platform \| Org | ⚠️ View All Data or Modify All Data permissions are granted without documented justification | | Platform \| Apex | ⚠️ SOQL/SOSL queries and DML operations run in default system mode without explicit access checks | | Platform \| Apex | ⚠️ CRUD and FLS enforcement is inconsistent or missing | | Platform \| Apex | ⚠️ SOQL relies on WITH SECURITY_ENFORCED, which has been removed and now causes a compilation error (replace with WITH USER_MODE) | | Platform \| Apex | ⚠️ Sharing keywords are used inconsistently or not at all | | Platform \| Design Standards | ⚠️ Use cases for granting elevated permissions are not clearly documented | ## Attribute-Based Access Control (ABAC) and Data 360 **Patterns** | Where to look | What good looks like | | --- | --- | | Platform \| Data 360 | ✅ RBAC (roles, profiles, permission sets) controls platform access (who can use Data 360), ABAC controls data access (what data they see based on attributes) | | Platform \| Data 360 | ✅ AI agents execute in the requesting user's context (on-behalf-of), so agent-generated queries are constrained by that user's access rather than running with system-level access | | Platform \| Documentation | ✅ Data classification taxonomy is documented with attribute definitions, enforcement rules, and business justification | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | Platform \| Data 360 | ⚠️ Access that must follow data classification is forced through role hierarchy and sharing, which cannot express it, instead of reaching for attribute-based access control | | Platform \| Data 360 | ⚠️ FLS bypass: users without field-level access retrieve data via API or SOQL queries that don't enforce FLS | | Platform \| Data 360 | ⚠️ AI agents query data without executing in the requesting user's context; agent-generated queries bypass object-, field-, and record-level access controls | | Platform \| Data 360 | ⚠️ Agent execution context does not include user-on-behalf-of attributes; agents operate with system-level access | | Platform \| Documentation | ⚠️ Data classification taxonomy is undocumented; attribute definitions vary by team creating inconsistent enforcement | ## Critical Impact Accounts **Patterns** | Where to look | What good looks like | | --- | --- | | Platform \| Org | ✅ Critical impact accounts (system administrators, integration users, automated process accounts) are identified and tracked in asset inventory | | Platform \| Org | ✅ Critical impact accounts represent high-value targets due to elevated privileges providing broad platform access | | Platform \| Org | ✅ Hardware security keys or authenticator apps are required for MFA (not SMS, which is vulnerable to SIM swapping) | | Platform \| Org | ✅ Login IP ranges are restricted to known administrative locations | | Platform \| Org | ✅ Login alerts and permission change notifications are enabled | | Platform \| Org | ✅ Quarterly access reviews are conducted with documented attestation | | Platform \| Org | ✅ Break-glass procedures exist for emergency access with post-use audit | | Integration \| Service Accounts | ✅ OAuth flows are used for integration and service accounts (never username-password) | | Integration \| Service Accounts | ✅ IP restrictions are enforced for integration users | | Integration \| Service Accounts | ✅ Credential rotation schedules are implemented (quarterly or per policy) | | Integration \| Service Accounts | ✅ Anomalous API usage patterns are monitored through Event Monitoring | | Integration \| Service Accounts | ✅ Each integration has a dedicated service account with minimum required permissions (not shared "integration user" with broad access) | | Integration \| Service Accounts | ✅ Service accounts apply least privilege rigorously since they operate unattended | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | Platform \| Org | ⚠️ Critical impact accounts (admin, integration, automation) are not identified, tracked, or inventoried | | Platform \| Org | ⚠️ System administrators use SMS-based MFA instead of hardware security keys or authenticator apps | | Platform \| Org | ⚠️ Critical impact accounts have no login hour or IP restrictions | | Platform \| Org | ⚠️ No alerts are configured for login or permission changes on privileged accounts | | Platform \| Org | ⚠️ Critical impact account access is never reviewed or reviewed irregularly (not quarterly) | | Platform \| Org | ⚠️ No break-glass procedures exist for emergency access | | Integration \| Service Accounts | ⚠️ A single "API User" account is shared across multiple integrations with Modify All Data permission | | Integration \| Service Accounts | ⚠️ Service accounts use username-password authentication when OAuth is available | | Integration \| Service Accounts | ⚠️ Service account credentials use static passwords unchanged for years (no rotation) | | Integration \| Service Accounts | ⚠️ Service accounts have excessive privileges beyond what integration requires | | Integration \| Service Accounts | ⚠️ Anomalous API usage patterns for service accounts are not monitored | ## Identity Lifecycle Management **Patterns** | Where to look | What good looks like | | --- | --- | | Platform \| Process | ✅ Identity lifecycle includes: Provisioning (create with baseline access), Access adjustment (grant/revoke as roles change), Periodic recertification (quarterly validation), Deprovisioning (immediate revocation) | | Platform \| Org | ✅ SCIM (System for Cross-domain Identity Management) is implemented for automated provisioning from identity providers | | Platform \| Process | ✅ Provisioning creates accounts with baseline access matching job function, triggered by HR system events | | Platform \| Process | ✅ Access adjustment grants additional permissions as roles expand and revokes permissions when roles change | | Platform \| Process | ✅ Periodic recertification occurs quarterly where managers review and validate access for their teams | | Platform \| Process | ✅ Deprovisioning revokes access immediately when employment ends or role no longer requires Salesforce | | Platform \| Org | ✅ Automated detection identifies users who have not logged in within 90 days and triggers access review workflows | | Platform \| Org | ✅ Just-in-time (JIT) provisioning creates users automatically from SSO when appropriate | **Anti-Patterns** | Where to look | What bad looks like | | --- | --- | | Platform \| Org | ⚠️ SCIM provisioning is not implemented despite having identity provider integration | | Platform \| Process | ⚠️ New users are created manually without standard onboarding procedures | | Platform \| Process | ⚠️ Initial user access is inconsistent or based on copying existing users | | Platform \| Process | ⚠️ Access changes for role changes or transfers are delayed or incomplete | | Platform \| Process | ⚠️ Offboarding is delayed; former employees retain access after termination (not same-day deactivation) | | Platform \| Org | ⚠️ No automation exists for user provisioning (manual user creation only) | | Platform \| Process | ⚠️ No access recertification campaigns exist (no quarterly or annual review) | | Platform \| Process | ⚠️ Unnecessary access identified during recertification is not removed | | Platform \| Process | ⚠️ Access recertification is not rigorous for privileged accounts, cross-org access, external users | | Platform \| Org | ⚠️ Dormant accounts (no login in 90+ days) accumulate without review or deactivation |