Merge master: keep the wizard docs and restore the from-source path

master fixed three real problems in the manual build instructions — the clone
URL still said YOUR_ORG, a Copy-Item step copied a dist folder Vite no longer
produces, and the production connection string lacked Encrypt/TrustServerCertificate.

This branch had rewritten that whole part of the README around the new setup
wizard, and in doing so dropped the Setup, Development and Production Deployment
sections entirely — while Prerequisites still advertised a "Building from source
(Option 3)" path that no longer existed. Resolving in favour of either side
would have lost something real.

Both are kept: the wizard remains the primary install, and master's sections
return as "Build from source (Option 3)" with all three of its fixes intact.

SECURITY.md, docs/THREAT_MODEL.md and docs/PROJECT_SUMMARY.md merged cleanly and
are taken from master unchanged.

Author: sameerk27

README.md

@@ -206,6 +206,117 @@ the resulting binaries would differ from the ones you tested.
 
 
 
+## Build from source (Option 3)
+
+Only needed if you are not using the setup wizard or Docker — for development,
+or to run Vigil365 on a host you build on yourself.
+
+### 1. Clone and configure secrets
+
+```powershell
+git clone https://github.com/sameerk27/vigil365.git
+cd vigil365
+
+cd src\M365SecurityDashboard.Api
+dotnet user-secrets init
+dotnet user-secrets set "Graph:TenantId"     "YOUR_TENANT_ID"
+dotnet user-secrets set "Graph:ClientId"     "YOUR_CLIENT_ID"
+dotnet user-secrets set "Graph:ClientSecret" "YOUR_CLIENT_SECRET"
+```
+
+> **Never put real credentials in `appsettings.json`** — use User Secrets for development and environment variables or `appsettings.Production.json` (gitignored) for production.
+
+### 2. Set up the database
+
+```powershell
+# Option A: let the API auto-create on first run (requires db-create rights)
+# Option B: pre-create manually
+sqlcmd -S .\SQLEXPRESS -E -I -i .\database\schema.sql
+```
+
+### 3. Build the frontend
+
+```powershell
+cd src\m365-security-dashboard-client
+npm install
+npm run build
+```
+
+> `npm run build` outputs directly into `..\M365SecurityDashboard.Api\wwwroot`
+> (configured via Vite `outDir`) — no copy step needed.
+
+### 4. Run the API
+
+```powershell
+cd src\M365SecurityDashboard.Api
+$env:ASPNETCORE_ENVIRONMENT = "Development"
+dotnet run
+```
+
+Open **http://localhost:5000**
+
+---
+
+## Development (hot-reload)
+
+Run both simultaneously:
+
+```powershell
+# Terminal 1 — backend
+cd src\M365SecurityDashboard.Api
+$env:ASPNETCORE_ENVIRONMENT = "Development"
+dotnet watch run
+
+# Terminal 2 — frontend
+cd src\m365-security-dashboard-client
+npm run dev
+```
+
+Frontend dev server: `http://localhost:5173` (proxies API calls to backend)
+
+---
+
+## Production Deployment (Windows Service)
+
+```powershell
+# 1. Build frontend (outputs straight into the API's wwwroot)
+cd src\m365-security-dashboard-client
+npm install && npm run build
+
+# 2. Publish API
+cd ..\M365SecurityDashboard.Api
+dotnet publish -c Release -o C:\Apps\M365SecurityDashboard
+
+# 3. Create appsettings.Production.json in publish folder
+# (see template below — this file is gitignored)
+
+# 4. Install as Windows Service
+sc.exe create M365SecurityDashboard `
+  binPath= "C:\Apps\M365SecurityDashboard\M365SecurityDashboard.Api.exe --environment Production --urls http://localhost:8080" `
+  start= auto
+sc.exe start M365SecurityDashboard
+```
+
+**`appsettings.Production.json` template** (create this file manually, never commit it):
+
+```json
+{
+  "ConnectionStrings": {
+    "DefaultConnection": "Server=.\\SQLEXPRESS;Database=M365SecurityDashboard;Trusted_Connection=True;Encrypt=True;TrustServerCertificate=True"
+  },
+  "Graph": {
+    "TenantId": "YOUR_TENANT_ID",
+    "ClientId": "YOUR_CLIENT_ID",
+    "ClientSecret": "YOUR_CLIENT_SECRET",
+    "CollectionIntervalMinutes": 15,
+    "DevicesNotCheckedInDays": 7,
+    "SignInLookbackHours": 24
+  }
+}
+```
+
+---
+
 ## HTTPS / TLS (required for production)
 
 Outside Development the app enforces HTTPS (HSTS + redirect). Plain HTTP is only

SECURITY.md

@@ -4,6 +4,45 @@
 
 If you find a security issue (e.g. credentials being logged, an endpoint leaking data), please **do not open a public issue**. Open a [GitHub Security Advisory](https://github.com/sameerk27/vigil365/security/advisories/new) instead so it can be fixed before public disclosure.
 
+Please include the affected version/commit, reproduction steps, and potential impact. We aim to acknowledge reports within a few business days and ask for reasonable time to remediate before public disclosure.
+
+---
+
+## Supported Versions
+
+Actively developed; security fixes target the latest `master`. Pin to a released commit for production and review changes before upgrading.
+
+---
+
+## Design & Deployment Model
+
+Vigil365 is a **self-hosted, single-tenant** application meant to run on infrastructure the operating organisation controls — **not** a public multi-tenant SaaS.
+
+- **Read-only against your tenant** — Graph access is app-only (client credentials) with `*.Read.All` permissions only; the app never writes to the M365 tenant.
+- **Data stays in-tenant** — collected data is stored in the operator's own SQL database; nothing is sent to any third-party service.
+- **Network isolation is a primary control** — designed to sit on a private network / behind a reverse proxy, not exposed directly to the internet.
+
+---
+
+## Current Security Controls
+
+- **Secrets encrypted at rest** — SMTP password, webhook URLs, and the Graph client secret are DPAPI-encrypted; secrets are never returned by the API.
+- **Database transport encryption** — SQL connections use `Encrypt=True`.
+- **TLS in production** — HSTS + HTTPS redirection enforced outside Development; TLS via reverse proxy or Kestrel certificate (see README "HTTPS / TLS").
+- **Safe error handling** — API errors return generic messages; detail goes to server logs only.
+- **Security headers** — `X-Frame-Options: DENY`, `X-Content-Type-Options: nosniff`, `Referrer-Policy: no-referrer`.
+- **Least privilege** — read-only Graph permission set scoped to the monitored services.
+
+## Hardening In Progress
+
+Implemented on a development branch and rolling into releases: identity sign-in (Entra ID / MSAL), role-based access control (Admin/Analyst/Viewer), an append-only audit trail, and certificate-based Graph auth. See `docs/PROJECT_SUMMARY.md`.
+
+## Operator Responsibilities
+
+- Keep the app registration's client secret/certificate in a secret store; never commit credentials; rotate anything that may have been exposed.
+- Serve over HTTPS in production and restrict network exposure.
+- Apply OS, .NET, SQL Server, and dependency updates.
+
 ---
 
 ## Reporting a Broken Graph API Endpoint

docs/PROJECT_SUMMARY.md

@@ -0,0 +1,80 @@
+# Vigil365 — Project Summary
+
+A self-hosted, open-source Microsoft 365 security dashboard. It aggregates
+security posture and alerts from across the Microsoft 365 stack — Defender XDR,
+Entra ID, Intune, Exchange Online, and Purview — into a single pane of glass.
+All data stays in the customer's own tenant/infrastructure; there is no
+third-party SaaS in the data path.
+
+> **Status note:** the public `master` branch reflects the released app. A large
+> authentication / multi-user / setup update (sections marked 🆕 below) is on the
+> `feature/microsoft-login` branch, validated locally, not yet merged/published.
+
+---
+
+## What it does
+
+| Area | Coverage |
+|------|----------|
+| Identity | Risky users, risky sign-ins, risk detections, MFA coverage, PIM, foreign sign-ins |
+| Devices | Intune compliance, non-compliant + stale devices, Defender endpoint alerts |
+| Email | Defender for Office 365 alerts (malware/phish/spam) |
+| Incidents | Unified Defender XDR incidents + alerts |
+| Compliance | DLP, MCAS, insider-risk, attack simulations |
+| Service Health | M365 service advisories |
+| Conditional Access | Policy inventory + state |
+| Audit / Sign-ins | Unified audit log, geographic sign-in view |
+| Alert Center | Custom alert policies, server-side evaluation, notifications (Teams/Email/webhook), per-alert snooze, silent auto-resolve |
+
+## Architecture & stack
+
+| Layer | Technology |
+|-------|-----------|
+| Backend | ASP.NET Core 8 Minimal API |
+| Frontend | React 18 + TypeScript + Vite (SPA) |
+| Data source | Microsoft Graph API — app-only (client credentials), **read-only** |
+| Scheduler | .NET BackgroundService, 15-minute collection cycle |
+| Storage | SQL Server Express by default; scales to SQL Server / Azure SQL (connection-string swap, no code change) |
+
+## Security posture
+
+- **Authentication** 🆕 — Microsoft/Entra ID login (MSAL); backend validates Bearer tokens (audience-scoped).
+- **Authorization** 🆕 — role-based access (Admin / Analyst / Viewer). Roles are app-managed (stored in-app), not Entra App Roles; enforced server-side via authorization policies and a claims transformation.
+- **User management** 🆕 — in-app admin UI to add/pre-provision, change roles, remove users, and send/resend access-notification emails. Last-admin lockout guards.
+- **Audit trail** 🆕 — append-only log of security-relevant actions (user add/role-change/remove/invite, settings, setup), with actor identity from the validated token.
+- **Encryption at rest** — secrets (SMTP password, webhook URLs, Graph client secret) DPAPI-encrypted; SQL connection uses `Encrypt=True`.
+- **Encryption in transit** 🆕 — HSTS + HTTPS redirection enforced outside Development; TLS via reverse proxy or Kestrel certificate (documented).
+- **Least privilege** — Graph permissions are all `*.Read.All`; the app never writes to the tenant.
+- **Network model** — designed as an internal/self-hosted tool; not a public multi-tenant SaaS.
+
+## Install model 🆕
+
+Reduced to ~3 steps:
+1. `install.ps1` — checks prerequisites, builds the frontend, publishes the API, optional Windows-service install.
+2. One-time Entra app registration (app-only Graph permissions + SPA redirect URI + `access_as_user` scope).
+3. Sign in (first user becomes Admin) → **in-app first-run setup wizard** to enter Graph credentials (stored encrypted; no JSON editing).
+
+## Roadmap
+
+**Recently landed (local branch):** Microsoft login, RBAC, in-app user management + invites, audit trail, production HTTPS enforcement, one-shot installer + first-run setup wizard.
+
+**In progress / planned:**
+- Trends & history page — metric snapshots over time (risky users, compliance, secure score) with exec-friendly up/down/flat readouts.
+- Certificate-based Graph auth (replacing client secret) + secret-vault integration.
+- Data retention / pruning policies.
+- `register-app.ps1` to script the Entra app registration.
+- Optional SQLite backend to drop the SQL Server dependency.
+- Docker / docker-compose deployment.
+- CI with automated tests; dependency scanning.
+
+## Scope & honest limitations
+
+- Not a SIEM — no raw-log ingestion, KQL hunting, or SOAR. It complements tools like Microsoft Sentinel rather than replacing them.
+- Visibility is bounded by what Microsoft Graph exposes.
+- Single-tenant, self-hosted by design.
+- Historical trends accrue from when snapshotting begins (no retroactive history).
+
+## Links
+
+- Repository: https://github.com/sameerk27/vigil365
+- License: MIT

docs/THREAT_MODEL.md

@@ -0,0 +1,67 @@
+# Vigil365 — Threat Model
+
+A concise threat model covering trust boundaries, data flows, assets, and the
+controls that protect them. Scope is the self-hosted, single-tenant deployment
+described in `SECURITY.md`.
+
+## Assets
+
+| Asset | Sensitivity |
+|-------|-------------|
+| Graph API credentials (tenant/client ID, client secret/cert) | **Critical** — grant read access to tenant security data |
+| Collected M365 security data (alerts, risky users, devices, sign-ins) | High — reveals security posture |
+| Notification secrets (SMTP password, webhook URLs) | High |
+| User roles / access assignments | Medium |
+| Audit trail | Medium — integrity matters for accountability |
+
+## Trust boundaries
+
+```
+[ Operator's browser ] --HTTPS--> [ Reverse proxy / Kestrel TLS ]
+                                          |
+                                   [ Vigil365 API ]  --app-only token-->  [ Microsoft Graph ]
+                                          |
+                                   [ SQL database (in-tenant) ]
+```
+
+1. **Browser ↔ App** — authenticated user session; should always be HTTPS in
+   production. Untrusted input crosses here.
+2. **App ↔ Microsoft Graph** — outbound, app-only OAuth2; read-only scopes.
+3. **App ↔ Database** — trusted, same-network; transport-encrypted.
+4. **App ↔ SMTP/webhooks** — outbound notifications; secrets decrypted in memory
+   only at send time.
+
+## Data flows
+
+- The background collector pulls current-state security data from Graph every
+  ~15 minutes and persists it to SQL.
+- The browser SPA reads that data through the API.
+- Privileged/mutating actions (acknowledge, snooze, settings, user management)
+  are authenticated and, where applicable, role-gated server-side.
+
+## Threats & mitigations (STRIDE-aligned)
+
+| Threat | Mitigation |
+|--------|-----------|
+| **Spoofing** — unauthorised access to the dashboard | Entra ID sign-in (in progress); network isolation; tenant-scoped login |
+| **Tampering** — modifying data/config | Server-side authorization; read-only Graph (no tenant writes); append-only audit trail |
+| **Repudiation** — denying an action | Audit entries capture actor identity from the validated token |
+| **Information disclosure** — leaking secrets or data | Secrets DPAPI-encrypted at rest and never returned by the API; generic error messages; data stays in-tenant; HTTPS in production |
+| **Denial of service** | Self-hosted/internal exposure limits blast radius; Graph 429 handling with backoff |
+| **Elevation of privilege** | Role policies enforced on the server, not just hidden in the UI; last-admin lockout guards |
+
+## Out of scope / assumptions
+
+- The host OS, SQL Server, and network are administered and patched by the operator.
+- The Entra app registration is correctly configured with least-privilege,
+  read-only permissions.
+- Vigil365 is **not** a SIEM and does not ingest raw logs; visibility is bounded
+  by what Microsoft Graph exposes.
+- Physical security and tenant-admin trust are assumed.
+
+## Residual risks
+
+- A compromised Graph credential exposes read access to tenant security data —
+  hence credential storage in a vault and rotation are operator responsibilities.
+- Until identity sign-in is merged to the released branch, network isolation is
+  the primary access control for the public release.