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

Enhancement Request: Implement Role-Based Access Control for Tenant Creation Endpoint #13

Closed
oleaasbo opened this issue Jan 17, 2024 · 4 comments · Fixed by #18
Closed

Comments

@oleaasbo
Copy link

Currently, the POST endpoint for creating a tenant doesn't have specific restrictions. This setup could potentially allow any user with API access to create new tenants.

Suggested Enhancement:
I propose implementing a role-based access control for the tenant creation endpoint. This would align with how Keycloak handles API management in general. In my current setup, I issue API tokens to my customers by creating a Keycloak client with a service account, using a predefined Keycloak client (named api-cli). This client is not allowed to interact with the Keycloak API unless I assign a service account role of realm-management - manage-clients.

Proposed Implementation:
For the tenancy API, I suggest a similar approach where a service account role (e.g., realm-management - manage-tenants) is required to manage tenant creation. This role would only be assigned to my predefined api-cli client. By doing so, it ensures that API tokens held by my customers cannot create tenants unless I explicitly add this role to their service account, which I intend not to do. In my application, creating a new tenant is a paid feature, and this change would add an extra layer of control and security.

Additional Consideration:
This suggestion needs some careful thought, especially in relation to the feature where users are forced to create a tenant if not a member of one. I have this feature disabled in my application, but the proposed enhancement should ideally be compatible with both scenarios.

Thank you for considering this enhancement. I believe it would be a valuable addition to the API.

@anarsultanov
Copy link
Owner

Hi @oleaasbo,

This is certainly a valid use case, but I'll need some time to consider how to implement this in a way that maintains backward compatibility.

Thank you for your suggestion!

Regards,
Anar

@anarsultanov
Copy link
Owner

@oleaasbo could you take a look at the PR and let me know if this addresses your needs and fits into your existing setup?

@oleaasbo
Copy link
Author

I am on holiday now. Will take a look 1. Feb!

@anarsultanov
Copy link
Owner

No problem. I've merged the PR, but feel free to comment if this solution doesn't work for you for some reason.

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 a pull request may close this issue.

2 participants