Part of a series of work to implement AAA in Deephaven Core.
Authorization is a mechanism to describe access to a system to users, typically a set of rules that define whether a given operation is allowed or rejected. Sometimes abbreviated as authz (as opposed to authn for authentication), authorization does not require authentication as a prerequisite, as anonymous users could still be granted access to certain operations. Typically however most authz rules will be based on the identity of the user, as handled by the authn mechanism.
Identifying operations and granting access can be handled in several ways - popular ones would include defining roles to assign to users (or to groups, and in turn let users be assigned to groups). The most generic approach would likely be to offer fine-grained API hooks to allow/deny each operation based on coarse grained roles, and to have a simple implementation that only checks if a user is granted that role. As the vast majority of our API surface area is in gRPC calls, it seems simplest to generate those api hooks directly, using the proto objects that describe the underlying services, taking care not just to intercept the original request, but later streamed requests too.
Rate limiting is another form of access control in this way, allowing even non-authenticated users to be limited in what actions they can perform based on what they have done so far. Limiting this by session is probably not sufficient, but by IP address might be necessary too. An http2 proxy can probably help with some of this, but might not be sufficient for bidi grpc streams.
Part of a series of work to implement AAA in Deephaven Core.
Authorization is a mechanism to describe access to a system to users, typically a set of rules that define whether a given operation is allowed or rejected. Sometimes abbreviated as authz (as opposed to authn for authentication), authorization does not require authentication as a prerequisite, as anonymous users could still be granted access to certain operations. Typically however most authz rules will be based on the identity of the user, as handled by the authn mechanism.
Identifying operations and granting access can be handled in several ways - popular ones would include defining roles to assign to users (or to groups, and in turn let users be assigned to groups). The most generic approach would likely be to offer fine-grained API hooks to allow/deny each operation based on coarse grained roles, and to have a simple implementation that only checks if a user is granted that role. As the vast majority of our API surface area is in gRPC calls, it seems simplest to generate those api hooks directly, using the proto objects that describe the underlying services, taking care not just to intercept the original request, but later streamed requests too.
Rate limiting is another form of access control in this way, allowing even non-authenticated users to be limited in what actions they can perform based on what they have done so far. Limiting this by session is probably not sufficient, but by IP address might be necessary too. An http2 proxy can probably help with some of this, but might not be sufficient for bidi grpc streams.