Skip to content
This repository has been archived by the owner on Jan 24, 2024. It is now read-only.

[FEATURE] Separate authorization from authentication #236

Closed
3 tasks done
BewareMyPower opened this issue Nov 14, 2020 · 0 comments
Closed
3 tasks done

[FEATURE] Separate authorization from authentication #236

BewareMyPower opened this issue Nov 14, 2020 · 0 comments
Assignees
Labels
triage/week-46 type/feature Indicates new functionality

Comments

@BewareMyPower
Copy link
Collaborator

BewareMyPower commented Nov 14, 2020

Is your feature request related to a problem? Please describe.
KoP checks permissions only during authentication. Some tests of SaslPlainTest relies on the behavior. But it means once a client passed the authentication, it would have all permissions no matter what the specific permissions real it have.

Describe the solution you'd like
Create an Authorizer in KafkaRequestHandler which is constructed from info of authentication. Then do the authorization before each request is processed.

Task list

@BewareMyPower BewareMyPower added the type/feature Indicates new functionality label Nov 14, 2020
@BewareMyPower BewareMyPower mentioned this issue Jun 18, 2021
9 tasks
@Demogorgon314 Demogorgon314 self-assigned this Aug 16, 2021
Demogorgon314 added a commit that referenced this issue Aug 17, 2021
Demogorgon314 added a commit that referenced this issue Aug 21, 2021
Add authorization to handleTopicMetadataRequest(#236 ).

Fix #415 and #571 

## Motivation
When client fetch metadata need check topic permission, so we need add authorization in handleTopicMetadataRequest, and do not perform role verification in authentication.

## Modifications
Add a common method in `KafkaRequestHandler#authorize` , this method use `authorizer` to authorization.
Modify the authentication behavior, and do not verify the role during authentication, verify the role in fetch metadata(#571  )
wangjialing218 pushed a commit to wangjialing218/kop that referenced this issue Aug 24, 2021
…ative#662)

Add authorization to handleTopicMetadataRequest(streamnative#236 ).

Fix streamnative#415 and streamnative#571 

## Motivation
When client fetch metadata need check topic permission, so we need add authorization in handleTopicMetadataRequest, and do not perform role verification in authentication.

## Modifications
Add a common method in `KafkaRequestHandler#authorize` , this method use `authorizer` to authorization.
Modify the authentication behavior, and do not verify the role during authentication, verify the role in fetch metadata(streamnative#571  )
BewareMyPower pushed a commit that referenced this issue Aug 25, 2021
Add authorization to handleTopicMetadataRequest(#236 ).

Fix #415 and #571 

## Motivation
When client fetch metadata need check topic permission, so we need add authorization in handleTopicMetadataRequest, and do not perform role verification in authentication.

## Modifications
Add a common method in `KafkaRequestHandler#authorize` , this method use `authorizer` to authorization.
Modify the authentication behavior, and do not verify the role during authentication, verify the role in fetch metadata(#571  )
BewareMyPower pushed a commit that referenced this issue Aug 26, 2021
## Motivation
#236 Add authorization to produce and consumer

## Modifications
* Add authorization to `handleProduceRequest`
* Add authorization to `handleOffsetFetchRequest`
* Add authorization to `handleListOffsetRequest`
* Add authorization to `MessageFetchContext#handleFetch`
* Add new test units for produce or consume permissions
* Add new test units for topic level permissions
BewareMyPower pushed a commit that referenced this issue Aug 26, 2021
## Motivation
#236 Add authorization to produce and consumer

## Modifications
* Add authorization to `handleProduceRequest`
* Add authorization to `handleOffsetFetchRequest`
* Add authorization to `handleListOffsetRequest`
* Add authorization to `MessageFetchContext#handleFetch`
* Add new test units for produce or consume permissions
* Add new test units for topic level permissions
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
triage/week-46 type/feature Indicates new functionality
Projects
None yet
Development

No branches or pull requests

2 participants