Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial proposal for /allow endpoint #65

Merged
merged 2 commits into from
Apr 11, 2023
Merged

Conversation

JAORMX
Copy link
Contributor

@JAORMX JAORMX commented Apr 11, 2023

This creates an /allow endpoint which does the actual permission
check.

It takes three mandatory query parameters:

  • tenant: The tenant URN
  • resource: The resource URN
  • action: The action identifier tag

It also adds a simple OpenAPI v3 spec document.

The intent is to have an easy, general and fairly opinionated endpoint
to do permission checks on. This can be taken programmatically without
much logic in... say... an API Gateway, to do the needed checks without
adding much logic other than gathering the mandatory parameters.

Signed-off-by: Juan Antonio Osorio [email protected]

This creates an `/allow` endpoint which does the actual permission
check.

It takes three mandatory query parameters:

* `tenant`: The tenant URN
* `resource`: The resource URN
* `action`: The action identifier tag

It also adds a simple OpenAPI v3 spec document.

The intent is to have an easy, general and fairly opinionated endpoint
to do permission checks on. This can be taken programmatically without
much logic in... say... an API Gateway, to do the needed checks without
adding much logic other than gathering the mandatory parameters.

Signed-off-by: Juan Antonio Osorio <[email protected]>
Copy link
Contributor

@fishnix fishnix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, I don't have a strong opinion about the previous has/on endpoint vs query parameters. I'm curious if we've thought about other ways to provide the tenant, for example in the jwt. Is this particularly untenable in the api-gateway? In this model, how do we account for permission on tenants without resources? do we duplicate the tenant in the resource query field? I could imagine pros/cons for that field being optional.

@JAORMX
Copy link
Contributor Author

JAORMX commented Apr 11, 2023

@fishnix thansk for the feedback, I think we can address that by making the resource ID optional.

Signed-off-by: Juan Antonio Osorio <[email protected]>
@JAORMX JAORMX requested a review from fishnix April 11, 2023 13:55
@JAORMX JAORMX merged commit e016623 into infratographer:main Apr 11, 2023
@JAORMX JAORMX deleted the check-api branch April 11, 2023 14:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants