Identity, Access, and Security Architecture
Identity, Access, and Security Architecture
This domain tests whether you can separate authentication from authorization, build a least-privilege model that survives external users and scale, and protect data at rest and in transit without breaking business processes.
Authentication
Single sign-on via SAML or OIDC, with My Domain required for SSO and for login flows. MFA for all internal and privileged users. Login flows support step-up authentication and terms acceptance. Connected apps carry OAuth scopes, IP restrictions, and session policies - scope creep here is a real vulnerability. Consider delegated authentication only for legacy directories you cannot retire.
Authorization
- Organization-wide defaults set the baseline; everything else loosens it.
- Role hierarchy grants internal vertical access; it does not apply to external users.
- Sharing rules (criteria-based and owner-based), teams, manual sharing, and Apex managed sharing extend access.
- Restriction rules and scoping rules narrow what a user sees without changing their permissions.
- Profiles provide a baseline; permission sets and permission set groups add capability; muting permission sets remove it inside a group.
- Apply least privilege and segregation of duties deliberately.
- Guest users need their own hardened profile and carefully scoped record access.
Data protection
Shield Platform Encryption for data at rest, Field Audit Trail for retention of field history, Event Monitoring for behavioural telemetry. Classify data and tag fields. Enforce CRUD and FLS in Apex with WITH SECURITY_ENFORCED, Security.stripInaccessible, or explicit schema checks; without sharing requires a written justification.
Worked example
Partner portal users must see cases belonging to accounts they own. Case organization-wide default is Private. The role hierarchy does nothing for external users, so the model uses sharing sets to grant access through the portal account's contact, plus criteria-based sharing for a small internal support group. Permission set groups give partner users exactly the objects they need, with a muting set removing internal-only fields.
Traps that cost marks
Relying on profiles alone, producing permission sprawl. Believing FLS hides data in every context - SOQL without enforcement, API access, and some declarative tools bypass expectations. Ignoring guest user defaults. Over-broad connected app scopes. Designing external sharing on the internal role hierarchy. Underestimating sharing recalculation on large data volumes.
Key points
- Authentication proves identity; authorization decides access - design them separately.
- Role hierarchy never applies to external users; use sharing sets.
- Permission set groups with muting sets scale better than profile edits.
- Enforce CRUD/FLS explicitly in Apex and APIs.
- Restriction and scoping rules narrow visibility without changing permissions.