Update SAML documentation

astro/astro.config.mjs

@@ -117,7 +117,7 @@ export default defineConfig({
           errorOnFallbackPages: false,
           errorOnInconsistentLocale: true,
           errorOnRelativeLinks: false,
-          errorOnLocalLinks: false,
+          errorOnLocalLinks: false
         }),
       ],
       title: "Duende Software Docs",

astro/src/content/docs/bff/fundamentals/session/management/back-channel-logout.md

@@ -23,7 +23,7 @@ involving the user's browser. This design avoids problems with 3rd party cookies
 
 The back-channel logout endpoint is invoked by the remote identity provider when it determines that sessions should be
 ended. IdentityServer will send back-channel logout requests if
-you [configure](/identityserver/reference/models/client.md#authentication--session-management) your client's
+you [configure](/identityserver/reference/v8/models/client.md#authentication--session-management) your client's
 `BackChannelLogoutUri`. When a session ends at IdentityServer, any client that was participating in that session that
 has a back-channel logout URI configured will be sent a back-channel logout request. This typically happens when another
 application signs out. [Expiration](/identityserver/ui/server-side-sessions/session-expiration.mdx)

astro/src/content/docs/bff/fundamentals/session/management/user.md

@@ -66,7 +66,7 @@ handler's [ClaimAction](https://docs.microsoft.com/en-us/dotnet/API/microsoft.as
 infrastructure, or by
 using [claims transformation](https://docs.microsoft.com/en-us/dotnet/API/microsoft.aspnetcore.authentication.iclaimstransformation?view=aspnetcore-7.0).
 For example, if you add a [claim](/identityserver/fundamentals/claims.md) to
-the [userinfo endpoint](/identityserver/reference/endpoints/userinfo.md) at IdentityServer that you would like to include
+the [userinfo endpoint](/identityserver/reference/v8/endpoints/userinfo.md) at IdentityServer that you would like to include
 in the */bff/user* endpoint, you need to add a corresponding ClaimAction in the BFF's OpenID Connect Handler to include
 the claim in the BFF's session.
 

astro/src/content/docs/identityserver/apis/aspnetcore/authorization.md

@@ -71,7 +71,7 @@ app.MapGet("/", () =>
 
 Historically, Duende IdentityServer emitted the `scope` claims as an array in the JWT. This works very well with the .NET deserialization logic, which turns every array item into a separate claim of type `scope`.
 
-The newer *JWT Profile for OAuth* [spec](/identityserver/overview/specs.md) mandates that the scope claim is a single space delimited string. You can switch the format by setting the `EmitScopesAsSpaceDelimitedStringInJwt` on the [options](/identityserver/reference/options.md). But this means that the code consuming access tokens might need to be adjusted. The following code can do a conversion to the *multiple claims* format that .NET prefers:
+The newer *JWT Profile for OAuth* [spec](/identityserver/overview/specs.md) mandates that the scope claim is a single space delimited string. You can switch the format by setting the `EmitScopesAsSpaceDelimitedStringInJwt` on the [options](/identityserver/reference/v8/options.md). But this means that the code consuming access tokens might need to be adjusted. The following code can do a conversion to the *multiple claims* format that .NET prefers:
 
 ```csharp
 namespace IdentityModel.AspNetCore.AccessTokenValidation;

astro/src/content/docs/identityserver/aspnet-identity/schemes.md

@@ -60,7 +60,7 @@ IdentityServer always uses the `"idsrv.external"` scheme here, available in the
 ### Check Session Cookie
 
 IdentityServer session management requires a separate cookie to monitor the session state without sending the large authentication cookie.
-The [User Session Service](/identityserver/reference/services/user-session-service.md) manages this cookie.
+The [User Session Service](/identityserver/reference/v8/services/user-session-service.md) manages this cookie.
 
 - **Default Name:** `"idsrv.session"` (Constant: `IdentityServerConstants.DefaultCheckSessionCookieName`).
 

astro/src/content/docs/identityserver/configuration/dcr.mdx

@@ -109,7 +109,7 @@ create a new ASP.NET Core Web application which will host the Configuration API.
     needs an implementation of this interface.
 
     You can either use the Entity Framework Core-based implementation, or implement
-    the interface yourself. See [the IClientConfigurationStore reference](/identityserver/reference/stores/index.md)
+    the interface yourself. See [the IClientConfigurationStore reference](/identityserver/reference/v8/stores/index.md)
     for more details. If you wish to use the built-in implementation, install its NuGet
     package and add it to the ASP.NET Core service provider.
 
@@ -163,7 +163,7 @@ and configure the store implementation.
     needs an implementation of this interface.
 
     You can either use the Entity Framework Core-based implementation, or implement
-    the interface yourself. See [the IClientConfigurationStore reference](/identityserver/reference/stores/index.md)
+    the interface yourself. See [the IClientConfigurationStore reference](/identityserver/reference/v8/stores/index.md)
     for more details. If you wish to use the built-in implementation, install its NuGet
     package and add it to the ASP.NET Core service provider.
 
@@ -192,7 +192,7 @@ and configure the store implementation.
 
 ### Adding the Registration Endpoint to the Discovery Document
 
-By default, the Dynamic Client Registration (DCR) endpoint is not included in the [discovery document](/identityserver/reference/endpoints/discovery.md) of Duende IdentityServer.
+By default, the Dynamic Client Registration (DCR) endpoint is not included in the [discovery document](/identityserver/reference/v8/endpoints/discovery.md) of Duende IdentityServer.
 
 To include it, change the Discovery Document options when registering IdentityServer in the service collection:
 
@@ -263,7 +263,7 @@ authentication scheme and an authorization policy that requires a particular
 scope to be present in the JWTs. You could choose any name for the scope that
 gives access to the Configuration APIs. Let's use the name
 `IdentityServer.Configuration` for this example. You would then define the
-`IdentityServer.Configuration` scope as an [ApiScope](/identityserver/reference/models/api-scope.md) in your
+`IdentityServer.Configuration` scope as an [ApiScope](/identityserver/reference/v8/models/api-scope.md) in your
 IdentityServer and allow the appropriate clients to access it.
 
 An automated process running in a CI pipeline could be configured as an OAuth client
@@ -301,7 +301,7 @@ The registration endpoint is invoked by making an HTTP POST request to the `/con
 with a JSON payload containing metadata describing the desired client as described in [RFC 7591](https://datatracker.ietf.org/doc/rfc7591/)
 and [OpenID Connect Dynamic Client Registration 1.0](https://openid.net/specs/openid-connect-registration-1_0.html).
 
-The supported metadata properties are listed in the reference section on the [`DynamicClientRegistrationRequest` model](/identityserver/reference/dcr/models.md#dynamicclientregistrationrequest).
+The supported metadata properties are listed in the reference section on the [`DynamicClientRegistrationRequest` model](/identityserver/reference/v8/dcr/models.md#dynamicclientregistrationrequest).
 A mixture of standardized and IdentityServer-specific properties are supported. Most standardized properties that
 are applicable to the client credentials or code flow grants are supported.
 
@@ -346,19 +346,19 @@ the original request, the claims principal that made the request, and a dictiona
 pass state between customized steps. Each step should update the client in the context and return an `IStepResult` to
 indicate success or failure.
 
-For more details, see the [reference section on DCR validation](/identityserver/reference/dcr/validation.md).
+For more details, see the [reference section on DCR validation](/identityserver/reference/v8/dcr/validation.md).
 
 ### Processing
 
 The request processor can be customized by implementing the `IDynamicClientRegistrationRequestProcessor` interface,
 or by extending the default `DynamicClientRegistrationRequestProcessor`. The default request processor contains virtual
 methods that allow you to override (part of) its functionality.
 
-For more details, see the [reference section on DCR request processing](/identityserver/reference/dcr/processing.md).
+For more details, see the [reference section on DCR request processing](/identityserver/reference/v8/dcr/processing.md).
 
 ### Response Generation
 
 To customize the HTTP responses of the Configuration API, you can implement the `IDynamicClientRegistrationResponseGenerator`
 interface, or extend the default `DynamicClientRegistrationResponseGenerator`.
 
-For more details, see the [reference section on DCR response generation](/identityserver/reference/dcr/response.md).
+For more details, see the [reference section on DCR response generation](/identityserver/reference/v8/dcr/response.md).

astro/src/content/docs/identityserver/data/configuration.md → astro/src/content/docs/identityserver/data/configuration.mdx

@@ -18,18 +18,18 @@ and [Resources](/identityserver/fundamentals/resources).
 Store interfaces are designed to abstract accessing the configuration data.
 The stores used in Duende IdentityServer are:
 
-* [Client store](/identityserver/reference/stores/client-store.md) for `Client` data.
-* [CORS policy service](/identityserver/reference/stores/cors-policy-service.md)
+* [Client store](/identityserver/reference/v8/stores/client-store.md) for `Client` data.
+* [CORS policy service](/identityserver/reference/v8/stores/cors-policy-service.md)
   for [CORS support](/identityserver/tokens/cors.md). Given that this is so closely tied to the `Client` configuration
   data, the CORS policy service is considered one of the configuration stores.
-* [Resource store](/identityserver/reference/stores/resource-store.md) for `IdentityResource`, `ApiResource`, and
+* [Resource store](/identityserver/reference/v8/stores/resource-store.md) for `IdentityResource`, `ApiResource`, and
   `ApiScope` data.
-* [Identity Provider store](/identityserver/reference/stores/idp-store.md) for `IdentityProvider` data.
+* [Identity Provider store](/identityserver/reference/v8/stores/idp-store.md) for `IdentityProvider` data.
 
 ## Registering Custom Stores
 
 Custom implementations of the stores must be registered in the ASP.NET Core service provider.
-There are [convenience methods](/identityserver/reference/di.md#configuration-stores) for registering these.
+There are [convenience methods](/identityserver/reference/v8/di.md#configuration-stores) for registering these.
 For example:
 
 ```csharp
@@ -38,7 +38,7 @@ builder.Services.AddIdentityServer()
     .AddClientStore<YourCustomClientStore>()
     .AddCorsPolicyService<YourCustomCorsPolicyService>()
     .AddResourceStore<YourCustomResourceStore>()
-    .AddIdentityProviderStore<YourCustomAddIdentityProviderStore>();
+    .AddIdentityProviderStore<YourCustomIdentityProviderStore>();
 ```
 
 ## Caching Configuration Data
@@ -47,7 +47,65 @@ Configuration data is used frequently during request processing.
 If this data is loaded from a database or other external store, then it might be expensive to frequently re-load the
 same data.
 
-Duende IdentityServer provides [convenience methods](/identityserver/reference/di.md#caching-configuration-data) to
+import { Tabs, TabItem } from '@astrojs/starlight/components';
+
+<Tabs syncKey="isVersion">
+<TabItem label="v8.0+">
+
+Duende IdentityServer provides [convenience methods](/identityserver/reference/v8/di#caching-configuration-data) to
+enable caching data from the various stores.
+The caching implementation is built on Microsoft's [`HybridCache`](https://learn.microsoft.com/en-us/aspnet/core/performance/caching/hybrid) from the `Microsoft.Extensions.Caching.Hybrid` package, registered as a [keyed service](https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection#keyed-services) under `ServiceProviderKeys.ConfigurationStoreCache`. For example:
+
+```csharp
+// Program.cs
+builder.Services.AddIdentityServer()
+    .AddClientStore<YourCustomClientStore>()
+    .AddCorsPolicyService<YourCustomCorsPolicyService>()
+    .AddResourceStore<YourCustomResourceStore>()
+    .AddInMemoryCaching()
+    .AddClientStoreCache<YourCustomClientStore>()
+    .AddCorsPolicyCache<YourCustomCorsPolicyService>()
+    .AddResourceStoreCache<YourCustomResourceStore>()
+    .AddIdentityProviderStoreCache<YourCustomIdentityProviderStore>();
+```
+
+For Entity Framework users, there is a convenience method `AddConfigurationStoreCache()` that enables caching for all configuration stores at once:
+
+```csharp
+// Program.cs
+builder.Services.AddIdentityServer()
+    .AddConfigurationStore(...)
+    .AddConfigurationStoreCache();
+```
+
+The duration of the data in the default cache is configurable on
+the [`IdentityServerOptions`](/identityserver/reference/v8/options#caching).
+For example:
+
+```csharp
+// Program.cs
+builder.Services.AddIdentityServer(options => {
+    options.Caching.ClientStoreExpiration = TimeSpan.FromMinutes(5);
+    options.Caching.ResourceStoreExpiration = TimeSpan.FromMinutes(5);
+})
+    .AddClientStore<YourCustomClientStore>()
+    .AddCorsPolicyService<YourCustomCorsPolicyService>()
+    .AddResourceStore<YourCustomResourceStore>()
+    .AddInMemoryCaching()
+    .AddClientStoreCache<YourCustomClientStore>()
+    .AddCorsPolicyCache<YourCustomCorsPolicyService>()
+    .AddResourceStoreCache<YourCustomResourceStore>();
+```
+
+Further customization of the cache is possible:
+
+* The caching stores use a keyed `HybridCache` instance registered under `ServiceProviderKeys.ConfigurationStoreCache`. You can customize the `HybridCache` behavior by configuring the keyed service registration (e.g., adding a distributed cache backend via `IDistributedCache`).
+* By default, only the L1 (in-memory) cache tier is used. To enable L2 (distributed) caching, register an `IDistributedCache` implementation (e.g., Redis via `AddStackExchangeRedisCache`). `HybridCache` will automatically use it as the L2 tier.
+
+</TabItem>
+<TabItem label="v7.0">
+
+Duende IdentityServer provides [convenience methods](/identityserver/reference/v8/di.md#caching-configuration-data) to
 enable caching data from the various stores.
 The caching implementation relies upon an `ICache<T>` service and must also be added to the ASP.NET Core service provider.
 For example:
@@ -62,11 +120,11 @@ builder.Services.AddIdentityServer()
     .AddClientStoreCache<YourCustomClientStore>()
     .AddCorsPolicyCache<YourCustomCorsPolicyService>()
     .AddResourceStoreCache<YourCustomResourceStore>()
-    .AddIdentityProviderStoreCache<YourCustomAddIdentityProviderStore>();
+    .AddIdentityProviderStoreCache<YourCustomIdentityProviderStore>();
 ```
 
 The duration of the data in the default cache is configurable on
-the [IdentityServerOptions](/identityserver/reference/options.md#caching).
+the [`IdentityServerOptions`](/identityserver/reference/v8/options#caching).
 For example:
 
 ```csharp
@@ -93,9 +151,12 @@ Further customization of the cache is possible:
   If you wish to customize the in-memory caching behavior, you can replace the `IMemoryCache` implementation in the
   dependency injection system.
 
+</TabItem>
+</Tabs>
+
 ## In-Memory Stores
 
-The various [in-memory configuration APIs](/identityserver/reference/di.md#configuration-stores) allow for configuring
+The various [in-memory configuration APIs](/identityserver/reference/v8/di.md#configuration-stores) allow for configuring
 IdentityServer from an in-memory list of the various configuration objects.
 These in-memory collections can be hard-coded in the hosting application, or could be loaded dynamically from a
 configuration file or a database.

astro/src/content/docs/identityserver/data/ef.md

@@ -142,7 +142,7 @@ This options class contains properties to control the operational store and `Per
 
 
 :::note
-The token cleanup feature does `not` remove persisted grants that are `consumed` (see [persisted grants](/identityserver/reference/stores/persisted-grant-store.md)). It only removes persisted grants that are beyond their `Expiration`.
+The token cleanup feature does `not` remove persisted grants that are `consumed` (see [persisted grants](/identityserver/reference/v8/stores/persisted-grant-store.md)). It only removes persisted grants that are beyond their `Expiration`.
 :::
 
 ## Database Creation And Schema Changes Across Different IdentityServer Versions