Implement RBAC for Cello

[YoungHypo]

Background & Problem

Cello has roles, but does not use them for authorization.

• src/api-engine/user/models.py already defines Role.ADMIN / Role.USER and the is_admin / is_common_user properties — but they are never used anywhere in the codebase.
• Every business ViewSet sets permission_classes to just [IsAuthenticated], with no role-based checks at all.

As a result, any logged-in user can perform operations that should be admin-only. Confirmed privilege-escalation examples:

• Any authenticated user can delete any organization — destroy in organization/views.py calls Organization.objects.get(id=pk).delete() directly, checking neither role nor ownership.
• The organization list / detail endpoints have no tenant isolation (Organization.objects.all(), lookup by arbitrary pk).

Goal

Make role actually participate in authorization. Core principle: Organization = resource boundary, Role = operation permissions — keep the two checks separate.

• High-risk operations (create/delete users, delete organization, create/delete nodes, install/approve/commit chaincode, etc.) should be restricted to ADMIN; USER should default to read-only or limited access.
• Start with the existing two roles ADMIN / USER, then extend as needed with OPERATOR (ops: manage nodes/channels/chaincode) and VIEWER (read-only).

[SOHAMPAL23]

@YoungHypo Can I work on this issue

[yeasy]

@SOHAMPAL23 feel free to assign it to yourself

[adarshjnv9100]

Hi! I'd like to work on this issue as part of LFX Mentorship.

From my understanding, the Role model (ADMIN / USER) already exists, but it is currently not enforced anywhere in the API. Since most ViewSets only use IsAuthenticated, any authenticated user can perform privileged operations such as deleting organizations or managing blockchain resources.

I think the separation proposed in the issue is important:

• Organization should define the resource boundary (which resources a user can access).
• Role should define what operations are permitted on those resources.

My plan is to:

1. Audit the existing ViewSets to identify all privileged endpoints.
2. Introduce reusable role-based permission classes instead of scattering role checks throughout the views.
3. Keep organization membership/ownership checks independent from role checks so the authorization logic remains modular.
4. Restrict destructive and management operations (organization deletion, user management, node lifecycle, chaincode lifecycle, etc.) to ADMIN, while allowing USER only the intended read or limited operations.
5. Add tests covering both authorized and unauthorized access to prevent privilege-escalation regressions.

I also noticed the examples mentioned in the issue, such as unrestricted organization deletion and lack of tenant isolation, so I'll review those paths first before implementing the permission layer.

If there are any existing design discussions or preferred patterns for authorization in Cello, I'd be happy to align with them before starting the implementation.

[SOHAMPAL23]

Looks good but I am still working on it .You can still put a Pr for review