Untitled Note

Nih.gov’s Join All of Us ~ SSO Architecture & Configuration Guide

Final Draft with Advanced Implementation Details

This comprehensive guide has been written for implementing and maintaining Single Sign-On within the NIH All of Us Research Program's Salesforce GovCloud environment.

Table of Contents

1. Executive Summary

2. System Architecture Overview

3. Identity Provider Configuration

4. Service Provider Configuration

5. Authentication Flows

6. Security Implementation

7. Integration Points

8. Maintenance and Monitoring

9. Troubleshooting

10. Compliance and Audit

11. User Provisioning and Management

12. Advanced Configuration Procedures

13. Appendices

1. Executive Summary

This document provides complete technical guidance for the Single Sign-On (SSO) implementation within the NIH All of Us Research Program's Salesforce environment. The solution utilizes Microsoft Active Directory Federation Services (ADFS) as the primary Identity Provider (IdP) and Salesforce GovCloud as the Service Provider (SP), implementing SAML 2.0 protocol for secure authentication.

Key Implementation Details

・ Identity Provider: Microsoft Active Directory Federation Services (ADFS)

・ Service Provider: Salesforce GovCloud (nihallofus.my.salesforce.com)

・ Protocol: SAML 2.0 with SHA-256 signing

・ Security Algorithm: SHA-256

・ User Base: 67+ NORC employees across multiple personas

・ Compliance: FedRAMP, FISMA, HIPAA compliant

Document Purpose

This Architecture & Configuration Guide serves as the authoritative technical reference for implementing, maintaining, and troubleshooting the SSO infrastructure. It provides complete implementation guidance from initial system design through ongoing operations and maintenance, ensuring compliance with federal healthcare data protection requirements and FedRAMP standards.

Target Audience

This document is intended for:

・ System Administrators and DevOps Engineers

・ Security and Compliance Officers

・ Technical Implementation Teams

・ Enterprise Architects

・ Project Managers and QA Testers

2. System Architecture Overview

2.1 High-Level Architecture

```

┌─────────────────┐ SAML 2.0 ┌──────────────────────┐

│ User Browser │ ◄─────────────► │ Salesforce GovCloud │

│ │ │ (Service Provider) │

└─────────────────┘ └──────────────────────┘

│ │

│ Authentication │ Assertion

│ Request │ Validation

▼ ▼

┌─────────────────┐ ┌──────────────────────┐

│ Active Directory│ │ SAML Configuration │

│ Federation │ │ - Entity ID │

│ Services (IdP) │ │ - ACS URL │

└─────────────────┘ │ - Certificate │

└──────────────────────┘

```

2.2 Component Descriptions

2.2.1 Identity Provider (ADFS)

・ Server: https://sts.norc.org/adfs/ls/

・ Function: Authenticates users and issues SAML assertions

・ Protocol: SAML 2.0 with SHA-256 signing

・ Certificate: ADFS token-signing certificate (2048-bit RSA minimum)

・ Multi-Factor Authentication: Enforced at ADFS level

2.2.2 Service Provider (Salesforce)

・ Environment: Salesforce GovCloud (USA9002)

・ Instance: https://nihallofus.my.salesforce.com

・ Function: Validates SAML assertions and grants access

・ Protocol: SAML 2.0 consumer

・ Compliance: FedRAMP, FISMA, HIPAA compliant

2.2.3 Integration Layer (MuleSoft)

・ Function: Provides API management and system integration

・ Authentication: SAML-based SSO for system-to-system communication

・ Connected App: MuleSoft SAML (ID: 0H48200000001HqCAI)

2.3 Authentication Flow

2.3.1 SP-Initiated Flow

1. User accesses https://nihallofus.my.salesforce.com

2. Salesforce redirects to ADFS with SAML AuthnRequest

3. User authenticates with ADFS (including MFA if required)

4. ADFS returns signed SAML assertion with SHA-256 signature

5. Salesforce validates assertion and grants access

2.3.2 IdP-Initiated Flow

1. User accesses ADFS portal/myapps

2. Selects Salesforce application

3. ADFS generates SAML assertion

4. User redirected to Salesforce with assertion

5. Salesforce validates and grants access

2.4 Key Configuration Parameters

| Component | Parameter | Value |

|-----------|-----------|-------|

| Entity ID | Service Provider Identifier | https://nihallofus.my.salesforce.com |

| ACS URL | Assertion Consumer Service | https://nihallofus.my.salesforce.com?so=00D820000008gExEAI |

| IdP Login URL | ADFS Authentication Endpoint | https://sts.norc.org/adfs/ls/ |

| Certificate | Signature Validation | ADFS token-signing certificate |

| Signature Algorithm | SAML Signing Method | SHA-256 (required for GovCloud) |

3. Identity Provider Configuration

3.1 ADFS Server Configuration

3.1.1 Server Requirements

・ Windows Server with ADFS role installed

・ Valid SSL certificate for ADFS service

・ Connectivity to Salesforce GovCloud endpoints

・ MFA capabilities configured

3.1.2 Relying Party Trust Configuration

Step 1: Create Relying Party Trust

1. Login to ADFS Management Console

2. Navigate to Trust Relationships → Relying Party Trusts

3. Click "Add Relying Party Trust"

4. Select "Claims aware" and click Start

Step 2: Configure Trust Settings

・ Entity ID: https://nihallofus.my.salesforce.com

・ ACS URL: https://nihallofus.my.salesforce.com?so=00D820000008gExEAI

・ Signature Algorithm: SHA-256

・ Certificate: ADFS token-signing certificate (2048-bit RSA)

Step 3: Configure Claims Rules

```

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]

=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"), query = ";mail,displayName;{0}", param = c.Value);

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/emailaddress"]

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

```

3.2 SAML Configuration

3.2.1 Attribute Mapping

・ mail → NameID: Primary user identifier (case-sensitive matching)

・ department → department: Optional attribute

・ employeeId → employeeId: Optional attribute

3.2.2 Certificate Management Best Practices

Certificate Generation:

1. Use 2048-bit RSA minimum key length

2. Implement SHA-256 signing algorithm

3. Set appropriate validity period (typically 2 years)

4. Store private keys securely

Certificate Monitoring:

```bash

Verify certificate expiration

openssl x509 -in adfs-cert.crt -text -noout | grep "Not After"

```

3.2.3 Certificate Renewal Process

1. 90 Days Before Expiration:

・ Coordinate with ADFS team for new certificate generation

・ Schedule maintenance window

・ Prepare rollback procedures

2. 30 Days Before Expiration:

・ Obtain new certificate from ADFS team

・ Test certificate in sandbox environment

・ Update ADFS relying party configuration

3. Day of Renewal:

・ Upload new certificate to Salesforce

・ Update ADFS configuration

・ Test both SP and IdP initiated flows

・ Monitor for any authentication issues

4. Service Provider Configuration

4.1 Salesforce SSO Settings

4.1.1 Primary SAML Configuration

Navigate to: Setup → Identity → Single Sign-On Settings

Step 1: Configure Basic SAML Settings

1. Login to Salesforce account with admin privileges

2. Under Administer, click Security Controls → Configure single-sign on for your organization

Step 2: Create SAML Configuration

1. On the Single-sign on settings page, click New from Metadata File

2. Upload the "idp-metadata.xml" downloaded from ADFS

3. Configure the following settings:

・ Name: NORC SSO

・ API Name: NORC_SSO

・ Service Provider Initiated Request Binding: HTTP POST

Step 3: Advanced Configuration

| Setting | Value | Notes |

|-----------------------------------------------|---------------------------------|-------------------------------------------|

|SAML Enabled | ✓ Checked | Required for SSO functionality |

|Identity Provider Certificate | ADFS Token-Signing Certificate | Must be current and valid |

|Identity Provider Login URL | https://sts.norc.org/adfs/ls/ | ADFS authentication endpoint |

|Identity Provider Logout URL | https://sts.norc.org/adfs/ls/ | Optional logout endpoint |

|Custom Error URL | (Optional) | Custom error page for failed authentication|

|SAML Identity Type | Federation ID | Links to User.FederationIdentifier field |

|SAML Identity Location | Subject | NameID element in SAML assertion |

|Service Provider Initiated Request Binding | HTTP POST | Recommended for security |

|Identity Provider Initiated Request Binding| HTTP POST | Matches IdP configuration |

|Request Signature Method | SHA256 | Required for GovCloud compliance |

|Request Signing Certificate | Salesforce Auto-Generated | Used for request signing |

|Decrypt SAML Response | ✓ Checked (if encryption enabled)| Optional encryption support |

Step 4: Download Service Provider Metadata

1. Click Download Metadata and save the file as "sp-metadata.xml"

2. Provide this file to the ADFS administrator for configuration

4.1.2 Updating IdP Configuration

Prerequisites:

・ The IdP configuration is updated after creating a federated pair

・ You must download the proxy metadata files from ADFS

Procedure:

1. Open the "Access IDP Metadata" from ADFS

2. Copy the "X.509Certificate" value

3. Format the certificate using: https://www.samltool.com/format_x509cert.php

4. Click "Format X.509 Certificate"

5. Save the formatted certificate as "access-idp-certificate.crt"

Update Salesforce Configuration:

1. Copy "entityId" attribute value from "EntityDescriptor" Element and paste in the "issuer" text box

2. Copy "Location" attribute value from "SingleSignOnService" Element and paste in "Identity Provider Login URL"

3. Copy "Location" attribute value from "SingleLogoutService" Element and paste in "Identity Provider Single Logout URL"

4. Upload the formatted certificate file "access-idp-certificate.crt"

5. Click Save

Note: Updating IDP Configuration in Salesforce can be error prone if copy/paste is required. Consider using metadata file imports when possible.

4.2 My Domain Configuration

Navigate to: Setup → Company Settings → My Domain

My Domain URL: nihallofus.my.salesforce.com

4.2.1 Authentication Configuration

・ Login Page Branding: Custom NORC branding

・ Authentication Services: NORC SSO enabled

・ Login Policy:

・ Prevent login from https://login.salesforce.com: ✓ Checked

・ Redirect to same page after login: ✓ Checked

4.3 Connected Apps for SSO

4.3.1 NORC SSO Connected App

App Name: NORC SSO

Connected App ID: 0H4SJ0000000L7h0AE

SAML Configuration:

・ Entity ID: https://nihallofus.my.salesforce.com

・ ACS URL: https://nihallofus.my.salesforce.com?so=00D820000008gExEAI

・ Subject Type: Federation ID

・ Name ID Format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

・ Issuer: https://sts.norc.org/adfs/services/trust

4.3.2 MuleSoft SAML Connected App

App Name: MuleSoft SAML

Connected App ID: 0H48200000001HqCAI

Used for API integrations and system-to-system authentication.

5. Authentication Flows

5.1 Detailed Authentication Process

5.1.1 SP-Initiated Authentication Flow

```mermaid

sequenceDiagram

participant User

participant Browser

participant Salesforce

participant ADFS

participant AD

User->>Browser: Navigate to Salesforce

Browser->>Salesforce: Request access

Salesforce->>Browser: Redirect to ADFS with SAML Request

Browser->>ADFS: Present SAML Request

ADFS->>User: Request credentials

User->>ADFS: Provide credentials + MFA

ADFS->>AD: Validate credentials

AD->>ADFS: Return user attributes

ADFS->>Browser: Return SAML Response

Browser->>Salesforce: Present SAML Response

Salesforce->>Salesforce: Validate assertion

Salesforce->>Browser: Grant access

```

1. User Access Request:

・ User navigates to Salesforce My Domain URL

・ Salesforce checks for valid session

・ If no valid session, initiates SSO process

2. SAML AuthnRequest Generation:

・ Salesforce generates SAML AuthnRequest

・ Request includes Entity ID, ACS URL, and other parameters

・ Request is signed with Salesforce private key (SHA-256)

3. Redirect to Identity Provider:

・ User browser is redirected to ADFS login URL

・ SAML AuthnRequest is included in the redirect

4. User Authentication:

・ User enters credentials at ADFS login page

・ ADFS validates credentials against Active Directory

・ Multi-factor authentication is enforced if configured

5. SAML Assertion Generation:

・ ADFS generates SAML assertion with user attributes

・ Assertion is signed with ADFS token-signing certificate (SHA-256)

・ Assertion includes NameID, attributes, and authentication statement

6. Response to Service Provider:

・ ADFS redirects user browser back to Salesforce ACS URL

・ SAML assertion is included in the POST response

7. Assertion Validation:

・ Salesforce validates SAML assertion signature using SHA-256

・ Salesforce verifies assertion elements (Issuer, Audience, etc.)

・ Salesforce extracts user attributes from assertion

8. User Session Creation:

・ Salesforce locates user record using Federation ID

・ Salesforce creates user session

・ User is granted access to Salesforce

5.2 IdP-Initiated Authentication Flow

1. User Access Request:

・ User navigates to ADFS portal or myapps

・ User selects Salesforce application tile

2. SAML Assertion Generation:

・ ADFS generates SAML assertion with user attributes

・ Assertion is signed with ADFS token-signing certificate

・ Assertion includes NameID, attributes, and authentication statement

3. Redirect to Service Provider:

・ User browser is redirected to Salesforce ACS URL

・ SAML assertion is included in the POST response

4. Assertion Validation:

・ Salesforce validates SAML assertion signature

・ Salesforce verifies assertion elements (Issuer, Audience, etc.)

・ Salesforce extracts user attributes from assertion

5. User Session Creation:

・ Salesforce locates user record using Federation ID

・ Salesforce creates user session

・ User is granted access to Salesforce

5.3 Advanced User Lifecycle Management

Your current user base of 67 SSO-enabled users will grow and change over time. People join the organization, change roles, leave for new opportunities, or shift between different levels of access requirements. Each of these transitions creates potential SSO-related complications that are best addressed through systematic lifecycle management processes.

Develop onboarding procedures that ensure new users receive appropriate Federation ID configuration:

・ Implement automated Federation ID assignment based on email attributes

・ Create validation processes to ensure exact matching with Active Directory

・ Establish testing protocols for new user SSO functionality

Consider implementing configuration version control practices similar to software development:

・ Document the current state completely before making any changes to SSO settings

・ This practice enables quick rollbacks if changes cause unexpected issues

・ Provides valuable data for troubleshooting when problems arise weeks or months after configuration modifications

6. Security Implementation

6.1 Encryption Standards

6.1.1 In-Transit Encryption

・ Protocol: TLS 1.2 minimum for all communications

・ Certificate: Valid SSL certificate for all endpoints

・ Cipher Suites: FIPS-approved cipher suites only

・ SAML Signature Algorithm: SHA-256 (mandatory for GovCloud)

6.1.2 At-Rest Encryption

・ Platform: Salesforce Shield Platform Encryption

・ Algorithm: AES-256 encryption for stored data

・ Key Management: Salesforce-managed or customer-managed keys via BYOK

Enabling Shield Platform Encryption:

1. From Setup, enter Encryption Settings in Quick Find

2. Select Encryption Settings

3. In the Encryption Policy section, turn on Encrypt Files and Attachments

4. Configure field-level encryption for sensitive data

Bring Your Own Key (BYOK) Configuration:

・ Contact Salesforce Customer Support to enable BYOK

・ Generate a BYOK-compatible certificate

・ Upload tenant secret files (.b64 format required)

・ Implement key rotation procedures

6.1.3 SAML Security

・ Signature Algorithm: SHA-256 (required for federal compliance)

・ Certificate: 2048-bit RSA minimum

・ Signing: Both requests and assertions signed

・ Encryption: Optional SAML response encryption available

6.2 Multi-Factor Authentication

6.2.1 MFA Implementation Requirements

・ Required: For all privileged users (System Administrators)

・ Recommended: For all users accessing sensitive data

・ Integration: ADFS MFA or Salesforce native MFA

MFA Configuration Options:

1. Salesforce Native MFA:

・ Salesforce Authenticator app

・ Third-party authenticator apps (TOTP)

・ Security keys (FIDO2/WebAuthn)

2. ADFS MFA Integration:

・ Certificate-based authentication

・ One-time passcodes

・ Biometric authentication

・ Smart card authentication

6.2.2 MFA Enforcement Policies

```apex

// Example MFA enforcement for key management

To assign identity verification for key management tasks:

• Manage Encryption Keys

AND

• Manage Certificates

AND

• Customize Application

```

6.3 Enhanced Transaction Security

Implement transaction security policies to monitor and control access:

File Access Monitoring:

・ Create policies to notify administrators when users attempt to preview specific files

・ Monitor content downloads and file access patterns

・ Implement real-time blocking for suspicious activities

Policy Configuration:

```

Actions: Block, Notifications

Conditions: Can Download PDF, Content Size, File Type, Source IP

Object: FileEventStore

```

7. Integration Points

7.1 MuleSoft Integration

7.1.1 MuleSoft SSO Configuration

・ Connected App: MuleSoft SAML (ID: 0H48200000001HqCAI)

・ Authentication Method: SAML 2.0

・ Purpose: API integrations and system-to-system authentication

・ Users: IBM System Administrators with MuleSoft_SSO permission set

7.1.2 API Authentication Flow

```

NORC User → ADFS Authentication → Salesforce SSO → MuleSoft API Access

```

7.1.3 Integration Considerations

・ MuleSoft applications must trust the same ADFS certificate

・ API endpoints must validate SAML tokens from Salesforce

・ Session management must be synchronized across platforms

7.2 Cross-Platform Session Management

7.2.1 Session Synchronization Challenges

・ Challenge: Maintaining consistent sessions across multiple platforms

・ Solution: Centralized session management through Salesforce

・ Implementation: Custom session synchronization logic

7.2.2 Integration with Broader Identity Governance

Your SSO implementation exists within a broader identity and access management ecosystem. Consider how changes to user roles, responsibilities, or employment status in your HR systems should trigger corresponding updates to Salesforce access. Developing automated workflows that synchronize identity changes across systems reduces security risks and administrative overhead.

Key Integration Points:

・ HR system integration for automated user provisioning/deprovisioning

・ Active Directory synchronization for attribute updates

・ Audit trail integration for compliance reporting

・ Monitoring dashboard integration for real-time visibility

7.3 Monitoring and Performance Optimization

Consider implementing monitoring dashboards that track SSO authentication success rates, response times, and failure patterns. This data becomes invaluable for capacity planning and identifying optimization opportunities.

Key Performance Indicators:

・ Authentication Success Rate: Target >99.5%

・ Authentication Response Time: Target <3 seconds

・ System Availability: Target 99.9%

・ Certificate Expiration Monitoring: 90-day advance warnings

8. Maintenance and Monitoring

8.1 Proactive Management Strategies

Building a Resilient SSO Ecosystem Through Proactive Management: Now that we've established the technical foundation, let's explore how to build an SSO ecosystem that not only functions reliably today but continues to serve your organization effectively as it evolves.

8.1.1 Understanding the Human Element in SSO Success

One of the most overlooked aspects of SSO implementation is how users actually interact with the system in real-world scenarios. Your technical configuration might be perfect, but if users don't understand how to navigate authentication flows or what to do when something goes wrong, you'll find yourself fielding the same support calls repeatedly.

User Education Strategies:

・ Develop comprehensive user guides for both SP and IdP-initiated flows

・ Create troubleshooting documentation for common user issues

・ Implement user training programs for new SSO users

・ Establish clear escalation procedures for support requests

8.1.2 Collaborative Cross-Team Relationships

Potential issues before they become urgent problems. These collaborative relationships become particularly valuable during complex changes like certificate renewals or infrastructure upgrades that require coordinated updates across multiple systems.

Shared Documentation Practices:

・ Create shared documentation repositories that both Salesforce and Active Directory teams can access and update

・ Document configuration changes with impact assessments

・ Maintain change logs with detailed timestamps and responsible parties

・ Implement peer review processes for configuration changes

8.2 Evolving Security Posture Through Continuous Improvement

Your GovCloud environment operates within an evolving threat landscape where security requirements and best practices change regularly. Building continuous security improvement into your SSO management processes ensures that your implementation remains robust against emerging threats while maintaining compliance with evolving regulatory requirements.

Security Review Processes:

・ Regularly review and update cryptographic standards to ensure they align with current federal requirements

・ Conduct quarterly security assessments of SSO configuration

・ Implement automated vulnerability scanning for SSO infrastructure

・ Maintain current threat intelligence for identity-related attacks

8.2.1 Certificate Lifecycle Management

Automated Certificate Monitoring:

```bash

Example certificate monitoring script

#!/bin/bash

CERT_FILE="/path/to/adfs-cert.crt"

EXPIREDATE=$(openssl x509 -in $CERTFILE -noout -enddate | cut -d= -f2)

EXPIRETIMESTAMP=$(date -d "$EXPIREDATE" +%s)

CURRENT_TIMESTAMP=$(date +%s)

DAYSUNTILEXPIRE=$(( (EXPIRETIMESTAMP - CURRENTTIMESTAMP) / 86400 ))

if [ $DAYSUNTILEXPIRE -lt 90 ]; then

echo "Certificate expires in $DAYSUNTILEXPIRE days - renewal required"

# Send alert to administrators

```

8.3 Change Management

8.3.1 Configuration Version Control

Having clear documentation of why specific decisions were made helps you evaluate whether those reasons still apply under changed circumstances. This documentation becomes particularly valuable when team members change and institutional knowledge might otherwise be lost.

Version Control Best Practices:

1. Document Current State: Before making any changes, export and document current configuration

2. Change Justification: Document the business reason for each configuration change

3. Testing Procedures: Document all testing performed before and after changes

4. Rollback Plans: Maintain detailed rollback procedures for each change

5. Change Approval: Implement formal approval processes for configuration changes

8.3.2 Maintenance Windows and Communication

Maintenance Window Planning:

・ Schedule regular maintenance windows (monthly recommended)

・ Communicate changes to stakeholders at least 48 hours in advance

・ Provide detailed maintenance plans with expected impacts

・ Establish emergency contact procedures during maintenance

・ Document all changes performed during maintenance windows

9. Troubleshooting

9.1 Common SSO Issues and Advanced Solutions

9.1.1 "SAML Assertion Invalid" Error

Symptoms:

・ Users see generic SAML error page

・ Login attempts fail silently

・ SAML Assertion Validator shows signature issues

Advanced Diagnostic Steps:

1. Check Certificate Chain Validity:

```bash

Verify certificate chain

openssl verify -CAfile ca-bundle.crt adfs-cert.crt

Check certificate key usage

openssl x509 -in adfs-cert.crt -text -noout | grep -A 3 "Key Usage"

```

2. Validate SAML Assertion Structure:

・ Use SAML Assertion Validator in Salesforce

・ Verify all required elements are present

・ Check attribute mappings and claim rules

3. Network and Timing Issues:

・ Verify system clocks are synchronized (NTP)

・ Check for network latency issues

・ Validate SSL/TLS configuration

Resolution Steps:

1. Re-upload current ADFS signing certificate to Salesforce

2. Verify SHA-256 configuration on both ADFS and Salesforce

3. Check certificate thumbprint matching in both systems

4. Test with SAML assertion validator before deploying

9.1.2 "User Not Found" Error

Symptoms:

・ Authentication succeeds at ADFS

・ Salesforce cannot locate user

・ Error: "We can't log you in because we can't find your username"

Advanced Diagnostic Procedures:

1. Federation ID Validation:

```sql

SELECT Id, Username, Email, FederationIdentifier, IsActive

FROM User

WHERE Email = 'user@norc.org'

AND IsActive = true

```

2. SAML NameID Analysis:

・ Capture SAML assertion from browser developer tools

・ Extract NameID value from assertion

・ Compare with Federation ID in Salesforce user record

3. Active Directory Attribute Verification:

```powershell

PowerShell command to verify AD attributes

Get-ADUser -Identity "username" -Properties mail,displayName

```

Resolution Procedures:

1. Update Federation ID to match ADFS mail attribute exactly

2. Consider case sensitivity settings in SSO configuration

3. Verify user account is active in both systems

4. Test with a known working user first

9.1.3 Advanced Permission and Access Issues

Symptom: User authenticates successfully but receives "Insufficient Privileges" error

Advanced Resolution:

1. Check Permission Set Assignments:

```sql

SELECT AssigneeId, PermissionSet.Name, PermissionSet.Type

FROM PermissionSetAssignment

WHERE AssigneeId = '[USER_ID]'

ORDER BY PermissionSet.Name

```

2. Validate NORCSSOUser (V2) Permission Set:

・ Verify "Single Sign-On Enabled" permission is granted

・ Check for any conflicting permission restrictions

・ Validate permission set group assignments

3. Profile-Level SSO Permissions:

・ Review base profile permissions

・ Ensure profile allows SSO authentication

・ Check for any profile-level restrictions

9.2 Emergency Recovery Procedures

9.2.1 Complete SSO Failure Recovery

Immediate Response Steps:

1. Enable Emergency Access:

・ Temporarily disable "Prevent login from login.salesforce.com"

・ Allow System Administrators to access via standard login

・ Document emergency access grants

2. Isolate the Issue:

・ Check ADFS server status and logs

・ Verify certificate validity and configuration

・ Test with SAML assertion validator

3. Communication Plan:

・ Notify all NORC users of temporary access issues

・ Provide alternative access methods if available

・ Establish regular status updates

9.2.2 Certificate Emergency Renewal

Critical Steps:

1. Obtain New Certificate:

・ Contact ADFS administrator for emergency certificate

・ Verify certificate meets security requirements

・ Test certificate in sandbox environment first

2. Coordinated Deployment:

・ Update ADFS configuration with new certificate

・ Upload new certificate to Salesforce simultaneously

・ Test both SP and IdP initiated flows immediately

3. Validation and Monitoring:

・ Monitor authentication success rates

・ Check error logs for any residual issues

・ Document lessons learned for future prevention

10. Compliance and Audit

10.1 Federal Compliance Requirements

10.1.1 FedRAMP Compliance Implementation

AC-2: Account Management

・ Implement automated user provisioning and deprovisioning workflows

・ Maintain regular access reviews and certification processes

・ Document all account management procedures with version control

・ Establish audit trails for all account-related activities

AC-3: Access Enforcement

・ Deploy role-based access control with least privilege principles

・ Implement attribute-based access control for sensitive data

・ Conduct regular validation of access permissions

・ Document access enforcement mechanisms and policies

AC-7: Unsuccessful Login Attempts

・ Monitor failed authentication attempts with automated alerting

・ Implement account lockout policies aligned with federal standards

・ Generate alerts for suspicious authentication patterns

・ Maintain detailed logs of all authentication activities

10.1.2 HIPAA Compliance for Healthcare Data

Administrative Safeguards (164.308):

・ Access Management: Document access authorization and supervision procedures

・ Workforce Training: Provide regular security awareness training

・ Information System Activity Review: Conduct regular reviews of system activity

Physical Safeguards (164.310):

・ Facility Access Controls: Document physical security measures

・ Workstation Use: Establish policies for workstation access

・ Device and Media Controls: Implement controls for portable devices

Technical Safeguards (164.312):

・ Access Control: Implement unique user identification and automatic logoff

・ Audit Controls: Maintain comprehensive audit logs

・ Integrity: Protect health information from alteration or destruction

・ Transmission Security: Encrypt data in transit

10.1.3 FISMA Compliance Requirements

Security Control Implementation:

・ Conduct regular risk assessments

・ Implement security controls from NIST SP 800-53

・ Maintain security documentation and procedures

・ Perform continuous monitoring of security controls

10.2 Continuous Monitoring and Audit Preparation

10.2.1 Event Monitoring Implementation

Real-time Monitoring:

・ Configure Salesforce Event Monitoring for SSO events

・ Implement automated alerting for security events

・ Establish baseline metrics for normal operations

・ Create dashboards for real-time visibility

Audit Trail Management:

・ Enable comprehensive logging of all authentication events

・ Implement log retention policies aligned with compliance requirements

・ Establish secure log storage and backup procedures

・ Create automated log analysis and reporting

10.2.2 Documentation and Evidence Collection

Automated Evidence Collection:

```apex

// Example code for automated compliance reporting

public class ComplianceReportGenerator {

public static void generateAccessReport() {

// Generate user access report

List<User> ssoUsers = [SELECT Id, Username, Email, LastLoginDate, Profile.Name

FROM User

WHERE Email LIKE '%@norc.org'

AND IsActive = true];

// Generate permission report

List<PermissionSetAssignment> permissions = [SELECT AssigneeId, PermissionSet.Name, AssignedDate

FROM PermissionSetAssignment

WHERE Assignee.Email LIKE '%@norc.org'];

// Create compliance report

ComplianceReport report = new ComplianceReport();

report.generateReport(ssoUsers, permissions);

}

```

11. User Provisioning and Management

11.1 Comprehensive User Lifecycle Management

11.1.1 User Personas and Access Requirements

The All of Us Research Program supports multiple user personas, each with specific access requirements:

NORC Staff Personas:

・ NORC Program Admin: Full system administration capabilities

・ NORC Program Operations Manager: Program operations and user support

・ NORC Research Staff: Research-focused access and reporting

・ Tactis Support Guide: Tier 1 support center access

NIH Staff Personas:

・ NIH Program Staff: Basic program staff access

・ NIH Program Manager: Enhanced management capabilities

・ NIH Analytics: Analytics and reporting focus

Partner Organization Personas:

・ Partner Admin: Partner organization administration

・ Partner Staff Portal User: Basic partner staff access

11.1.2 Federation ID Management

Critical Requirements:

・ Federation ID must exactly match the mail attribute in Active Directory

・ Case sensitivity should be disabled to prevent matching issues

・ Federation ID is required for all SSO-enabled users

・ Changes must be coordinated between systems

Bulk Federation ID Update Process:

```apex

// Automated Federation ID synchronization

public class FederationIdSynchronizer {

public static void syncFederationIds() {

List<User> usersToUpdate = new List<User>();

for(User u : [SELECT Id, Email, FederationIdentifier

FROM User

WHERE Email LIKE '%@norc.org'

AND IsActive = true

AND (FederationIdentifier = null

OR FederationIdentifier != Email)]) {

u.FederationIdentifier = u.Email.toLowerCase();

usersToUpdate.add(u);

}

if(!usersToUpdate.isEmpty()) {

update usersToUpdate;

System.debug('Updated Federation IDs for ' + usersToUpdate.size() + ' users');

}

```

11.2 Permission Set Management

11.2.1 NORC Permission Set Groups

Core Permission Sets:

・ NORCSSOUser (V2): Base SSO enablement for all NORC users

・ Admin Health Cloud Basics: Health Cloud administration capabilities

・ Admin User Custom Fields Management: User management permissions

Permission Set Group Assignments:

```sql

-- Verify permission set assignments

SELECT AssigneeId, PermissionSet.Name, PermissionSetGroup.Label

FROM PermissionSetAssignment

WHERE Assignee.Email LIKE '%@norc.org'

AND PermissionSet.Name = 'NORCSSOUser_V2'

```

11.2.2 Automated Permission Assignment

```apex

// Automated permission set assignment for new users

trigger UserProvisioningTrigger on User (after insert, after update) {

if(Trigger.isInsert) {

List<PermissionSetAssignment> assignments = new List<PermissionSetAssignment>();

PermissionSet norcSSO = [SELECT Id FROM PermissionSet WHERE Name = 'NORCSSOUser_V2'];

for(User u : Trigger.new) {

if(u.Email != null && u.Email.contains('@norc.org') && u.IsActive) {

assignments.add(new PermissionSetAssignment(

AssigneeId = u.Id,

PermissionSetId = norcSSO.Id

));

}

if(!assignments.isEmpty()) {

insert assignments;

}

```

12. Advanced Configuration Procedures

12.1 Sandbox Refresh Procedures

12.1.1 Pre-Refresh Preparation

Configuration Backup:

1. Export all SSO settings and metadata

2. Document connected app configurations

3. Create user access matrix with Federation IDs

4. Export permission set assignments

5. Document certificate configurations

Data Backup Scripts:

```bash

SFDX commands for data backup

sfdx force:data:tree:export -q "SELECT Id, Username, Email, FederationIdentifier FROM User WHERE Email LIKE '%@norc.org'"

sfdx force:data:tree:export -q "SELECT Id, DeveloperName, MasterLabel FROM ConnectedApp WHERE Name LIKE '%SSO%'"

```

12.1.2 Post-Refresh Configuration

Step 1: Update SAML Single Sign-On Settings

1. Navigate to Setup → Identity → Single Sign-On Settings

2. Update Entity ID: https://nihallofus--[SANDBOX_NAME].sandbox.my.salesforce.com

3. Update ACS URL: https://nihallofus--[SANDBOX_NAME].sandbox.my.salesforce.com?so=[NEW_ORG_ID]

Step 2: Reconfigure Connected Apps

```apex

// Script to update Connected App settings for sandbox

ConnectedApp norcSSO = [SELECT Id, CallbackUrl FROM ConnectedApp WHERE Name = 'NORC SSO'];

norcSSO.CallbackUrl = 'https://nihallofus--' + [SANDBOXNAME] + '.sandbox.my.salesforce.com?so=' + [NEWORG_ID];

update norcSSO;

```

Step 3: Restore User Configuration

```apex

// Bulk restore Federation IDs after sandbox refresh

List<User> usersToUpdate = new List<User>();

for(User u : [SELECT Id, Email, FederationIdentifier FROM User WHERE Email LIKE '%@norc.org']) {

if(u.FederationIdentifier != u.Email) {

u.FederationIdentifier = u.Email.toLowerCase();

usersToUpdate.add(u);

}

update usersToUpdate;

```

12.2 Advanced Security Configuration

12.2.1 Enhanced Transaction Security Policies

File Access Monitoring Policy:

```

Policy Configuration:

・ Name: NORC File Access Monitor

・ Object: FileEventStore

・ Conditions:

・ File Action = Preview

・ Source IP not in trusted range

・ File Type contains sensitive data markers

・ Actions: Block access, Send notification

```

Policy Configuration:

・ Name: NORC Login Anomaly Detection

・ Object: LoginEventStore

・ Conditions:

・ Login time outside business hours

・ Login from unusual geographic location

・ Multiple failed attempts

・ Actions: Require additional verification, Send security alert

```

12.2.2 Shield Platform Encryption Configuration

Field-Level Encryption:

1. Navigate to Setup → Encryption Settings

2. Enable encryption for sensitive fields:

・ User.FederationIdentifier

・ Custom participant data fields

・ Health information fields

Key Management:

```apex

// Example key rotation script

public class EncryptionKeyManager {

public static void rotateEncryptionKeys() {

// Implement key rotation logic

TenantSecret newSecret = generateNewTenantSecret();

// Update encryption policy

EncryptionPolicy policy = getActiveEncryptionPolicy();

policy.TenantSecretId = newSecret.Id;

// Re-encrypt existing data

reEncryptExistingData(policy);

}

```

13. Appendices

Appendix A: Enhanced Configuration Templates

A.1 Complete ADFS Relying Party Trust Configuration

```xml

<RelyingPartyTrust Name="Salesforce GovCloud NORC"

Identifier="https://nihallofus.my.salesforce.com"

MetadataURL="https://nihallofus.my.salesforce.com/saml/metadata"

Enabled="true"

SignatureAlgorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"

TokenEncryptionCertificate="ADFS-Token-Signing-Cert">

<Endpoint Address="https://nihallofus.my.salesforce.com?so=00D820000008gExEAI"

Protocol="SAMLAssertionConsumer"

Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" />

</Endpoints>

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]

=> issue(store = "Active Directory",

types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",

"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",

"http://schemas.microsoft.com/ws/2008/06/identity/claims/role"),

query = ";mail,displayName,memberOf;{0}",

param = c.Value);

</CustomRule>

</AddClaimRule>

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",

Issuer = c.Issuer,

OriginalIssuer = c.OriginalIssuer,

Value = c.Value,

ValueType = c.ValueType);

</CustomRule>

</AddClaimRule>

</ClaimsRules>

<RequireEncryptedAssertions>false</RequireEncryptedAssertions>

<SignatureAlgorithm>http://www.w3.org/2001/04/xmldsig-more#rsa-sha256</SignatureAlgorithm>

</SecuritySettings>

</RelyingPartyTrust>

```

Appendix B: Comprehensive Troubleshooting Scripts

B.1 Automated Diagnostic Script

```apex

public class SSODiagnosticTool {

public static DiagnosticResult runCompleteDiagnostic(String userEmail) {

DiagnosticResult result = new DiagnosticResult();

// Check user configuration

result.userCheck = checkUserConfiguration(userEmail);

// Check SSO configuration

result.ssoCheck = checkSSOConfiguration();

// Check permissions

result.permissionCheck = checkUserPermissions(userEmail);

// Check certificates

result.certificateCheck = checkCertificateStatus();

return result;

}

private static UserCheckResult checkUserConfiguration(String userEmail) {

UserCheckResult result = new UserCheckResult();

List<User> users = [SELECT Id, Username, Email, FederationIdentifier, IsActive, Profile.Name

FROM User

WHERE Email = :userEmail];

if(users.isEmpty()) {

result.status = 'FAIL';

result.message = 'User not found in Salesforce';

return result;

}

User user = users[0];

if(!user.IsActive) {

result.status = 'FAIL';

result.message = 'User account is inactive';

return result;

}

if(String.isBlank(user.FederationIdentifier)) {

result.status = 'FAIL';

result.message = 'Federation ID not configured';

return result;

}

if(user.FederationIdentifier != user.Email) {

result.status = 'WARN';

result.message = 'Federation ID does not match email';

return result;

}

result.status = 'PASS';

result.message = 'User configuration is correct';

return result;

}

// Additional diagnostic methods...

}

```

Appendix C: Monitoring and Alerting Configuration

C.1 Salesforce Event Monitoring Queries

```sql

-- Monitor SSO authentication failures

SELECT UserId, Username, LoginType, Status, LoginTime, SourceIp, LoginUrl

FROM LoginEventStore

WHERE LoginType = 'SAML Sfdc Initiated SSO'

AND Status = 'Failed'

AND LoginTime = LASTNDAYS:7

ORDER BY LoginTime DESC

-- Monitor permission changes

SELECT Id, CreatedDate, CreatedById, Action, Section, Display

FROM SetupAuditTrail

WHERE Action LIKE '%Permission%'

OR Action LIKE '%SSO%'

AND CreatedDate = LASTNDAYS:30

ORDER BY CreatedDate DESC

-- Monitor certificate expiration

SELECT Id, Subject, Issuer, ValidFrom, ValidTo

FROM Certificate

WHERE ValidTo <= NEXTNDAYS:90

ORDER BY ValidTo ASC

```

C.2 Automated Monitoring Script

```bash

#!/bin/bash

SSO Health Check Script

LOG_FILE="/var/log/sso-health-check.log"

DATE=$(date '+%Y-%m-%d %H:%M:%S')

echo "[$DATE] Starting SSO health check" >> $LOG_FILE

Check ADFS server connectivity

if curl -f -s "https://sts.norc.org/adfs/ls/IdpInitiatedSignon.aspx" > /dev/null; then

echo "[$DATE] ADFS connectivity: OK" >> $LOG_FILE

else

echo "[$DATE] ADFS connectivity: FAILED" >> $LOG_FILE

# Send alert

Check certificate expiration

CERT_EXPIRE=$(openssl s509 -in /path/to/adfs-cert.crt -noout -enddate | cut -d= -f2)

EXPIRETIMESTAMP=$(date -d "$CERTEXPIRE" +%s)

CURRENT_TIMESTAMP=$(date +%s)

DAYSUNTILEXPIRE=$(( (EXPIRETIMESTAMP - CURRENTTIMESTAMP) / 86400 ))

if [ $DAYSUNTILEXPIRE -lt 90 ]; then

echo "[$DATE] Certificate expires in $DAYSUNTILEXPIRE days - ACTION REQUIRED" >> $LOG_FILE

# Send alert to administrators

else

echo "[$DATE] Certificate expiration: OK ($DAYSUNTILEXPIRE days remaining)" >> $LOG_FILE

Check Salesforce connectivity

SFSTATUS=$(curl -f -s -o /dev/null -w "%{httpcode}" "https://nihallofus.my.salesforce.com")

if [ "$SF_STATUS" = "200" ]; then

echo "[$DATE] Salesforce connectivity: OK" >> $LOG_FILE

else

echo "[$DATE] Salesforce connectivity: HTTP $SFSTATUS" >> $LOGFILE

# Send alert

echo "[$DATE] SSO health check completed" >> $LOG_FILE

```

Appendix D: Emergency Response Procedures

D.1 SSO Outage Response Plan

Immediate Response (0-15 minutes):

1. Confirm outage scope (partial vs. complete)

2. Enable emergency admin access via standard login

3. Notify stakeholders via emergency communication channels

4. Begin preliminary diagnostics

Short-term Response (15-60 minutes):

1. Identify root cause (certificate, network, configuration)

2. Implement temporary workarounds if available

3. Provide regular status updates to stakeholders

4. Document all troubleshooting steps

Resolution Phase (1-4 hours):

1. Implement permanent fix based on root cause analysis

2. Test resolution with limited user group

3. Monitor system stability

4. Gradually restore access to all users

Post-Incident (4+ hours):

1. Conduct post-incident review

2. Document lessons learned

3. Update procedures based on findings

4. Implement preventive measures

D.2 Certificate Emergency Renewal

Emergency Certificate Renewal Checklist:

・ [ ] Obtain new certificate from ADFS administrator

・ [ ] Verify certificate meets security requirements (2048-bit RSA, SHA-256)

・ [ ] Test certificate in sandbox environment if time permits

・ [ ] Coordinate simultaneous update in ADFS and Salesforce

・ [ ] Update certificate in Salesforce SSO settings

・ [ ] Update ADFS relying party trust configuration

・ [ ] Test both SP and IdP initiated authentication flows

・ [ ] Monitor authentication logs for any issues

・ [ ] Document emergency renewal process for future reference

・ [ ] Schedule post-incident review to prevent future emergencies

This comprehensive guide provides organizations with the technical foundation and operational procedures necessary to implement, maintain, and troubleshoot a robust SSO solution within the demanding requirements of federal healthcare environments. The investment in thorough planning and implementation pays dividends in reduced support overhead, improved security posture, and enhanced user experience over the long term.

Untitled Note

Start thinking in