crossid / accessbot

Streamline resource access grants with AI-Powered chatbot
https://www.crossid.io
Other
2 stars 0 forks source link

Secure endpoints #53

Closed asaf closed 5 months ago

asaf commented 8 months ago

Auth Methods

GET /api/workspaces/{workspace_id}/auth-methods

Scope Required: read:auth-methods

POST /api/workspaces/{workspace_id}/auth-methods

Scope Required: update:auth-methods

DELETE /api/workspaces/{workspace_id}/auth-methods/{auth_method_id}

Scope Required: delete:auth-methods

Workspaces

GET /api/workspaces/public

Scope Required: none, anonymous

POST /api/workspaces

Scope Required: update:workspaces

Note: Not sure about this as any authenticated user can create a workspace.

GET /api/workspaces/{workspace_id}

Scope Required: read:workspaces

DELETE /api/workspaces/{workspace_id}

Scope Required: delete:workspaces

PATCH /api/workspaces/{workspace_id}

Scope Required: update:workspaces

Conversations

POST /api/conversations

Scope Required: update:conversations

GET /api/conversations

Scope Required: read:conversations

Note: admin can read any, non admin - need to add a criteria where current_user eq assignee

GET /api/conversations/{conversation_id}

Scope Required: read:conversations

Note: same as list

POST /api/conversations/{conversation_id}/stream

Scope Required: update:conversations

POST /api/conversations/{conversation_id}/.cancel

Scope Required: update:conversations

Note: admin can cancel any, otherwise current_user eq assignee

Content

PUT /api/content

Scope Required: update:content

POST /api/content

Scope Required: update:content

GET /api/content

Scope Required: read:content

POST /api/content/.delete

Scope Required: delete:content

GET /api/content/{id}

Scope Required: read:content

Domains

POST /api/domains/

Scope Required: update:domains

POST /api/domains/{id}/.verify

Scope Required: update:domains

POST /api/domains/managed-certificates

Scope Required: update:domains

PUT /api/domains/certificates

Scope Required: update:domains

POST /api/domains/{id}/.activate

Scope Required: update:domains

DELETE /api/domains/{id}

Scope Required: delete:domains

Directories

POST /api/directories

Scope Required: update:directories

GET /api/directories

Scope Required: read:directories

GET /api/directories/{directory_id}

Scope Required: read:directories

DELETE /api/directories/{directory_id}

Scope Required: delete:directories

PATCH /api/directories/{directory_id}

Scope Required: update:directories

Applications

POST /api/applications

Scope Required: update:applications

GET /api/applications

Scope Required: read:applications

GET /api/applications/{application_id}

Scope Required: read:applications

DELETE /api/applications/{application_id}

Scope Required: delete:applications

PATCH /api/applications/{application_id}

Scope Required: update:applications

Secrets

PUT /api/secrets/{path}

Scope Required: update:secrets

DELETE /api/secrets/{path}

Scope Required: delete:secrets

GET /api/secrets

Scope Required: read:secrets

asaf commented 6 months ago

@ErezSha anything left about this ticket?

ErezSha commented 6 months ago

@asaf What do you want for authz? scopes?

asaf commented 5 months ago

This is far away from being completed, we need minimal security facilities.

asaf commented 5 months ago

@ErezSha please implement, per your preference - come up with any solution (inline checking, decorators, fastapi dependencies, etc.

Please note that few of the endpoints requires a bit more work than just checking the scope as it depends if the user is an admin or not.

I suggest to come up with some method such 'is_admin' which we can for now resolve by the creator of the workspace and later on provide a more robust implementation based on user roles/scopes/etc.

ErezSha commented 5 months ago

Reminder: Auth0 is a bit weird with scopes, because scopes is per audience, so we'll probably have to create a different audience per workspace.

asaf commented 5 months ago

Can't we create a single API for the bot?

Then the access granting should be on the org level, e.g a user in org "acme" should have read: workspaces.

Granting on the user level does not make any sense. On Sun, Jun 16, 2024, 4:54 PM Erez Sharim @.***> wrote:

Reminder: Auth0 is a bit weird with scopes, because scopes is per audience, so we'll probably have to create a different audience per workspace.

— Reply to this email directly, view it on GitHub https://github.com/crossid/accessbot/issues/53#issuecomment-2171672717, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAADPM3PQY42DSFROTJHSUTZHWKIJAVCNFSM6AAAAABELUPBHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZRGY3TENZRG4 . You are receiving this because you modified the open/close state.Message ID: @.***>

ErezSha commented 5 months ago

From what I understand, in Auth0, scopes are on the api level, not org level.

asaf commented 5 months ago

Not the definition of the scopes, the relationship to the users

On Sun, Jun 16, 2024, 5:10 PM Erez Sharim @.***> wrote:

From what I understand, in Auth0, scopes are on the api level, not org level.

— Reply to this email directly, view it on GitHub https://github.com/crossid/accessbot/issues/53#issuecomment-2171679737, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAADPM3TDBQCFVWR5HFG2BLZHWME5AVCNFSM6AAAAABELUPBHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZRGY3TSNZTG4 . You are receiving this because you modified the open/close state.Message ID: @.***>