Revisit authorization logic

Problem description

1. The authorization subsystem doesn’t give adequate information to the authorization handler, to disambiguate between scope creation and scope use. One is unable to grant to the administrator the ability to create scopes, and grant to a user the ability to create streams within a given scope (but not to create scopes). Similar situation for scope deletion.

2. Similar situation for streams with respect to scopes; e.g. the ability to write to a stream without the ability to create streams.

3. Some of the calls are marked as requiring READ_UPDATE whereas READ may be sufficient:

• getCurrentSegments
• getSegments
• getURI
• isStreamCutValid
• getDelegationToken (varies by situation?)

Problem location

• io.pravega.controller.server.rpc.grpc.v1.ControllerServiceImpl
• io.pravega.controller.server.rest.resources.StreamMetadataResourceImpl

Suggestions for an improvement Adjust the argument passed to the authorize call on the auth handler, such that a call to create or delete a sub-resource has the parent resource as the argument. For example:

action	logic
list scopes	authorize("/", READ)
create scope	authorize("/", READ_UPDATE)
delete scope	authorize("/", READ_UPDATE)
list streams	authorize(scopeName, READ)
create stream	authorize(scopeName, READ_UPDATE)
delete stream	authorize(scopeName, READ_UPDATE)
read stream	authorize(scopeName + "/" + streamName, READ)
write stream	authorize(scopeName + "/" + streamName, READ_UPDATE)

Be sure to update ControllerServiceImpl and StreamMetadataResourceImpl since the logic is duplicated.

[EronWright]

@ravisharda your table has ‘delete’ operations that are inconsistent with that in the description, and consequently doesn’t solve the original problem.

I don’t see a compelling reason to change the resource argument format, because the handler is not designed to provide a generic hierarchical auth model.

Regarding the question of access rules, we use a fancy policy engine (Keycloak) which is very flexible. We strive to avoid embedding policy into the auth handler. e.g. the concept of roles, sentinel values such as ‘Admin’, permission inheritance.

[ravisharda]

@EronWright and @sarlaccpit FYI, I’ve started working on this issue.