|
2 | 2 | title: "Multi-frontend support" |
3 | 3 | description: Overview on what BFF multi-frontend support is, how it works and why you would use it. |
4 | 4 | date: 2024-06-11T08:22:12+02:00 |
| 5 | +sidebar: |
| 6 | + label: "Multiple Frontends" |
| 7 | + order: 5 |
| 8 | + badge: |
| 9 | + text: v4 |
| 10 | + variant: tip |
5 | 11 | --- |
6 | 12 |
|
7 | 13 | BFF V4.0 introduces the capability to support multiple BFF Frontends in a single host. This helps to simplify your application landscape by consolidating multiple physical BFF Hosts into a single deployable unit. |
8 | 14 |
|
9 | 15 | A single BFF setup consists of: |
10 | | -1. A browser based application, typically built using technology like React, Angular or VueJS. This is typically deployed to a CDN. |
| 16 | +1. A browser based application, typically built using technology like React, Angular or VueJS. This is typically deployed to a Content Delivery Network (CDN). |
11 | 17 | 2. A BFF host, that will take care of the OpenID Connect login flows. |
12 | | -3. An api surface, exposed and protected by the BFF. |
| 18 | +3. An API surface, exposed and protected by the BFF. |
13 | 19 |
|
14 | | -With the BFF Multi-frontend support, you can logically host multiple of these BFF Setups in a single host. The concept of a single frontend (with OpenID Connect configuration, an api surface and a browser based app) is now codified inside the BFF. By using a flexibile frontend selection mechanism (using Origins or Paths to distinguish), it's possible to create very flexible setups. |
| 20 | +With the BFF Multi-frontend support, you can logically host multiple of these BFF Setups in a single host. The concept of a single frontend (with OpenID Connect configuration, an API surface and a browser based app) is now codified inside the BFF. By using a flexible frontend selection mechanism (using Origins or Paths to distinguish), it's possible to create very flexible setups. |
15 | 21 |
|
16 | | -The BFF dynamically configures the aspnet core authentication pipeline according to recommended practices. For example, when doing Origin based routing, it will configure the cookies using the most secure settings and with the prefix [__Host](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie). |
| 22 | +The BFF dynamically configures the aspnet core authentication pipeline according to recommended practices. For example, when doing Origin based routing, it will configure the cookies using the most secure settings and with the prefix [`__Host`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie). |
17 | 23 |
|
18 | 24 | Frontends can be added or removed dynamically from the system, without having to restart the system. You can do this via configuration (for example by modifying a configuration file) or programmatically. |
19 | 25 |
|
20 | 26 | :::note |
21 | | -The duende BFF V4 library doesn't ship with an abstraction to store or read frontends from a database. It's possible to implement this by creating your own store (based on your requirements), then modify the **FrontendCollection** at run-time. |
| 27 | +The Duende BFF V4 library doesn't ship with an abstraction to store or read frontends from a database. It's possible to implement this by creating your own store (based on your requirements), then modify the `FrontendCollection` at run-time. |
22 | 28 | ::: |
23 | 29 |
|
24 | 30 | ## A typical example |
25 | 31 |
|
26 | | -Consider an enterprise who hosts multiple browser based applications. Each of these applications is developed by a separate team and as such, has it's own deployment schedule. |
| 32 | +Consider an enterprise that hosts multiple browser based applications. Each of these applications is developed by a separate team and as such, has it's own deployment schedule. |
27 | 33 |
|
28 | | -There are some 'internally facing' applications that are exclusively used by internal employees. These internal employees are all present in Microsoft Entra ID, so these internally facing applications should directly authenticate against Microsoft Entra ID. These applications also use several internal api's, that due to the sensitivity, should not be accessible by external users. However, they also use some of the more common api's. These apps are only accessible via an internal DNS name, such as https://app1.internal.company.com. |
| 34 | +There are some 'internally facing' applications that are exclusively used by internal employees. These internal employees are all present in Microsoft Entra ID, so these internally facing applications should directly authenticate against Microsoft Entra ID. These applications also use several internal api's, that due to the sensitivity, should not be accessible by external users. However, they also use some of the more common api's. These apps are only accessible via an internal DNS name, such as `https://app1.internal.example.com`. |
29 | 35 |
|
30 | | -There are also several public facing applications, that are used directly by customers. These users should be able to log in using their own identity, such as a GMail, Twitter or other provider. This authentication process is handled by Duende Identity Server. There is constant development ongoing on these applications and it's not uncommon for new applications to be introduced. There should be single signon across all these public facing applictions. They are all available on the same domain name, but use path based routing to distinguish themselves, such as https://app.company.com/app1 |
| 36 | +There are also several public facing applications, that are used directly by customers. These users should be able to log in using their own identity, such as a GMail, Twitter or other provider. This authentication process is handled by Duende IdentityServer. There is constant development ongoing on these applications and it's not uncommon for new applications to be introduced. There should be single sign-on across all these public facing applications. They are all available on the same domain name, but use path based routing to distinguish themselves, such as `https://app.example.com/app1` |
31 | 37 |
|
32 | | -Then there is a partner portal. This partner portal can only be accessed by employees of the partners. Each partner should be able to bring their own identity provider. This is implemented using the Dynamic Providers feature of Duende Identity Server. |
| 38 | +There is also a partner portal. This partner portal can only be accessed by employees of the partners. Each partner should be able to bring their own identity provider. This is implemented using the [Dynamic Providers](/identityserver/ui/login/dynamicproviders/) feature of Duende IdentityServer. |
33 | 39 |
|
34 | | -This setup, where there are multiple frontends, which different authentication requirements and different api surfaces, is now supported by the BFF. |
| 40 | +This setup, with multiple frontends, each having different authentication requirements and different API surfaces, is now supported by the BFF. |
35 | 41 |
|
36 | | -Each frontend can either rely on the 'global' configuration or override (parts of) this configuration, such as the identity provider or the Client ID and Client Secret to use. |
| 42 | +Each frontend can either rely on the global configuration or override (parts of) this configuration, such as the identity provider or the Client ID and Client Secret to use. |
37 | 43 |
|
38 | 44 | It's also possible to dynamically add or remove frontends, without restarting the BFF host. |
39 | 45 |
|
40 | 46 | ## Internals |
41 | 47 |
|
42 | | -BFF V4 still allows you to manually configure the asp.net authentication options, by calling .AddAuthentication().AddOpenIdConnect().AddCookies(). However, if you wish to use the multi-frontend features, then this setup needs to become dynamic. |
| 48 | +BFF V4 still allows you to manually configure the ASP.NET Core authentication options, by calling `.AddAuthentication().AddOpenIdConnect().AddCookies()`. However, if you wish to use the multi-frontend features, then this setup needs to become dynamic. |
43 | 49 |
|
44 | | -To achieve this, the BFF automatically configures the AspNet pipeline: |
| 50 | +To achieve this, the BFF automatically configures the ASP.NET Core pipeline: |
45 | 51 |
|
46 | 52 |  |
47 | 53 |
|
48 | | -1. FrontendSelectionMiddleware. This middleware performs the frontend selection by seeing which frontend's selection criteria best matches the incoming request route. It's possible to mix both path based routing origin based routing, so the most specific will be selected. |
49 | | -2. PathMappingMiddlweare. If you use path mapping, in the selected frontend, then it will automatically *map()* the frontend's path so none of the subsequent middlewares know (or need to care) about this fact. |
50 | | -3. OpenIdCallbackMiddlware. To dynamically perform the openid connect authentication without explicitly adding each frontend as a scheme, we inject a middleware that will handle the openid connect callbacks. This only kicks in for dynamic frontends. |
51 | | -4. Your own applications logic is executed in this part of the pipeline. For example, calling .UseAuthentication(), .UseRequestLogging(), etc. |
| 54 | +1. `FrontendSelectionMiddleware` - This middleware performs the frontend selection by seeing which frontend's selection criteria best matches the incoming request route. It's possible to mix both path based routing origin based routing, so the most specific will be selected. |
| 55 | +2. `PathMappingMiddleware` - If you use path mapping, in the selected frontend, then it will automatically map the frontend's path so none of the subsequent middlewares know (or need to care) about this fact. |
| 56 | +3. `OpenIdCallbackMiddleware` - To dynamically perform the OpenID Connect authentication without explicitly adding each frontend as a scheme, we inject a middleware that will handle the OpenID Connect callbacks. This only kicks in for dynamic frontends. |
| 57 | +4. Your own applications logic is executed in this part of the pipeline. For example, calling `.UseAuthentication(), .UseRequestLogging()`, etc. |
52 | 58 |
|
53 | 59 | After your application's logic is executed, there are two middlewares registered as fallback routes: |
54 | 60 |
|
55 | | -5. MapRemoteRoutesMiddlware. This will handle any configured remote routes. Note, it will not handle plain yarp calls, only routes that are specifically added to a frontend. |
| 61 | +5. `MapRemoteRoutesMiddleware` - This will handle any configured remote routes. Note, it will not handle plain YARP calls, only routes that are specifically added to a frontend. |
56 | 62 |
|
57 | | -6. ProxyIndexMiddleware. If configured, this proxy the IndexHTML to start the browser based app. |
| 63 | +6. `ProxyIndexMiddleware` - If configured, this proxy the `index.html` to start the browser based app. |
58 | 64 |
|
59 | 65 |
|
0 commit comments