Add OIDC provider docs

Author: webprofusion-chrisc

docs/hub/guides/oidc.md

@@ -0,0 +1,20 @@
+# Configuring and using OpenID Connect (OIDC)
+
+The hub can be configured to allow users to sign in by authenticating against an external OIDC provider such as Azure Entra.
+
+## Configure an OIDC provider
+
+You can add the configuration for a new OIDC provider under Settings > Security > OpenID Connect (OIDC).
+
+You will need to provide:
+- **Provider Name** for display on the sign in screen
+- **Authority URL** e.g. `https://login.microsoftonline.com/<your tenant id>`
+- **Client ID**
+- **Client Secret**
+- **OpenID Scopes**, at a minimum `openid`
+- **Response Type**: `code`
+- **Response Mode**: `form_post`
+
+## Signing In
+
+Once an OIDC provider is configured, any user can try to sign in using that provider. A stub account will then be created within the system with no roles assigned. The administrator can then assign hub roles to that account. When the user signs back in they will have the assigned roles and feature access.

docs/hub/index.md

@@ -16,6 +16,7 @@ The product is available to try out as an beta version (e.g. not the finished pr
 - **Self-hosted, cross-platform including Linux, macOS or Windows.**
 - Optionally manage thousands of certs across hundreds of existing *Certify Certificate Manager* instances, or renew centrally, from a "single pane of glass" UI.
 - Multi-user role based access security for administration and consuming certificates, with support for app/service security principles and individual scoped API access
+- Optional single sign on with [OIDC support](./guides/oidc.md) via providers such as Azure Entra.
 - Distribute certs using optional installed agents, deployment tasks, or use the API to pull the latest cert using your own integrations.
 - Optional centralized DNS challenges compatible with most popular ACME clients, so that privileged DNS credentials do not need to be stored across individual ACME clients.
 - Optional integrated visibility of renewal status for third party ACME clients such as win-acme, Certbot and acme.sh

docs/hub/known-issues.md

@@ -15,14 +15,11 @@ The UI needs to know the URL of the API it should talk to. This is configured by
 
 If the problem occurs with a new docker container, follow the above and set the url to the require host and port e.g. `http://localhost:8080`
 
-#### Refreshing a page returns a blank page
-If using the combined hub service container image or serving the UI via the same service as the API, some app UI routing does not work (e.,g. reloading or bookmarking in-app URL routes). 
+#### Data caching in the UI
+Normally, when the system changes managed certificate or updates it status the change should be streamed back to the UI via SignalR. This streaming functionality is currently a work in progress and most items now update automatically.
 
 Pages that show data that might change will generally update themselves periodically (summary page, instances, charts etc) or in some cases when the underlying data changes and a message from the hub is streamed back the the UI. In some cases you may need to reload the app from the app root URL to see the latest information while the app is still under development.
 
-#### When managed certificates change, the info doesn't update in the UI
-Normally, when the system changes managed certificate or updates it status the change should be streamed back to the UI via SignalR. This streaming functionality is currently a work in progress and most items now update automatically.
-
 #### Loading time over slow connections
 The web app uses WebAssembly (WASM) and has a large application payload on initial load. Subsequent loads used cached resources.
 
@@ -34,4 +31,5 @@ Multiple instances of the Certify Agent or Management Hub service reading and wr
 
 Note: We do not provide general support for how to use different container technology and you will likely need to know more about your choice of container deployment technology than we do, if you are using containers at all. Certify Management Hub is our first product that supports deployment to containers, so we expect growing pains.
 
-
+### Windows Specific Tasks
+If you will be commonly running PowerShell etc and interacting with Windows Server using Windows AAuthentication you should host the Management Hub on a Windows Server install. The hub *can* be used in containers (or hosted directly on Linux) but with reduced compatibility for Windows specific things like Windows Impersonation credentials.