[Design] Websocket: Wallet authorization for real-time

[r4mmer]

Real-Time Authorization

When subscribing to the events of a wallet, the client should verify that he owns the wallet.
This can be done by passing a token created with the /auth/token API when subscribing to the wallet.

Discussion

Should we use the authorization method when connecting ($connect route) instead of when subscribing to the wallet?

• By enforcing that only wallet owners can connect to the API Gateway Websocket, we can mitigate DOS attacks. Too many connections on the API Gateway will consume our resources, also each connection will create at least one key in our Redis instance, creating too many may overload the instance and DOS the actual users.
• If we expand the use of websockets to use cases where a wallet subscription is not needed, another authentication method will have to be developed (this is not a drawback, only an observation).
  • In this case, if no alternative authentication method is developed, we would be open to a DOS attack described above.
• This way we can enforce a limit of open connections for a given wallet.
• This may impede having one connection for multiple wallets (if such feature is desired).

[r4mmer]

@pedroferreira1 @msbrogli @andreabadesso @luislhl
The implementation should be simple, I just need feedback on the points under Discussion.
We can also expand the desired features this will bring (such as a limit to websocket connections per wallet, etc.)

[pedroferreira1]

Should we use the authorization method when connecting ($connect route) instead of when subscribing to the wallet?

I like this because of the DoS prevention.

If we expand the use of websockets to use cases where a wallet subscription is not needed

What do you mean here? What event subscription does not need a wallet id?

This way we can enforce a limit of open connections for a given wallet.

I think this is important, otherwise the same DoS attack can be done using a wallet subscription.

This may impede having one connection for multiple wallets (if such feature is desired).

I didn't understand why we can't have one connection for multiples wallets with this approach.

[andreabadesso]

I also agree with rejecting the connection as soon as possible if it is not authenticated, but maybe we can use something like scopes on the token to authenticate the user and everything he wants to access (subscribing for multiple wallets for instance)

[r4mmer]

What do you mean here? What event subscription does not need a wallet id?

@andreabadesso mentioned an idea of a service listening for new txs on the wallet-service websocket instead of the full-node.

I didn't understand why we can't have one connection for multiples wallets with this approach.

We can, but we would need to $connect with one wallet, then use a join action for the other wallets, duplicating the authentication process on the join. We could pass a list of wallet ids to $connect (as an alternative).

[luislhl]

By enforcing that only wallet owners can connect to the API Gateway Websocket, we can mitigate DOS attacks. Too many connections on the API Gateway will consume our resources, also each connection will create at least one key in our Redis instance, creating too many may overload the instance and DOS the actual users.

I think we should also use API Gateway rate-limiting feature to protect against DDoS. It should be capable of preventing the opening of too many connections in a short time span.

@andreabadesso mentioned an idea of a service listening for new txs on the wallet-service websocket instead of the full-node.

If this new service is ours, maybe we should have two websocket connection APIs, one public and one private, where the public one has rate-limits and authentication, and the private one don't have authentication (it could have rate-limit or not).

Does that make sense?

[r4mmer]

Summary

Authorize any user that wishes to connect to the Wallet Service WebSocket API. The information on the Websocket API is not sensitive, but it demands resources to maintain and communicate to each connection, this way we can limit the connections per wallet and ensure that the connections are from the wallet owner.

Motivation

Security

The WebSocket API will not send or receive sensitive information, but we can ensure noone can listen on updates of anothers wallet without permission (and using our resources).

Limits

We can create limits of connections for each wallet and make sure the connections are legitimate (from the owner).

We can configure API Gateway rate limits to minimize DOS attacks, but we can also implement wallet limits on open connections, so that no user can consume out resources by creating many valid concurrent connections.

Session

In the future, we may use tokens to control user sessions (multiple devices logins, allow or deny access to certain resources, etc.).
The WebSocket API authorization is a beginning to session management when implemented.

Guide-level explanation

The authorization process is the same as the API authorization, a lambda authorizer will ensure that the request is legitimate, will verify ownership and extract the wallet id from the request token and pass the wallet id to the $connect route if the token is valid.

There's a few exceptions to be made for WebSocket Authorizers on AWS and for WebSocket authorization in general.

• Can only be implemented on the $connect route since it's the only http request made before upgrading the protocol
  • This means we cannot have this authorizer implemented on the $join route, we'd have to implement the authorization on the handler itself
• The JS websocket api for browsers does not support custom header authorization
  • Our Desktop-wallet runs on electron, so we cannot use headers for authorization.
  • We are implementing with querystring parameters so that any client can connect.
  • querystring size has no limits by the RFC 2616 (HTTP 1.1) or the RFC 3986 (URI) but most servers implement a 1K/2K hard limits to prevent attacks, so we cannot let our token grow that large.
• Serverless Offline does not support WebSocket Authorizers yet, so I created a workaround for offline testing until serverless fix this issue.
• We only authorize the first call with a token to the wallet being subscribed, if there's an action to subscribe to another wallet on the same connection, it should pass through the authorization process again.

When subscribing to the events of a wallet, the client should verify that he owns the wallet.
This can be done by passing a token created with the /auth/token API when subscribing to the wallet.

Reference-level explanation

Authorizer

• The identitySource syntax for a WebSocket API authorizer is not the same as a HTTP authorizer, this means we cannot reuse the serverless.yml definition of the authorizer.
• The http api and WebSocket API run in different instances of API Gateway, this means the method ARN of the policy generated by the authorizer in one instance will never affect the other.
• WebSocket authorizer forces the REQUEST type (I did not find the documentation for this but our configuration of TOKEN was ignored and the event type sent to the lambda was a type REQUEST one).

Since the definition, API Gateway instance, event type and effect are different, the best approach would be to not reuse the same lambda function for both authorizers.

We created another lambda to handle websocket authorization requests (generating the desired policy) but using the same core function to validate the token.

Unlike the HTTP API, the WebSocket only has 1 interaction where we can use the authorizer, the $connect route, where the user authenticates and starts the websocket connection, since the connect route is also the caller, we just need to allow the user acess to the caller method arn, any authorization other than this will have to be implemented on the websocket lambdas.

Limit

Every time a connection tries to connect to a wallet, we will count the number of open connections on that wallet and if this connection goes above the limit we disconnect the user.

Connection Keys

• 1 for each connection (<prefix>:conn:<connId>)
  • Since we are making a connection have an obligatory wallet subscription, this could be removed
• 1 for each connection-wallet subscription (<prefix>:chan:wallet-<walletId>:<connId>)
  • This allows for a connection to subscribe to multiple wallets
  • The limit is implemented on the number of keys this search returns: <prefix>:chan:wallet-<walletId>:*

Future Improvements

We could create one key to track all connections of a wallet instead of one key per connection, this would save time when searching for all connections of a given wallet or any particular connection and it would simplify implementing session management.

[luislhl]

The same authorizer function as the API can be used, since the TOKEN type of authorizer extracts the token from the identitySource and passes it to the authorizer.
Unfortunately we need separate instances of the authorizer definition on the serverless.yml since the identitySource syntax is different for WebSockets.

I think this part has to be updated, right? We learned that Serverless creates two independent API Gateway instances for the Http and WebSocket apis.

In the future, we may use tokens to control user sessions (multiple devices logins, allow or deny access to certain resources, etc.).
The WebSocket API authorization is a beginning to session management when implemented.

I think we should evaluate the use of Cognito to help us with session management and authorization. Should we create an issue for this already and put the ideas there?

[r4mmer]

I think this part has to be updated, right? We learned that Serverless creates two independent API Gateway instances for the Http and WebSocket apis.

Corrected.

I think we should evaluate the use of Cognito to help us with session management and authorization. Should we create an issue for this already and put the ideas there?

I think we should create this issue to start a discussion.

[luislhl]

I think we should create this issue to start a discussion.

Can you create it? @r4mmer