@backstage/backend-app-api 0.6.3-next.0 → 0.7.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +70 -0
- package/alpha/package.json +1 -1
- package/config.d.ts +100 -0
- package/dist/index.cjs.js +1017 -274
- package/dist/index.cjs.js.map +1 -1
- package/dist/index.d.ts +2 -2
- package/migrations/20240327104803_public_keys.js +50 -0
- package/package.json +19 -14
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,75 @@
|
|
|
1
1
|
# @backstage/backend-app-api
|
|
2
2
|
|
|
3
|
+
## 0.7.0
|
|
4
|
+
|
|
5
|
+
### Minor Changes
|
|
6
|
+
|
|
7
|
+
- 3256f14: **BREAKING**: Modules are no longer loaded unless the plugin that they extend is present.
|
|
8
|
+
|
|
9
|
+
### Patch Changes
|
|
10
|
+
|
|
11
|
+
- 10327fb: Deprecate the `getPath` option for the `httpRouterServiceFactory` and more generally the ability to configure plugin API paths to be anything else than `/api/:pluginId/`. Requests towards `/api/*` that do not match an installed plugin will also no longer be handled by the index router, typically instead returning a 404.
|
|
12
|
+
- 2c50516: Fix auth cookie issuance for split backend deployments by preferring to set it against the request target host instead of origin
|
|
13
|
+
- 7e584d6: Fixed a bug where expired cookies would not be refreshed.
|
|
14
|
+
- 1a20b12: Make the auth service create and validate dedicated OBO tokens, containing the user identity proof.
|
|
15
|
+
- 00fca28: Implemented support for external access using both the legacy token form and static tokens.
|
|
16
|
+
- d5a1fe1: Replaced winston logger with `LoggerService`
|
|
17
|
+
- bce0879: Service-to-service authentication has been improved.
|
|
18
|
+
|
|
19
|
+
Each plugin now has the capability to generate its own signing keys for token issuance. The generated public keys are stored in a database, and they are made accessible through a newly created endpoint: `/.backstage/auth/v1/jwks.json`.
|
|
20
|
+
|
|
21
|
+
`AuthService` can now issue tokens with a reduced scope using the `getPluginRequestToken` method. This improvement enables plugins to identify the plugin originating the request.
|
|
22
|
+
|
|
23
|
+
- 54f2ac8: Added `initialization` option to `createServiceFactory` which defines the initialization strategy for the service. The default strategy mimics the current behavior where plugin scoped services are initialized lazily by default and root scoped services are initialized eagerly.
|
|
24
|
+
- 56f81b5: Improved error message thrown by `AuthService` when requesting a token for plugins that don't support the new authentication tokens.
|
|
25
|
+
- 25ea3d2: Minor internal restructuring
|
|
26
|
+
- d62bc51: Add support for limited user tokens by using user identity proof provided by the auth backend.
|
|
27
|
+
- c884b9a: Automatically creates a get and delete cookie endpoint when a `user-cookie` policy is added.
|
|
28
|
+
- Updated dependencies
|
|
29
|
+
- @backstage/backend-common@0.21.7
|
|
30
|
+
- @backstage/config-loader@1.8.0
|
|
31
|
+
- @backstage/plugin-permission-node@0.7.28
|
|
32
|
+
- @backstage/backend-plugin-api@0.6.17
|
|
33
|
+
- @backstage/backend-tasks@0.5.22
|
|
34
|
+
- @backstage/plugin-auth-node@0.4.12
|
|
35
|
+
- @backstage/cli-node@0.2.5
|
|
36
|
+
- @backstage/cli-common@0.1.13
|
|
37
|
+
- @backstage/config@1.2.0
|
|
38
|
+
- @backstage/errors@1.2.4
|
|
39
|
+
- @backstage/types@1.1.1
|
|
40
|
+
|
|
41
|
+
## 0.7.0-next.1
|
|
42
|
+
|
|
43
|
+
### Minor Changes
|
|
44
|
+
|
|
45
|
+
- 3256f14: **BREAKING**: Modules are no longer loaded unless the plugin that they extend is present.
|
|
46
|
+
|
|
47
|
+
### Patch Changes
|
|
48
|
+
|
|
49
|
+
- 10327fb: Deprecate the `getPath` option for the `httpRouterServiceFactory` and more generally the ability to configure plugin API paths to be anything else than `/api/:pluginId/`. Requests towards `/api/*` that do not match an installed plugin will also no longer be handled by the index router, typically instead returning a 404.
|
|
50
|
+
- 1a20b12: Make the auth service create and validate dedicated OBO tokens, containing the user identity proof.
|
|
51
|
+
- bce0879: Service-to-service authentication has been improved.
|
|
52
|
+
|
|
53
|
+
Each plugin now has the capability to generate its own signing keys for token issuance. The generated public keys are stored in a database, and they are made accessible through a newly created endpoint: `/.backstage/auth/v1/jwks.json`.
|
|
54
|
+
|
|
55
|
+
`AuthService` can now issue tokens with a reduced scope using the `getPluginRequestToken` method. This improvement enables plugins to identify the plugin originating the request.
|
|
56
|
+
|
|
57
|
+
- 54f2ac8: Added `initialization` option to `createServiceFactory` which defines the initialization strategy for the service. The default strategy mimics the current behavior where plugin scoped services are initialized lazily by default and root scoped services are initialized eagerly.
|
|
58
|
+
- d62bc51: Add support for limited user tokens by using user identity proof provided by the auth backend.
|
|
59
|
+
- c884b9a: Automatically creates a get and delete cookie endpoint when a `user-cookie` policy is added.
|
|
60
|
+
- Updated dependencies
|
|
61
|
+
- @backstage/backend-common@0.21.7-next.1
|
|
62
|
+
- @backstage/backend-plugin-api@0.6.17-next.1
|
|
63
|
+
- @backstage/plugin-auth-node@0.4.12-next.1
|
|
64
|
+
- @backstage/backend-tasks@0.5.22-next.1
|
|
65
|
+
- @backstage/plugin-permission-node@0.7.28-next.1
|
|
66
|
+
- @backstage/cli-common@0.1.13
|
|
67
|
+
- @backstage/cli-node@0.2.4
|
|
68
|
+
- @backstage/config@1.2.0
|
|
69
|
+
- @backstage/config-loader@1.8.0-next.0
|
|
70
|
+
- @backstage/errors@1.2.4
|
|
71
|
+
- @backstage/types@1.1.1
|
|
72
|
+
|
|
3
73
|
## 0.6.3-next.0
|
|
4
74
|
|
|
5
75
|
### Patch Changes
|
package/alpha/package.json
CHANGED
package/config.d.ts
CHANGED
|
@@ -32,6 +32,106 @@ export interface Config {
|
|
|
32
32
|
* unless you configure credentials for service calls.
|
|
33
33
|
*/
|
|
34
34
|
dangerouslyDisableDefaultAuthPolicy?: boolean;
|
|
35
|
+
|
|
36
|
+
/**
|
|
37
|
+
* Configures methods of external access, ie ways for callers outside of
|
|
38
|
+
* the Backstage ecosystem to get authorized for access to APIs that do
|
|
39
|
+
* not permit unauthorized access.
|
|
40
|
+
*/
|
|
41
|
+
externalAccess: Array<
|
|
42
|
+
| {
|
|
43
|
+
/**
|
|
44
|
+
* This is the legacy service-to-service access method, where a set
|
|
45
|
+
* of static keys were shared among plugins and used for symmetric
|
|
46
|
+
* signing and verification. These correspond to the old
|
|
47
|
+
* `backend.auth.keys` set and retain their behavior for backwards
|
|
48
|
+
* compatibility. Please migrate to other access methods when
|
|
49
|
+
* possible.
|
|
50
|
+
*
|
|
51
|
+
* Callers generate JWT tokens with the following payload:
|
|
52
|
+
*
|
|
53
|
+
* ```json
|
|
54
|
+
* {
|
|
55
|
+
* "sub": "backstage-plugin",
|
|
56
|
+
* "exp": <epoch seconds one hour in the future>
|
|
57
|
+
* }
|
|
58
|
+
* ```
|
|
59
|
+
*
|
|
60
|
+
* And sign them with HS256, using the base64 decoded secret. The
|
|
61
|
+
* tokens are then passed along with requests in the Authorization
|
|
62
|
+
* header:
|
|
63
|
+
*
|
|
64
|
+
* ```
|
|
65
|
+
* Authorization: Bearer eyJhbGciOiJIUzI...
|
|
66
|
+
* ```
|
|
67
|
+
*/
|
|
68
|
+
type: 'legacy';
|
|
69
|
+
options: {
|
|
70
|
+
/**
|
|
71
|
+
* Any set of base64 encoded random bytes to be used as both the
|
|
72
|
+
* signing and verification key. Should be sufficiently long so as
|
|
73
|
+
* not to be easy to guess by brute force.
|
|
74
|
+
*
|
|
75
|
+
* Can be generated eg using
|
|
76
|
+
*
|
|
77
|
+
* ```sh
|
|
78
|
+
* node -p 'require("crypto").randomBytes(24).toString("base64")'
|
|
79
|
+
* ```
|
|
80
|
+
*
|
|
81
|
+
* @visibility secret
|
|
82
|
+
*/
|
|
83
|
+
secret: string;
|
|
84
|
+
|
|
85
|
+
/**
|
|
86
|
+
* Sets the subject of the principal, when matching this token.
|
|
87
|
+
* Useful for debugging and tracking purposes.
|
|
88
|
+
*/
|
|
89
|
+
subject: string;
|
|
90
|
+
};
|
|
91
|
+
}
|
|
92
|
+
| {
|
|
93
|
+
/**
|
|
94
|
+
* This access method consists of random static tokens that can be
|
|
95
|
+
* handed out to callers.
|
|
96
|
+
*
|
|
97
|
+
* The tokens are then passed along verbatim with requests in the
|
|
98
|
+
* Authorization header:
|
|
99
|
+
*
|
|
100
|
+
* ```
|
|
101
|
+
* Authorization: Bearer eZv5o+fW3KnR3kVabMW4ZcDNLPl8nmMW
|
|
102
|
+
* ```
|
|
103
|
+
*/
|
|
104
|
+
type: 'static';
|
|
105
|
+
options: {
|
|
106
|
+
/**
|
|
107
|
+
* A raw token that can be any string, but for security reasons
|
|
108
|
+
* should be sufficiently long so as not to be easy to guess by
|
|
109
|
+
* brute force.
|
|
110
|
+
*
|
|
111
|
+
* Can be generated eg using
|
|
112
|
+
*
|
|
113
|
+
* ```sh
|
|
114
|
+
* node -p 'require("crypto").randomBytes(24).toString("base64")'
|
|
115
|
+
* ```
|
|
116
|
+
*
|
|
117
|
+
* Since the tokens can be any string, you are free to add
|
|
118
|
+
* additional identifying data to them if you like. For example,
|
|
119
|
+
* adding a `freben-local-dev-` prefix for debugging purposes to a
|
|
120
|
+
* token that you know will be handed out for use as a personal
|
|
121
|
+
* access token during development.
|
|
122
|
+
*
|
|
123
|
+
* @visibility secret
|
|
124
|
+
*/
|
|
125
|
+
token: string;
|
|
126
|
+
|
|
127
|
+
/**
|
|
128
|
+
* Sets the subject of the principal, when matching this token.
|
|
129
|
+
* Useful for debugging and tracking purposes.
|
|
130
|
+
*/
|
|
131
|
+
subject: string;
|
|
132
|
+
};
|
|
133
|
+
}
|
|
134
|
+
>;
|
|
35
135
|
};
|
|
36
136
|
};
|
|
37
137
|
|