11.2 Guest vs. Authenticated User Journeys & Identity Verification

11.2 Guest vs. Authenticated User Journeys & Identity Verification

Exam Focus: The AP-222 exam places heavy emphasis on the architectural boundary between unauthenticated guest citizens and authenticated portal constituents. Candidates must thoroughly understand Salesforce's strict Guest User Security Policies (Org-Wide Defaults locked to Private, record ownership reassignment, and criteria-based Guest Sharing Rules), the Person Account self-registration provisioning lifecycle, community license trade-offs (Customer Community vs. Customer Community Plus), federated Single Sign-On (SSO/MFA), and Identity Verification (IDV) standards (NIST SP 800-63 IAL2) integrating government providers like Login.gov and ID.me.

---

The Dual Identity Paradigm in Government Service Delivery

Public sector digital architecture operates under a fundamental duality. On one hand, government agencies must uphold democratic transparency and accessibility by offering frictionless public services to unauthenticated visitors—allowing residents to report road hazards, file anonymous whistleblower complaints, search public health notices, or check potential benefits eligibility without creating an account. On the other hand, agencies handle sensitive public safety, child welfare, regulatory enforcement, and financial assistance programs requiring rigorous identity assurance, statutory audits, and strict data confidentiality.

Architects must carefully evaluate which constituent touchpoints belong in the Unauthenticated Guest Zone versus the Authenticated Constituent Zone:

+-----------------------------------------------------------------------------------+
| Unauthenticated Guest Zone                                                        |
| - Public Regulatory Catalogs & FAQ Knowledge Base                                 |
| - Anonymous Whistleblower Complaints & 311 Code Violation Intake (`PublicComplaint`)|
| - Preliminary Benefits Pre-Screening Calculators (Discovery Framework)            |
+-----------------------------------------------------------------------------------+
                                        |
                       [Identity Proofing / Self-Registration]
                                        |
                                        v
+-----------------------------------------------------------------------------------+
| Authenticated Constituent Zone (Customer Community / Customer Community Plus)    |
| - Statutory Application Filing (`IndividualApplication`, `BusinessLicenseApp`)   |
| - Personally Identifiable Information (PII) & Income Verifications               |
| - Benefit Disbursement History, Award Management & Electronic Fund Transfers       |
| - Inspection Scheduling, License Renewals & Official Permit PDF Downloads         |
+-----------------------------------------------------------------------------------+

---

The Salesforce Guest User Security Model: Absolute Compliance Standards

Salesforce enforces a strict, multi-layered security model for unauthenticated Experience Cloud visitors. Known as the Guest User Security Policy, these platform controls are non-negotiable and represent heavily tested topics on the AP-222 exam.

1. Secure by Default & Org-Wide Defaults (OWD)

• Mandatory Private OWD: The external Org-Wide Default for the Guest User profile is locked to Private across all standard and custom objects in the Salesforce organization. Administrators cannot modify guest OWD to Public Read or Public Read/Write.
• Permitted Object Permissions: The Guest User profile can only be granted Read and Create permissions on authorized objects. The platform permanently revokes Edit, Delete, View All, and Modify All permissions for guest users across all objects.
• No Group or Queue Membership: Guest users cannot be added to public groups, personal groups, or assignment queues.

2. Guest User Record Ownership Enforcement

In standard Salesforce mechanics, when a user creates a record, that user becomes the default record owner. However, because guest users are transient and anonymous, allowing guest users to own records introduces severe security vulnerabilities.

• The Default Internal User: Salesforce mandates that every Experience Cloud site specify a Default Lead/Record Owner—an active, licensed internal Salesforce user (e.g., an automated integration user or site administrator).
• Ownership Reassignment: When an unauthenticated guest submits an application, a service ticket, or a file through an Experience Cloud site, the platform automatically intercepts the transaction and reassigns the OwnerId of the newly created record to the designated Default Internal User.
• Zero Subsequent Read Access: Once a guest user submits a record, they immediately lose all access to that record. The guest user cannot view, edit, or track the record they just submitted unless they authenticate or the agency employs secure token-based verification patterns.

3. Guest User Sharing Rules: The Sole Read Mechanism

Because guest OWD is locked to Private and guest users cannot belong to public groups, the only supported mechanism to grant guest users visibility into existing records is a Guest User Sharing Rule:

• Criteria-Based Sharing Only: Guest user sharing rules can only be created using record criteria (e.g., Is_Public_Catalog_Item__c == true or Status == 'Published'). Owner-based sharing rules cannot target guest users.
• Read-Only Access: Guest user sharing rules grant strictly Read-Only access. They cannot grant Edit or Delete rights.
• Application in PSS: Agencies use Guest User Sharing Rules to expose standard RegulatoryAuthorizationType records (the public license catalog) and active FundingOpportunity records (grant opportunities) without exposing sensitive internal metadata.

4. Running Digital Automation for Guests: System Mode with Sharing

When guest citizens complete multi-step intake flows using OmniStudio OmniScripts:

• If an OmniScript attempts to query or write records using the guest user's explicit profile permissions, it may fail due to strict guest object restrictions.
• Architectural Best Practice: Execute server-side operations through Integration Procedures configured to run in System Mode with Sharing. This allows the integration procedure to perform authorized lookups and record creations on behalf of the guest flow while respecting programmatic criteria filters and preventing unauthorized data exposure.

---

Authenticated Constituent Provisioning: Self-Registration & License Architecture

When constituents engage in formal statutory processes—such as applying for a professional nursing license, requesting food assistance benefits, or managing commercial building permits—they must transition to an authenticated security context.

Self-Registration Flow & Person Account Provisioning

Public Sector Solutions utilizes the Person Account data model to represent individual citizens. The self-registration process must seamlessly link the digital portal user with their master constituent record:

[1. Constituent Submits Self-Reg Form] (Name, Email, Phone, Address, SSN/ID)
                    |
                    v
[2. Configurable Self-Reg Handler / Apex] (Executes Duplicate Check Logic)
                    |
        +-----------+-----------+
        | Match Found           | No Match
        v                       v
[Link Existing Person Account]  [Insert New Person Account]
        |                       |
        +-----------+-----------+
                    |
                    v
[3. Create User Record] (Username, Email, Profile, ContactId = PersonContactId)
                    |
                    v
[4. Assign Permission Sets & Send Welcome Email / Verification Link]

1. Intake & Validation: The citizen completes an Experience Cloud self-registration form (built via standard Configurable Self-Reg or an OmniScript).
2. Deduplication Check: A custom self-registration handler (Auth.ConfigurableSelfRegHandler) queries the database using high-confidence matching rules (e.g., First Name + Last Name + Normalized Email + Government Identifier).
3. Person Account Provisioning: If an existing Person Account matches the constituent, the handler links to that record; otherwise, it inserts a new Account with the designated Person Account record type.
4. Portal User Creation: The handler inserts a User record, setting ContactId to the Person Account's underlying PersonContactId, assigning the designated Community profile, and triggering identity verification emails.

Experience Cloud Community License Comparison

Selecting the correct community license is a major architectural decision with significant cost, security, and functional ramifications. AP-222 candidates must master the distinct capabilities of Customer Community versus Customer Community Plus.

Exam Tip: If a scenario describes individual citizens applying for SNAP benefits, unemployment assistance, or personal driver's licenses, the correct answer is Customer Community. If the scenario describes a commercial construction enterprise where a project manager must view, edit, and manage permits submitted by other engineers within the same firm, the correct answer is Customer Community Plus due to its role hierarchy and record-sharing capabilities.

---

Constituent Identity Verification (IDV) & External Identity Providers

In public assistance and regulatory licensing, preventing identity theft, fraudulent benefit claims, and synthetic identity creation is a legal mandate. Government systems rely on established national identity standards.

The NIST SP 800-63-3 Identity Assurance Framework

Public sector architectures evaluate identity security against the National Institute of Standards and Technology (NIST) Special Publication 800-63-3:

+-----------------------------------------------------------------------------------+
| NIST SP 800-63-3 Digital Identity Assurance Levels                                |
+-----------------------------------------------------------------------------------+
| IAL1 (Identity Assurance Level 1): Self-asserted identity. No identity proofing   |
| required. Used for newsletter signups, public 311 reporting, and anonymous tips.  |
+-----------------------------------------------------------------------------------+
| IAL2 (Identity Assurance Level 2): Remote or in-person identity proofing.         |
| Requires validating government-issued photo ID (driver's license, passport),      |
| verifying biometric facial liveness, and confirming financial/telecom records.    |
| Mandated for cash assistance, food stamps, tax portals, and professional licenses.|
+-----------------------------------------------------------------------------------+
| IAL3 (Identity Assurance Level 3): Rigorous in-person physical identity           |
| verification with biometric hardware authentication (PIV/CAC cards).             |
| Mandated for law enforcement, critical infrastructure, and national security.    |
+-----------------------------------------------------------------------------------+

Integration with Government Identity Providers (IdPs)

Rather than managing constituent passwords and physical identity proofing internally, public agencies federate with trusted Identity Providers (IdPs):

• Login.gov: The official federal single sign-on platform used across U.S. federal agencies (e.g., USDA, VA, SBA). Provides federated OIDC authentication satisfying NIST IAL2.
• State Digital ID & DMV Gateways: State-level identity services that verify constituent credentials directly against state department of motor vehicle databases.
• ID.me: A commercial identity verification partner widely used by state workforce agencies and the IRS, providing automated document scanning, mobile selfie liveness checks, and video chat verification.

The PSS Native Identity Verification (IDV) Component

When constituents contact agency call centers or complete digital workflows, Public Sector Solutions provides the native Identity Verification (IDV) framework:

• Verification Configuration: Administrators configure verification rules specifying mandatory verification data points (e.g., Full Legal Name, Date of Birth, National ID / SSN, Physical Address).
• Caseworker Verification Console: When a constituent calls an agency caseworker, the IDV component prompts the worker to ask secondary verification questions before unlocking the constituent's record page.
• Audit Logging: Every successful and failed verification attempt is permanently recorded in IdentityVerificationLog records, providing complete statutory compliance tracking.

---

Single Sign-On (SSO) Federation & Multi-Factor Authentication (MFA)

SSO Architecture with SAML 2.0 and OpenID Connect (OIDC)

Salesforce Experience Cloud acts as a Service Provider (SP) in federated identity topologies:

1. Authentication Flow: When a constituent clicks "Log In with State ID", the portal redirects to the external Identity Provider via SAML 2.0 or OpenID Connect (OIDC).
2. Auth. Provider & Registration Handler: Salesforce receives the cryptographically signed SAML assertion or OIDC JSON Web Token (JWT). A custom Registration Handler (Auth.RegistrationHandler) decodes the token claims (e.g., sub, email, given_name, verified_claims), queries for existing Person Accounts, creates or updates the user, and establishes the authenticated session.
3. Just-In-Time (JIT) Provisioning: JIT provisioning eliminates manual user creation by instantiating or updating the constituent's Salesforce User and Person Account on the fly during initial SSO handshake.

Multi-Factor Authentication (MFA) & Step-Up Security

• Mandatory MFA: Salesforce enforces MFA across all administrative and constituent logins. Constituents verify their identity via authenticator apps, SMS one-time passcodes (OTP), or WebAuthn/FIDO2 hardware keys.
• Step-Up Authentication: For high-risk transactions—such as changing bank account direct deposit information for grant disbursements or reassigning property ownership—the system triggers step-up authentication, requiring the constituent to re-enter an OTP or biometric confirmation before proceeding, even if already logged into the portal.

---

💡 Real-World AP-222 Exam Scenarios & Case Analysis

Scenario 1: Anonymous Whistleblower Complaint Intake with Zero Data Leakage

A state ethics commission implements an online portal for citizens to report statutory violations and municipal corruption. Whistleblowers must be able to submit detailed narrative allegations, upload evidentiary documents, and receive a secure tracking reference number. However, whistleblowers must remain completely anonymous. Under no circumstances may a guest user view previously submitted complaints, and internal investigator notes must never be visible to the public.

How must the Lead Architect design this intake flow to guarantee statutory compliance?

• Intake Flow: Build a public-facing OmniScript embedded on the Experience Cloud site for unauthenticated guest users, capturing data into standard PublicComplaint and ContentVersion records.
• Security Enforcement:
  • Confirm the external OWD for PublicComplaint is locked to Private.
  • Configure the Experience Cloud site's Default Record Owner to an internal system integration user; all submitted complaints automatically transfer ownership away from the guest user upon commit.
  • Ensure no Guest User Sharing Rules are created for PublicComplaint records.
• Secure Tracking Pattern: To allow the whistleblower to check status later without logging in, the system generates a high-entropy UUID tracking token and returns it to the user. An Integration Procedure running in System Mode queries only public status milestones matching that unique token without exposing the underlying database record.

Scenario 2: Multi-Party Commercial General Contractor Portal with Delegated Administration

A metropolitan construction authority requires an online portal for commercial general contracting corporations. A large construction firm has 15 project managers, 5 safety compliance officers, and 3 accounting specialists. The firm's executive wants the ability to grant and revoke portal access for their own employees directly, without contacting the city IT helpdesk. Furthermore, all project managers within the firm must be able to collaborate, view, and modify building permit applications submitted by their colleagues across the firm.

Which license type and security architecture should the architect specify?

• License Selection: Specify Customer Community Plus licenses (or Partner Community licenses).
• Justification for Customer Community Plus:
  • Role Hierarchy: Customer Community Plus provisions a role hierarchy under the commercial Account, enabling role-based sharing rules so all project managers within the firm can view and edit each other's BusinessLicenseApplication records.
  • Delegated Administration: Enables the contracting firm's executive to function as an External Delegated Administrator, granting them permissions to create, update, and deactivate portal user accounts for their own employees autonomously.
  • Why Customer Community fails: Customer Community does not support role hierarchies, record sharing among co-workers, or external delegated administration.