-
Notifications
You must be signed in to change notification settings - Fork 0
Restriction Mode
Restricted sub-queues is a new featured added in version 0.3.0.
The application Restriction Mode is a way to indicate how the MessageQueue can be interacted with. This property can drive whether credentials need to be created and shared for all sub-queues, some of the sub-queues or none of the sub-queues.
When the Restriction Mode is set to NONE there is no way to restrict access to any of the sub-queues. The entire MessageQueue and all messages stored within it are completely accessible by any caller who can reach the application.
When the Restriction Mode is set to another option, either HYBRID or RESTRICTED the application will start with none of the sub-queues marked as restricted. API requests need to be made to the auth endpoint to register specific sub-queues as restricted or not. NOTE: For RESTRICTED mode this is required. HYBRID mode allows you to run both restricted and un-restricted sub-queues simultaneously.
The intention is for the application to start, for each pre-determine set of sub-queues you will need to request the MessageQueue to restrict them. Doing so will return you a JWT token for each individual request. This returned token will need to be shared with the appropriate applications for them to access their appropriate sub-queues.
The restriction mode of the MessageQueue can be controlled by setting the following environment property: message-queue.restriction-mode, the default is NONE.
The other options are HYBRID and RESTRICTED which aim to lockdown interactions with specific or all sub-queues to callers who hold the corresponding credential for the requested sub-queue.
This is the default setting, in the NONE mode the MessageQueue is completely available, no area is restricted and messages can be freely added, removed, assigned and released as needed by any caller with access to the application endpoints.
Using the HYBRID mode, is a blend between both NONE and RESTRICTED modes. By default all sub-queues are readily accessible like in NONE mode. But you can optionally select specific sub-queues that you want to restrict. Doing so will return you an Access Token which must be used on subsequent calls for only that specific sub-queue.
Using the RESTRICTED mode, no sub-queue is accessible at all without a token. Meaning that any sub-queue you want to utilise will need to marked as restricted and a Access Token needs to be generated and used by any calling wanting to access that specific sub-queue.
However there are some endpoints that are always accessible to allow you to see what sub-queues exist and what identifiers own messages in which sub-queues.
Once a sub-queue is restricted and you have its token you need to provide this token in subsequent calls to access that sub-queue (this even includes direct UUID message look ups).
The token needs to be provided in the Authorization header with the value Bearer <token>.
Restricted Sub-Queues are persisted in the storage mechanism. Meaning tokens will last forever and cannot be cycled without several steps. Cycling the tokens requires setting a different Access Token credential, this will invalidate ALL existing Access Tokens and you will be unable remove this restriction. The sub-queue will become completely locked for any restrictions that are not removed in step one below. To cycle the Access Tokens you can use the following steps:
- Remove restriction for ALL sub-queues
- Stop the MessageQueue
- Update the
message-queue.access-token.keyproperty if it is set, otherwise a random key will be generated on start up and the application just needs to be restarted - Re-create the restrictions that you removed in step 1 for all required sub-queues
When HYBRID or RESTRICTED are used, you can set: message-queue.access-token.key which will be used in the HMAC512 JWT token signing and verification algorithm. If this is not provided a randomly generated key will be generated and used. There is no way to extract the key being used from the application.
NOTE: If you want Access Tokens to remain effective when the application restarts you need to make sure this is set to a consistent value, otherwise the randomly generated credential will be unable to verify tokens generated by the different key credential.
When HYBRID or RESTRICTED are used, when you want to restrict a sub-queue you can call the following endpoint POST - https://<host-name>/auth/<sub-queue-identifier/queue-type> (Please refer to the application swagger docs).
In the response payload a token will be returned, this should be used and shared when interacting with this sub-queue from now on.
When HYBRID or RESTRICTED are used, if you no longer wish for a sub-queue to be treated as restricted you can remove the restriction using the following endpoint DELETE - https://<host-name>/auth/<sub-queue-identifier/queue-type> (Please refer to the application swagger docs).
When HYBRID or RESTRICTED are used, you can perform a GET request to end endpoint https://<host-name>/auth, (Please refer to the application swagger docs). This endpoint does not require authentication to access and returns a List<String> of the restricted sub-queues. These sub-queues require authentication to access and manipulate that sub-queue's messages.