Technical Architecture

This document provides a technical overview of the AccessPoint platform for solution architects, cybersecurity engineers, and IT directors evaluating the product for their organization.

Platform Overview

AccessPoint is an ATIP/FOI request management platform that runs entirely within your organization's Microsoft 365 and Azure tenant. There are no external servers, databases, or third-party cloud dependencies at runtime. All data remains in your environment under your control.

Key characteristics:

• Tenant-native — Deploys as a SharePoint Framework (SPFx) solution and Azure PaaS services within your existing tenant
• No Power Platform dependencies — No Dataverse, Power Automate, or Power Apps licensing required
• Data sovereignty — All data resides in your Azure tenant's configured geography
• No vendor runtime access — The publisher cannot access your data at any point during normal operation
• Flat-rate licensing — Departmental licensing with no per-user metering
• Configuration over code — Request types, extension reasons, exemption codes, and choice fields are data-driven
• Multilingual by design — Three-tier translation system supporting 11 languages

Architecture Diagram

Customer's Microsoft 365 Tenant          Customer's Azure Subscription
┌──────────────────────────────┐         ┌─────────────────────────────────────────┐
│                              │         │                                         │
│  SPFx Web Part               │         │  Azure App Service (Linux)              │
│  (SharePoint Online /        │──HTTPS──│  ASP.NET Core 10 Web API               │
│   Teams Personal App /       │  (JWT)  │    ├─ Entra ID JWT validation          │
│   Teams Tab)                 │         │    ├─ Role-based authorization          │
│                              │         │    ├─ PII filter middleware             │
│  Installed from AppSource    │         │    ├─ User upsert from JWT claims      │
│  or Tenant App Catalog       │         │    ├─ License validation middleware    │
│                              │         │    └─ Syncfusion document conversion   │
│                              │         │                                         │
│  SharePoint Tenant Storage   │         │  Azure SQL Database                     │
│  (API URL + Client ID)       │         │  (55 tables, ~716 fields)              │
│                              │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────┐             │  Application Insights + Log Analytics   │
        │  Mail.Send       │◄────────────│  (Telemetry, diagnostics)               │
        │  User.Read.All   │             │                                         │
        │  TeamsActivity   │             └─────────────────────────────────────────┘
        │  TeamsAppInstall │
        └──────────────────┘

Component Inventory

Component	Technology	Deployed To	Purpose
SPFx Web Part	TypeScript, React 17, Fluent UI 8, SPFx 1.22.1	Customer SharePoint Online / Teams	User interface for all roles
Teams App	Teams manifest v1.17, app version 1.3.0	Customer Teams Admin Center	Personal app, configurable tab, activity feed notifications with deep linking
Web API	C# / ASP.NET Core 10, .NET 10	Customer Azure App Service (Linux)	Business logic, data access, document processing
Database	SQL Server (DacPac)	Customer Azure SQL Database	Relational data store (55 tables)
Blob Storage	Azure Blob Storage	Customer Azure Storage Account	Document file storage
Monitoring	Application Insights + Log Analytics	Customer Azure Subscription	Telemetry, diagnostics, alerting

What the Publisher Operates

The publisher (Realizer) operates the following services, which are separate from your tenant:

Service	Purpose
Realizer Platform	License key issuance and validation (no customer data transmitted)
AppSource Listings	SPFx web part and Teams app distribution via Microsoft AppSource
Deployment Templates	Bicep ARM template and PowerShell script hosted at get.realizer.io

No customer data is transmitted to or stored by any publisher-operated service.

Shared Responsibility Model

AccessPoint deploys within the customer's own Azure tenant and Microsoft 365 environment. Security responsibilities are shared between three parties:

Control Area	Azure (CSP)	Customer Department	AccessPoint (Publisher)
Physical security	Responsible	—	—
Hypervisor / host OS	Responsible	—	—
Network infrastructure	Responsible	Configure (NSG, firewall, VNet)	—
Azure platform services (App Service, SQL, Blob)	Responsible (platform security)	Configure (SKU, redundancy, firewall rules)	Define deployment template (Bicep)
Identity and authentication	Provide Entra ID platform	Manage tenant policies (MFA, Conditional Access)	Integrate with Entra ID, validate JWT tokens
Application-level access control	—	Assign roles to users	Enforce RBAC, PII filtering, resource ownership
Application code security	—	—	Responsible (secure development, dependency updates, vulnerability remediation)
Data encryption at rest	Provide TDE, SSE	Enable CMK if required	Use platform encryption (no application-level key management)
Data encryption in transit	Provide TLS termination	Verify TLS configuration	Enforce TLS 1.2+, httpsOnly, disable insecure protocols
Audit logging	Provide platform logs	Retain and monitor logs, integrate with SIEM	Write application-level audit trail, emit Application Insights telemetry
Backup and recovery	Provide backup services	Configure retention, redundancy, geo-replication	Stateless application — no application-level backup required
Patching — OS and runtime	Responsible (App Service managed platform)	—	—
Patching — application code	—	Apply updates when published	Develop and publish updates
Patching — third-party dependencies	—	—	Monitor and update NuGet/npm dependencies
Incident response	Azure platform incidents	Departmental incident response, report to CCCS	Application-level incident response, notify affected customers
Data residency	Provide Canadian regions	Select Canadian region during deployment	No data transmitted to publisher; all data stays in customer tenant
Vulnerability assessment	Platform-level scanning	Conduct or commission application-level VAPT	Remediate findings, provide assessment support

System Authorization Boundary

For SA&A purposes, the AccessPoint authorization boundary includes:

• The Azure App Service and its deployed application code
• The Azure SQL Database and all application data
• The Azure Blob Storage account and all stored documents
• The Application Insights and Log Analytics workspace
• The Entra ID app registration and managed identity
• The SPFx web part deployed to SharePoint Online
• The Teams app package
• All data flows between these components

The following are outside the AccessPoint authorization boundary and fall under the department's broader Azure/M365 SA&A:

• The Azure subscription and resource group configuration
• Entra ID tenant policies (MFA, Conditional Access, device compliance)
• Network configuration (VNet, NSG, Private Endpoints)
• Azure platform services (managed by Microsoft)

Design Principles

1. SQL schema is source of truth — The Azure SQL Database schema defines the data model. All business entities, relationships, and constraints are enforced at the database level.

2. Privacy by design — Certain roles are restricted from viewing requestor PII. This is enforced at the API layer through middleware that strips PII fields from responses before they reach the client.

3. Data sovereignty — All data resides in the customer's Azure tenant. No data is transmitted to the publisher or any third party at runtime.

4. Configuration over code — Request types, extension reasons, exemption codes, workflow stages, and choice fields are stored as data in Azure SQL. Changes to these do not require code deployments.

5. Multilingual by design — A three-tier translation system supports 11 languages across the user interface, configuration data, and system messages.

6. Tenant settings in database — Runtime configuration is stored in Azure SQL, not in application config files. This enables per-tenant customization without redeployment.

Authentication and Identity

AccessPoint uses Microsoft Entra ID as its sole identity provider. There are no application-specific user accounts or passwords.

Authentication Flow

User (Browser)                SharePoint Online           AccessPoint API
     │                              │                          │
     │  1. Load SPFx web part       │                          │
     │─────────────────────────────►│                          │
     │                              │                          │
     │  2. AadHttpClient.getClient()│                          │
     │  (SPFx acquires token for    │                          │
     │   api://<client-id> audience)│                          │
     │                              │                          │
     │  3. API call + Bearer token  │                          │
     │──────────────────────────────┼─────────────────────────►│
     │                              │                          │
     │                              │  4. Validate JWT:        │
     │                              │     - Issuer (Entra ID)  │
     │                              │     - Audience (api://)  │
     │                              │     - Signature          │
     │                              │     - Expiry             │
     │                              │                          │
     │                              │  5. UserUpsertMiddleware: │
     │                              │     Extract claims →     │
     │                              │     Upsert Users table   │
     │                              │                          │
     │                              │  6. RoleAuthorization:   │
     │                              │     Check UserRoles table│
     │                              │                          │
     │     ◄── JSON response ───────┼──────────────────────────│

Token Configuration

Parameter	Value
Identity Provider	Microsoft Entra ID (Azure AD)
Protocol	OAuth 2.0 / OpenID Connect
Token Type	JWT Bearer
Audience	api://<client-id> and <client-id> (both v1 and v2 tokens accepted)
Issuer	https://login.microsoftonline.com/{tenantId}/v2.0 and https://sts.windows.net/{tenantId}/
Token Acquisition	SPFx AadHttpClient (implicit/auth code flow managed by SharePoint)

App Registration

Property	Value
Type	Single-tenant (AzureADMyOrg)
Identifier URI	api://accesspoint-{environment}
Exposed Scope	access_as_user (delegated, user consent)
Client Secret	None — SPFx uses the SharePoint-managed token flow

Managed Identity

The App Service uses a System-Assigned Managed Identity to authenticate to:

• Azure SQL Database — Entra-only authentication is enabled; SQL password authentication is disabled
• Azure Blob Storage — DefaultAzureCredential (Managed Identity in production)
• Microsoft Graph API — ManagedIdentityCredential on App Service (falls back to DefaultAzureCredential for local development) with application permissions

No client secrets or certificates are stored in the application. The managed identity's credentials are rotated automatically by Azure. The API explicitly uses ManagedIdentityCredential on App Service to ensure correct token acquisition for Graph calls, avoiding ambiguity with DefaultAzureCredential probe order.

Users authenticate with their existing organizational account. The API validates the JWT on every request, checking issuer, audience, signature, and expiry. MFA and Conditional Access policies are fully compatible — all tenant-level Entra ID security policies apply.

Authorization and RBAC

AccessPoint implements application-level role-based access control stored in Azure SQL. Roles are assigned to users within the application and enforced by ASP.NET Core authorization policies on every API request.

Role Permissions

Role	Sees Requestor PII	Manages Requests	Manages Assignments	Submits Documents	Typical User
Administrator	Yes	Config only	No	No	IT admin, system owner
SAO	Yes	Yes	Yes	No	Access & privacy officer
Reviewer	Yes	Read only	Read only	No	Legal counsel, QA
Custodian	No	No	Own assignments	No	Department records officer
Contributor	No	No	No	Own tasks	Subject matter expert
Reader	No	Read only	Read only	No	Oversight, audit

Server-Side Role Enforcement

All API write endpoints enforce roles at the controller level:

Resource	Create	Update	Delete	Other
Requests	Admin, SAO	Admin, SAO	Admin, SAO	Activate: Admin, SAO
Assignments	SAO	SAO or assigned custodian	SAO	Approve/RequestChanges/Cancel: SAO
Tasks	SAO, custodian	SAO, contributor, or custodian	SAO, custodian	Cancel: SAO, custodian
Documents	SAO, contributor, or custodian (ownership check)	SAO	SAO, contributor, or custodian (ownership check)	Other write ops: SAO
Configuration	Administrator	Administrator	Administrator	All writes: Administrator
Settings	Administrator	Administrator	—	All writes: Administrator

Reader/Advisor access: Request lists are filtered server-side to only associated requests (unless the user has Admin/SAO/Reviewer role). Documents respect canViewDocuments settings. Attestation forms are hidden; only read-only views are shown. No Acknowledge, Cancel, or Approve actions are available.

Bootstrap: The first user to access the system is automatically granted both Administrator and SAO roles.

Role Scoping

Roles are scoped and can be constrained to specific resources:

• Global scope — Role applies to all requests (e.g., Administrator, SAO)
• Request scope — Role applies to a specific request
• Assignment scope — Role applies to a specific custodian assignment
• Task scope — Role applies to a specific contributor task

Enforcement Points

1. API Authorization Policies — ASP.NET Core [Authorize(Policy = "...")] attributes on every controller action
2. RoleAuthorizationHandler — Checks UserRoles table for the authenticated user's role membership
3. ResourceOwnerAuthorizationHandler — Validates resource-level ownership (e.g., a Contributor can only access their own tasks)
4. PiiFilterMiddleware — Strips requestor PII fields from JSON responses for restricted roles (Custodian, Contributor, Reader)

Privacy by Design

AccessPoint implements structural privacy controls that are enforced at the API layer, not just the UI.

PII Filter Middleware

A response-level middleware intercepts all JSON responses and strips PII fields for users holding restricted roles (Custodian, Contributor, Reader). This is enforced server-side regardless of what the client requests.

Fields stripped for restricted roles:

• requestorName, requestorEmail, requestorPhone, requestorAddress
• subjectName, subjectDateOfBirth

Notification PII Blanking

When the notification system sends emails or Teams messages to Custodians or Contributors, requestor PII is replaced with placeholder text in the notification content itself — even if the notification template includes PII merge fields.

Custodian/Contributor Isolation

• Custodians see only their assigned requests and work from sanitized instructions
• Contributors see only their assigned tasks
• Neither role can search, browse, or access requests outside their scope

Data Flow

1. User loads the SPFx web part in SharePoint Online or Microsoft Teams
2. SPFx acquires a JWT token for the API audience via AadHttpClient
3. The API validates the JWT (issuer, audience, signature, expiry)
4. UserUpsertMiddleware creates or updates the user record in Azure SQL from JWT claims
5. RoleAuthorizationHandler checks the UserRoles table to verify the user has the required role for the requested operation
6. PiiFilterMiddleware strips requestor PII from the response for restricted roles
7. The API reads from and writes to Azure SQL Database and Azure Blob Storage
8. Notifications are dispatched via Microsoft Graph API (email via Mail.Send, Teams activity feed via TeamsActivity)

Network Architecture

Inbound Traffic

Source	Destination	Protocol	Port	Authentication
User browser (via SharePoint)	App Service	HTTPS	443	JWT Bearer token
Azure DevOps / GitHub Actions	App Service (Kudu)	HTTPS	443	Publish profile / Managed Identity
Azure DevOps / GitHub Actions	Azure SQL	TDS/TCP	1433	SQL auth / Managed Identity

Outbound Traffic

Source	Destination	Protocol	Port	Purpose
App Service	Azure SQL	TDS/TCP	1433	Database queries
App Service	Azure Blob Storage	HTTPS	443	Document upload/download
App Service	Microsoft Graph API	HTTPS	443	Email, Teams, user lookup
App Service	Publisher License API	HTTPS	443	License validation
App Service	Syncfusion CDN	HTTPS	443	Document viewer assets (client-side only)
SPFx (browser)	App Service	HTTPS	443	API calls
SPFx (browser)	Microsoft Graph	HTTPS	443	People picker, file access

CORS Policy

The API restricts cross-origin requests to SharePoint Online origins only:

• Origin must match *.sharepoint.com
• All headers allowed
• All HTTP methods allowed
• Content-Disposition header exposed (for file downloads)

Network Security Recommendations

The default Bicep deployment uses public endpoints. For enhanced security, customers can apply the following:

Enhancement	How
Private Endpoints	Add Azure Private Endpoints for App Service, SQL, and Blob Storage
VNet Integration	Deploy App Service with VNet Integration for outbound traffic
Application Gateway / Front Door	Add WAF protection in front of App Service
SQL Firewall	Restrict to App Service outbound IPs or VNet only
Blob Storage Firewall	Restrict to App Service VNet or Private Endpoint
NSG Rules	Apply Network Security Groups to the integration subnet

Encryption

In Transit

Connection	Protocol	Minimum TLS
Browser → App Service	HTTPS (enforced, httpsOnly: true)	TLS 1.2
App Service → Azure SQL	TDS with encryption (Encrypt=True)	TLS 1.2
App Service → Blob Storage	HTTPS (Managed Identity, DefaultAzureCredential)	TLS 1.2
App Service → Microsoft Graph	HTTPS	TLS 1.2
SPFx → App Service	HTTPS (enforced by SharePoint context)	TLS 1.2

At Rest

Data Store	Encryption	Key Management
Azure SQL Database	Transparent Data Encryption (TDE)	Microsoft-managed keys (default) or Customer-managed keys (CMK)
Azure Blob Storage	Azure Storage Service Encryption (SSE)	Microsoft-managed keys (default) or Customer-managed keys (CMK)
Application Insights	Platform encryption	Microsoft-managed keys

Application-Level Encryption

Feature	Mechanism
Document viewer tokens	ASP.NET Core Data Protection (machine key, auto-rotated)
Attestation e-signatures	SHA-256 hash of signatory + timestamp stored in audit fields

Data Residency and Sovereignty

All data resides in the customer's Azure tenant in the region selected during deployment. No data is transmitted to or stored in other regions unless the customer explicitly configures Azure geo-replication.

Canadian federal departments: For GC-specific data residency requirements, ITSG-33 control mapping, and GC Cloud Guardrails compliance, see the GC Security Controls Reference.

Customer Data Locations

Data Type	Storage Location	Controlled By
Request records, user data, audit trail	Azure SQL Database	Customer's Azure subscription
Uploaded documents	Azure Blob Storage	Customer's Azure subscription
Application telemetry	Application Insights / Log Analytics	Customer's Azure subscription
SPFx web part assets	SharePoint CDN	Customer's M365 tenant
Tenant configuration (API URL, Client ID)	SharePoint Tenant Storage Entities	Customer's M365 tenant

What Crosses Tenant Boundaries

Data Flow	Direction	What Is Transmitted	Purpose
License validation	API → Publisher Platform	License key (opaque string), tenant ID	Validate active subscription
Email notifications	API → Microsoft Graph	Email content via Mail.Send	Send notifications from shared mailbox
Teams notifications	API → Publisher Platform → Microsoft Graph	Activity type, preview text, recipient ID, template parameters	Send Teams activity feed notifications (proxied through publisher's multi-tenant enterprise app because sendActivityNotification must be called by the app that owns the Teams manifest)
User profile lookup	SPFx → Microsoft Graph	User search queries	People picker, user resolution

What Never Leaves the Tenant

• Request records and requestor PII
• Uploaded documents
• Audit history
• Configuration data (request types, templates, numbering)
• Role assignments

Tenant Isolation

Single-Tenant Deployment

Each customer deploys their own isolated instance of AccessPoint:

• Dedicated Azure SQL Database — no shared database across customers
• Dedicated App Service — no shared compute across customers
• Dedicated Blob Storage — no shared storage across customers
• Dedicated App Registration — each tenant has its own Entra ID app registration

Multi-Tenancy Within the Application

While deployment is single-tenant, the database schema includes a TenantId column on all tables for future multi-tenant scenarios and to support organizations with multiple Entra ID tenants.

Split Azure / M365 Tenant Support

Some organizations host their Azure backend in a different Entra ID tenant than their M365 tenant (e.g., a shared services tenant manages Azure infrastructure while SharePoint Online runs in the corporate tenant). AccessPoint supports this topology:

• The App Service managed identity is registered as a service principal in the M365 tenant
• Graph permissions (Mail.Send, User.Read.All, TeamsAppInstallation.ReadForUser.All, Application.Read.All, AppCatalog.Read.All) are granted to the managed identity in the M365 tenant
• Application Access Policy scopes Mail.Send to the designated shared mailbox only
• Teams notifications require separate admin consent for the Realizer enterprise app (TeamsActivity.Send, AppCatalog.Read.All, User.Read) in the M365 tenant — this is independent of the managed identity
• No architectural changes are required — the API uses ManagedIdentityCredential to authenticate, and Graph API calls target the M365 tenant

No Shared Infrastructure

The publisher operates no shared middleware, message queues, or caching layers between customer tenants. Each deployment is fully isolated.

Logging, Monitoring, and Audit

Application Insights

All API telemetry is sent to the customer's Application Insights instance:

Signal	What Is Captured
Request traces	HTTP method, path, status code, duration, correlation ID
Dependency tracking	SQL queries, Blob operations, Graph API calls (duration, success/failure)
Exceptions	Unhandled exceptions with stack traces
Custom metrics	Request processing times, document conversion durations

Audit Trail

AccessPoint maintains a comprehensive audit trail in the AuditHistory table (Azure SQL):

Field	Description
EntityType	The table/entity that was modified
EntityId	The primary key of the modified record
Action	Create, Update, Delete, StatusChange
FieldName	The specific field that changed
OldValue / NewValue	Before/after values
ModifiedBy	The authenticated user who made the change
ModifiedOn	UTC timestamp

Audit records are immutable — they cannot be modified or deleted through the API.

Retention Purge Log

When records are purged according to retention policy, the retention purge process deletes document blobs, converted PDFs, annotations, and export packages from Azure Blob Storage in addition to database records. The RetentionPurgeLog table records what was deleted, when, and by whom, providing a compliance-grade audit trail even after data is removed.

Log Analytics

Application Insights data is backed by a Log Analytics workspace with configurable retention (default: 90 days, configurable 30–730 days). Customers can extend retention, export to Azure Sentinel, or integrate with their existing SIEM.

Default Alert Rules

The Bicep deployment includes two default metric alerts on the App Service:

Alert	Severity	Condition	Window
Server Errors	2 (Warning)	HTTP 5xx count > 5	5 minutes
High Latency	3 (Informational)	Average response time > 5 seconds	15 minutes

Customers can customize thresholds and add action groups (email, SMS, webhook) in the Azure Portal.

Microsoft Graph API Permissions

Delegated Permissions (SPFx → Graph, user context)

Requested during SPFx package approval in SharePoint Admin Center:

Permission	Type	Purpose
User.Read.All	Delegated	People picker, user search and resolution
Sites.Read.All	Delegated	SharePoint site access for document context
Files.Read.All	Delegated	File access for document preview
Mail.Read	Delegated	Email preview (.eml, .msg files)

Application Permissions (API → Graph, managed identity)

Granted via Entra ID admin consent to the App Service managed identity:

Permission	App Role ID	Purpose
Mail.Send	b633e1c5-b582-4048-a93e-9f11b44c7e96	Send notification emails from the shared mailbox
User.Read.All	df021288-bdef-4463-88db-98f22de89214	Validate shared mailbox existence, resolve recipient addresses
TeamsAppInstallation.ReadForUser.All	afdb422a-4b2a-4e07-a708-8ceed48196bf	Pre-check Teams app installation before sending notifications
Application.Read.All	9a5d68dd-52b0-4cc2-bd40-abcf44ac3a30	Teams setup validation — verify publisher enterprise app consent in tenant
AppCatalog.Read.All	e12dae10-5a57-4571-81cb-25a4a5493fc3	Teams setup validation — check Teams app availability in org catalog

Realizer Enterprise Application Permissions (Publisher's multi-tenant app)

Granted via admin consent in the customer's M365 tenant. The Realizer enterprise app is a publisher-operated multi-tenant application that proxies Teams sendActivityNotification calls — required because the Graph API mandates that the caller be the same app registration that owns the Teams manifest.

Permission	Purpose
TeamsActivity.Send	Send Teams activity feed notifications on behalf of AccessPoint
AppCatalog.Read.All	Resolve the Graph catalog app ID from the manifest external ID via AppCatalogs.TeamsApps lookup
User.Read	Basic sign-in scope required for Graph API calls

Permission Justification

Customer's app registration (managed identity):

• Mail.Send is scoped to a single shared mailbox configured by the administrator. The API sends only from this designated mailbox — it cannot enumerate or access other mailboxes.
• User.Read.All (application) is required to validate the shared mailbox exists and to resolve notification recipient email addresses server-side. It does not access mailbox contents.
• TeamsAppInstallation.ReadForUser.All is used to pre-check whether the Teams app is installed for a recipient before dispatching a Teams notification. The API queries GET /users/{userId}/teamwork/installedApps filtered by the AccessPoint app ID. This avoids wasted Platform API calls for users who haven't installed the app.
• Application.Read.All is used during Teams setup validation in the Setup panel to verify that the Realizer publisher enterprise app has been consented in the customer's tenant. It queries GET /servicePrincipals filtered by the publisher's app ID. Read-only — it does not modify any application registrations.
• AppCatalog.Read.All is used during Teams setup validation to check whether the AccessPoint Teams app is available in the organization's Teams app catalog. Read-only — it does not modify the catalog.

Realizer enterprise application (publisher's multi-tenant app):

• TeamsActivity.Send sends activity feed notifications visible only to the target user. It does not access Teams messages, channels, or any other tenant data. The Graph sendActivityNotification API requires that the caller be the same app registration that owns the Teams manifest — since AccessPoint is distributed via AppSource, this must be the publisher's app, not the customer's. Notifications use Text topic source with a deep link URL containing subEntityId so clicking a notification opens the relevant detail panel. The TeamsAppId field is set on each notification to display the AccessPoint app icon — this must be the catalog ID resolved via AppCatalogs.TeamsApps, not the manifest external ID. Template parameters use {actorName} and {requestNumber} (actor is a reserved Teams system token). Teams notifications default to Off and must be explicitly enabled in the Setup panel after the administrator grants consent.
• AppCatalog.Read.All is used by the Platform API to resolve the Graph catalog app ID from the manifest external ID. The sendActivityNotification API requires the catalog ID (not the manifest ID) in the TeamsAppId field. Read-only — it does not modify the catalog.
• User.Read is a basic delegated scope required for the Graph API sign-in.

Dependency Inventory

Runtime Dependencies (API)

Package	Version	Purpose	License
ASP.NET Core 10	10.0	Web API framework	MIT
Entity Framework Core	10.x	ORM / database access	MIT
Microsoft.Graph	5.x	Graph API SDK (email, Teams, users)	MIT
Azure.Identity	1.x	Managed Identity credential provider	MIT
Azure.Storage.Blobs	12.x	Blob Storage SDK	MIT
Syncfusion.DocIORenderer.Net.Core	32.2.8	Word → PDF conversion	Commercial (Syncfusion)
Syncfusion.PresentationRenderer.Net.Core	32.2.8	PowerPoint → PDF conversion	Commercial (Syncfusion)
Syncfusion.XlsIORenderer.Net.Core	32.2.8	Excel → PDF conversion	Commercial (Syncfusion)
SkiaSharp	3.119.1	Graphics rendering (Syncfusion dependency)	MIT

Runtime Dependencies (SPFx)

Package	Version	Purpose	License
@microsoft/sp-core-library	1.22.1	SPFx core	Microsoft EULA
@microsoft/sp-http	1.22.1	HTTP client (AadHttpClient, SPHttpClient)	Microsoft EULA
React	17.x	UI framework	MIT
@fluentui/react	8.x	UI component library	MIT
@pnp/spfx-controls-react	3.x	SharePoint-specific controls	MIT

External Services (Runtime)

Service	Data Sent	Purpose
Microsoft Graph API	Email content, Teams payloads, user queries	Notifications, user resolution
Syncfusion CDN (cdn.syncfusion.com)	None (asset download only)	Document viewer JavaScript/CSS (browser-side)
Realizer Platform API	License key, tenant ID	License validation

Disaster Recovery and Business Continuity

Azure SQL Database

Feature	Default Configuration	Customer Can Modify
Backup	Automated backups (Azure-managed)	Yes — configure retention, geo-redundancy
Point-in-time restore	7 days (Basic tier)	Yes — upgrade tier for longer retention
Geo-replication	Not enabled by default	Yes — add active geo-replication
Long-term retention	Not enabled by default	Yes — configure LTR policies

Azure Blob Storage

Feature	Default Configuration	Customer Can Modify
Redundancy	LRS (Locally Redundant Storage)	Yes — upgrade to GRS, ZRS, RA-GRS
Soft delete	Platform default	Yes — enable blob soft delete
Versioning	Not enabled by default	Yes — enable blob versioning

App Service

Feature	Default Configuration	Customer Can Modify
Availability	Single instance (P1v3 tier)	Yes — scale out, add deployment slots
Region	Customer-selected	Yes — deploy to multiple regions
Backup	Not enabled by default	Yes — configure App Service backup

Recovery Point Objective (RPO) / Recovery Time Objective (RTO)

These are determined by the customer's Azure configuration choices (tier, redundancy, geo-replication). The application itself is stateless — all state is in Azure SQL and Blob Storage. A fresh App Service deployment with the same database connection restores full functionality.

Update and Patching Lifecycle

SPFx Web Part Updates

• Distributed via Microsoft AppSource (or tenant App Catalog for manual deployments)
• SharePoint administrators approve updates in the App Catalog
• Updates deploy to all sites using the web part automatically after approval
• No downtime — SharePoint serves the new assets on next page load

API Updates

• Published as a new deployment to the customer's App Service
• Customers control when to apply updates (Azure DevOps pipeline, GitHub Actions, or manual)
• Database schema changes delivered as DacPac migrations (additive, non-destructive)
• Zero-downtime deployments supported via App Service deployment slots

Configuration Pack Updates

• Jurisdiction-specific configuration (request types, notification templates, choice fields) delivered as importable Configuration Packs
• Imported via the AccessPoint admin Settings panel
• Non-destructive — existing customizations are preserved

Security Patching

Component	Patching Responsibility
OS / runtime (.NET)	Azure (managed by App Service platform)
Application code	Publisher (via AppSource / deployment)
Azure SQL	Azure (managed platform)
SPFx framework	Microsoft (via M365 platform updates)
Third-party NuGet / npm packages	Publisher (regular dependency updates)

Configuration Management

Security Hardening Defaults

The Bicep deployment template applies the following security hardening by default:

Setting	Value	Purpose
httpsOnly	true	Redirect all HTTP traffic to HTTPS
minTlsVersion	1.2	Reject connections below TLS 1.2
ftpsState	Disabled	Disable FTPS access to App Service
scmBasicAuth	Disabled	Disable basic auth on the SCM/Kudu endpoint
http20Enabled	true	Enable HTTP/2
SQL Entra-only auth	Enabled	SQL password authentication disabled
Managed Identity	System-Assigned	No stored credentials

Application Configuration

All application configuration is stored in Azure SQL (the TenantSettings table), not in environment variables, config files, or Azure Key Vault. This means:

• No secrets in appsettings.json or App Service configuration
• No credentials to rotate (Managed Identity handles all authentication)
• Configuration changes take effect immediately without redeployment
• Configuration is included in Azure SQL database backups

The only values stored in App Service configuration are:

Setting	Purpose
Connection string	Azure SQL connection string (uses Managed Identity — no password)
APPLICATIONINSIGHTS_CONNECTION_STRING	Application Insights ingestion endpoint

Change Management

• Application code changes — Published by the vendor as versioned releases. Customers control when updates are applied.
• Database schema changes — Delivered as DacPac migrations. All migrations are additive and non-destructive (no column drops, no data loss).
• Configuration changes — Made by the department's AccessPoint Administrator through the Settings panel. All configuration changes are captured in the audit trail.
• Azure infrastructure changes — Managed by the department's Azure administrators through standard Azure governance processes.

Incident Response

Publisher Responsibilities

Realizer Services Inc. maintains an incident response process for application-level security events:

Area	Commitment
Security vulnerability notification	Customers are notified of confirmed vulnerabilities affecting AccessPoint within 72 hours of validation
Patch availability	Critical security patches are published within 14 days of confirmed vulnerability; high-severity patches within 30 days
Incident communication	Direct notification to affected customers via email with description, impact assessment, and remediation guidance
Post-incident review	Root cause analysis provided to affected customers upon request

Customer Responsibilities

Since AccessPoint runs within the customer's Azure tenant, the department retains responsibility for:

• Azure platform incidents — Monitoring Azure Service Health for their subscription
• Tenant security incidents — Responding to Entra ID sign-in anomalies, Conditional Access violations, and other identity-related events
• Reporting to CCCS — Reporting cyber security events to the Canadian Centre for Cyber Security per GC incident reporting requirements
• Access revocation — Disabling compromised user accounts in Entra ID (immediately effective for AccessPoint since authentication is delegated)
• Log preservation — Retaining Application Insights and audit trail data for forensic analysis

Application Security Features Supporting Incident Response

Feature	How It Helps
Immutable audit trail	Every action is recorded with user, timestamp, and before/after values — cannot be modified or deleted through the API
Application Insights correlation	Request traces include correlation IDs for end-to-end tracing across SPFx → API → SQL → Graph
Log Analytics integration	Centralized log storage with KQL query support, configurable retention (30–730 days), exportable to Azure Sentinel or external SIEM
Role-based access control	Compromised accounts are limited to their assigned role — a compromised Custodian account cannot access requestor PII or other requests
No stored credentials	Managed Identity eliminates the risk of credential theft from configuration files or environment variables
Session management	JWT tokens are issued by Entra ID with standard expiry — AccessPoint does not maintain its own session state

Compliance Considerations

Regulatory Alignment

Regulation	How AccessPoint Supports Compliance
Canada ATIA (Access to Information Act)	Request tracking, statutory deadline management, extension requests, disposition tracking, annual reporting
US FOIA (Freedom of Information Act)	Multi-track processing, exemption tracking, fee management, appeal tracking
EU GDPR (General Data Protection Regulation)	Data minimization (PII filtering), right of access tracking, retention management, audit trail
Provincial/State regulations	Configurable request types, deadlines, and fee structures per jurisdiction

Data Classification

Data Category	Classification	Location
Requestor PII (name, email, address)	Protected / Confidential	Azure SQL (customer tenant)
Request records	Protected / Confidential	Azure SQL (customer tenant)
Uploaded documents	Classification varies	Azure Blob Storage (customer tenant)
Application configuration	Internal	Azure SQL (customer tenant)
Telemetry / logs	Internal	Application Insights (customer tenant)
Audit trail	Protected	Azure SQL (customer tenant, immutable)

Accessibility

• UI built with Fluent UI 8 (Microsoft's accessible component library)
• WCAG 2.1 AA compliance through Fluent UI's built-in ARIA attributes and keyboard navigation
• Full dark theme and high-contrast theme support via SharePoint/Teams theme integration (18 CSS custom properties with semantic fallbacks)
• Teams-optimized layout: redundant branding hidden, navigation inline with actions, larger font for readability

Data Retention

• Configurable retention periods per request type (RetentionPeriodMonths and RetentionStartPoint)
• Automated retention review dashboard shows only requests whose retention expiry has passed (not future expiry)
• Retention purge deletes database records and Azure Blob Storage artifacts (document blobs, converted PDFs, annotations, export packages)
• Retention purge log provides compliance-grade deletion audit trail

Azure Resource Inventory

Resources deployed by the Bicep template into the customer's Azure subscription:

Resource	Azure Resource Type	SKU (Default)	Purpose
app-accesspoint-{tenant}	Microsoft.Web/sites	P1v3 (Premium)	Web API hosting
plan-accesspoint-{tenant}	Microsoft.Web/serverfarms	P1v3 Linux	App Service Plan
sql-accesspoint-{tenant}	Microsoft.Sql/servers	—	SQL Server logical server (Entra-only auth)
sqldb-accesspoint-{tenant}	Microsoft.Sql/servers/databases	Basic (2 GB)	Application database
insights-accesspoint-{tenant}	Microsoft.Insights/components	—	Application Insights
log-accesspoint-{tenant}	Microsoft.OperationalInsights/workspaces	PerGB2018	Log Analytics workspace
accesspoint{tenant}docs	Microsoft.Storage/storageAccounts	—	Document file storage (Blob, Microsoft-managed AES-256 encryption)

Conditionally deployed (only when alertEmailAddress is provided):

Resource	Azure Resource Type	Purpose
alert-{baseName}-server-errors	Microsoft.Insights/metricAlerts	HTTP 5xx alert rule
alert-{baseName}-high-latency	Microsoft.Insights/metricAlerts	Response time alert rule

Optional post-deployment hardening:

Resource	Azure Resource Type	Purpose
Key Vault	Microsoft.KeyVault/vaults	Customer-managed encryption keys (CMK) for Blob Storage

Default SKU Rationale

The default template deploys P1v3 (Premium) SKUs suitable for production workloads. Customers can scale up or down according to organizational requirements:

Upgrade Path	When
App Service → S1/P1v3	Production workloads, deployment slots, custom domains
SQL Database → S0/S1	Higher DTU, longer backup retention, geo-replication
App Service Plan scale-out	High user concurrency

Port and Protocol Summary

Port	Protocol	Direction	Source	Destination	Purpose
443	HTTPS	Inbound	Browser	App Service	API requests
443	HTTPS	Outbound	App Service	graph.microsoft.com	Graph API calls
443	HTTPS	Outbound	App Service	*.blob.core.windows.net	Blob Storage
443	HTTPS	Outbound	App Service	Publisher License API	License validation
443	HTTPS	Outbound	Browser	cdn.syncfusion.com	Document viewer assets
1433	TDS/TCP	Outbound	App Service	Azure SQL	Database queries

All traffic is encrypted. No unencrypted protocols are used. No custom ports are required.