feat(runtime): enhance the access protection security model #452

basmasking · 2024-01-26T14:03:50Z

Fixes #448

Changes proposed in this pull request:

added option to created trusted clients
added protected access for procedures
updated documentation
updated example to reflect the change

@MaskingTechnology/jitar

petermasking · 2024-01-26T19:52:10Z

documentation/docs/deploy/segmentation.md

+
+When building a distributed application, you don't want all functions to be available by the outside world. Some functions are only used internally by other segments. To protect the access to these functions, Jitar provides a `secret` property in the [runtime services](../fundamentals/runtime-services#node). This secret is used to create trusted clients. Trusted clients can access functions with the `protected` access level.
+
+Any client that wants to access a protected function must provide a valid access key. The access key needs to be added to the http header `x-access-key`. Any node that has a valid access key is considered a trusted client, and automatically adds the access key to the http header of outgoing requests. Any node that doesn't have a valid access key is considered an untrusted client and can only access `public` functions.


The header X-Access-Key is, in a security context, generic enough to conflict with other systems (I know systems that use this header too). My suggestion would be to make it more jitar specific, like: X-Jitar-Protected-Access-Key.

Good suggestion, I changed the header key.

petermasking · 2024-01-26T19:58:59Z

documentation/docs/fundamentals/runtime-services.md

@@ -115,6 +115,7 @@ The following configuration properties are available:
 * repository - url of the repository (required).
 * segments - list of segment names to load (optional, loads all segments by default).
 * middlewares - list of [middleware modules](../develop/middleware.md) to load (optional).
+* secret - shared secret for creating trusted clients (optional).


How do the terms secret and access key relate to each other? Can we use a singe term for both to make things more clear?

The string I've used is trustKey, because the key builds trust between the nodes and the gateway, allowing them to access protected procedures.

petermasking · 2024-01-26T20:02:49Z

examples/concepts/access-protection/segments/game.segment.json

Is it more clear to rename this segment to protected.segment.json?

There is also a private procedure in there, and it's still related to the game folder in the source. This keeps everything aligned, just as it is in the other examples.

petermasking · 2024-01-26T20:03:02Z

examples/concepts/access-protection/segments/web.segment.json

Is it more clear to rename this segment to public.segment.json

petermasking · 2024-01-26T20:09:05Z

packages/runtime/src/models/Procedure.ts

@@ -25,6 +25,22 @@ export default class Procedure
        return implementations.some(implementation => implementation.public);
    }

+    get protected()
+    {


Should we mention this in the docs?

petermasking · 2024-01-26T20:16:52Z

packages/runtime/src/services/LocalNode.ts


        return this.#gateway.run(request);
    }

    async #runProcedure(procedure: Procedure, request: Request): Promise<Response>
    {
+        const secret = request.headers.get('x-access-key');


Suggested change

const secret = request.headers.get('x-access-key');

const secret = request.getHeader('x-access-key');

petermasking · 2024-01-26T20:22:19Z

packages/runtime/test/services/LocalGateway.spec.ts

I'm missing a test for a failing registration of a node, and protected related test in the local node spec.

petermasking

Besides the other review comments I'm still missing the tests for the local node. At least for running a protected procedure with a key, with an invalid key and a valid key.

petermasking · 2024-01-26T22:52:26Z

documentation/docs/deploy/segmentation.md

+
+When building a distributed application, you don't want all functions to be available by the outside world. Some functions are only used internally by other segments. To protect the access to these functions, Jitar provides a `trustKey` property in the [runtime services](../fundamentals/runtime-services#node). This key is used to create trusted clients. Trusted clients can access functions with the `protected` access level.
+
+Any client that wants to access a protected function must provide a valid key. It needs to be added to the http header `X-Jitar-Protected-Access-Key`. Any node that has a valid key is automatically considered a trusted client, and adds the access key to the http header of outgoing requests. Any node that doesn't have a valid access key is considered an untrusted client and can only access `public` functions.


As discussed, we'll use X-Jitar-Trust-Key to make it consistent with the used property.

The key has been changed in the code, but not in the docs yet.

petermasking · 2024-01-26T22:59:52Z

packages/runtime/src/services/Node.ts

@@ -3,5 +3,5 @@ import ProcedureRuntime from './ProcedureRuntime.js';

 export default abstract class Node extends ProcedureRuntime
 {
-    
+   get trustKey(): string | undefined { return undefined; }


Can we make this property abstract, so the remote node also gets an explicit implementation?

petermasking · 2024-01-27T19:21:04Z

examples/concepts/access-protection/requests.http

+
+// Run the protected function with key (succeeds)
+GET http://localhost:3000/rpc/game/checkSecret?secret=123 HTTP/1.1
+X-Jitar-Protected-Access-Key: VERY_SECRET_KEY


Suggested change

X-Jitar-Protected-Access-Key: VERY_SECRET_KEY

X-Jitar-Trust-Key: VERY_SECRET_KEY

petermasking · 2024-01-27T19:22:19Z

documentation/docs/deploy/segmentation.md

+
+When building a distributed application, you don't want all functions to be available by the outside world. Some functions are only used internally by other segments. To protect the access to these functions, Jitar provides a `trustKey` property in the [runtime services](../fundamentals/runtime-services#node). This key is used to create trusted clients. Trusted clients can access functions with the `protected` access level.
+
+Any client that wants to access a protected function must provide a valid key. It needs to be added to the http header `X-Jitar-Protected-Access-Key`. Any node that has a valid key is automatically considered a trusted client, and adds the access key to the http header of outgoing requests. Any node that doesn't have a valid access key is considered an untrusted client and can only access `public` functions.


The key has been changed in the code, but not in the docs yet.

basmasking added 7 commits January 25, 2024 08:28

#448: addNode is async so await to get exception

8e82b16

#448: added secret to Node service

21ff70c

#448: added secret to standalone

832c898

#448: added protected access level

3e301d5

#448: added secret for node registration

e5ddd70

#448: updated access-protection example

5f02b88

#448: updated documentation

baea0a1

basmasking linked an issue Jan 26, 2024 that may be closed by this pull request

Enhance the access protection security model #448

Closed

basmasking added 3 commits January 26, 2024 15:15

#448: implemented tests

e21e66f

#448: removed comment

9ab13f7

#448: tidy up

a4f7bec

basmasking requested a review from petermasking January 26, 2024 14:21

basmasking marked this pull request as ready for review January 26, 2024 14:21

petermasking requested changes Jan 26, 2024

View reviewed changes

basmasking added 2 commits January 26, 2024 22:58

#448: processed feedback

66f8053

#448: fixed error import

67e2bd0

petermasking requested changes Jan 26, 2024

View reviewed changes

#448: processed second round of feedback

e26a8b8

petermasking requested changes Jan 27, 2024

View reviewed changes

#448: trust key change

1f612b2

petermasking approved these changes Jan 27, 2024

View reviewed changes

petermasking merged commit eb35499 into main Jan 27, 2024
7 checks passed

petermasking deleted the 448-enhance-the-access-protection-security-model branch January 27, 2024 19:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(runtime): enhance the access protection security model #452

feat(runtime): enhance the access protection security model #452

basmasking commented Jan 26, 2024

petermasking Jan 26, 2024

basmasking Jan 26, 2024

petermasking Jan 26, 2024

basmasking Jan 26, 2024 •

edited

Loading

petermasking Jan 26, 2024

basmasking Jan 26, 2024

petermasking Jan 26, 2024

petermasking Jan 26, 2024

petermasking Jan 26, 2024

petermasking Jan 26, 2024

petermasking left a comment

petermasking Jan 26, 2024

petermasking Jan 27, 2024

petermasking Jan 26, 2024

petermasking Jan 27, 2024

petermasking Jan 27, 2024


		When building a distributed application, you don't want all functions to be available by the outside world. Some functions are only used internally by other segments. To protect the access to these functions, Jitar provides a `secret` property in the [runtime services](../fundamentals/runtime-services#node). This secret is used to create trusted clients. Trusted clients can access functions with the `protected` access level.

		Any client that wants to access a protected function must provide a valid access key. The access key needs to be added to the http header `x-access-key`. Any node that has a valid access key is considered a trusted client, and automatically adds the access key to the http header of outgoing requests. Any node that doesn't have a valid access key is considered an untrusted client and can only access `public` functions.

	const secret = request.headers.get('x-access-key');
	const secret = request.getHeader('x-access-key');

	X-Jitar-Protected-Access-Key: VERY_SECRET_KEY
	X-Jitar-Trust-Key: VERY_SECRET_KEY

feat(runtime): enhance the access protection security model #452

feat(runtime): enhance the access protection security model #452

Conversation

basmasking commented Jan 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

basmasking Jan 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petermasking left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

basmasking Jan 26, 2024 •

edited

Loading