Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tsgFw-004X7F-J1 for pgadmin-hackers@arkaria.postgresql.org; Thu, 13 Mar 2025 10:57:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tsgFv-00AcDZ-78 for pgadmin-hackers@arkaria.postgresql.org; Thu, 13 Mar 2025 10:57:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tsgFu-00AcDQ-Ux for pgadmin-hackers@lists.postgresql.org; Thu, 13 Mar 2025 10:57:39 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tsgFr-002dTI-08 for pgadmin-hackers@postgresql.org; Thu, 13 Mar 2025 10:57:38 +0000 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-549a4a4400aso922367e87.0 for ; Thu, 13 Mar 2025 03:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1741863455; x=1742468255; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RttZPkzCyJ3MAQl97n7LgiPNplt+FPAgFEGIW0p++DE=; b=kGuEZjJsWI1aloCafcQSRfvHm7nQGj27mi1iM6ThpHmsiNzEICSI7Pd3cgNer9lgs4 mHTCB63i/4VQEpihLmWPUjxD8MezhTjsj1XlQR0jP6SGTnNm919CHsYfkmRDu3ur+B1O ocQ+D+3EZh6Pq/QPA2DDvMcY7+eBEwJdeFT0Y8W9zR9JIBQv3EnrhFQhq77lNKQZ9tmf VwvwYeB2jusmrxTJMggQh+q1qcyaZtVKynfrGoR49kQRuUjMJ2TB47SwVI1CQZCNQMYK kWDh4x4Yg81vsrK3Lk5SByGgSddVIIIKhgDnpHvSx7bTzCqtgkLQVsdwgcZp2hjxEOUc cTYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741863455; x=1742468255; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RttZPkzCyJ3MAQl97n7LgiPNplt+FPAgFEGIW0p++DE=; b=hWFyuk4idL0SUl7/Lw5ppNhkopMCMed+EZ8sMxSiIKlDCbR02FjnjRRKXeG+7mNp5H 1VXTEqLEJft8hQtgooBtoNM9JuyZsgx4WrB6tR+t3zE6uNCQQNG2ICFRGKEfw7sv8OZY 53aHuGrzYEW1pGqq9PzdEH7t604dam0cq6yH1fo1mCyLQHpejs6SNg+2B3lqRkthmQRO UaaNglfaOgvbSv9OZAcU90NXZME2Wk4nsB/mbUvYkuQV2TYQcbvs20kxaoUNTG1SLLLn cyBWudD8Sr+eLWYQB3JhkW+frvDVVNGzhG5ZAK4gv0ugj6vrPCQuLtARip34dZW4c+v1 9SHA== X-Gm-Message-State: AOJu0YxPnt2bGSskGciwEVuM3bihz3Omqv6R+weGoz6yBh6wOtvdOiHg poKuOKpFBCBDHg4HH2v6yWPl1kpHOnzr89r5V3vSagC2O3770pNOpK5sPltZteXG0gDPZ+fA9TF SxaOGyn2wVU2N9MK6hUxAH68PAVqdY+KXznk19w51IDBAXQT+hw== X-Gm-Gg: ASbGncuvDeiscxqfILb96MJZLpQnM9d/C3gKyC6EjF2hLkxX7trdcW5z5AODVyKRURQ pCue/qR/bb9dxb7pNtsRl2NSK76O8UkGsOr1bSSGaB3J+MTeyJKEqCblK4khXd7BG/z9tttYw8u mep5jKCsBaCFnhuqlj2vpazpkjuHk6 X-Google-Smtp-Source: AGHT+IFXrNM7TGbRsgU+mLXKja2BDYmVML5kONLSoI4CJ1zklwOHq9v9mouiObNy3nqS3ZLhOgmawRKbbpT5ohpa4qQ= X-Received: by 2002:a05:6512:3d19:b0:549:4d78:2418 with SMTP id 2adb3069b0e04-549abacd211mr4098512e87.27.1741863455230; Thu, 13 Mar 2025 03:57:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Thu, 13 Mar 2025 10:57:23 +0000 X-Gm-Features: AQ5f1Jq2yOPXUkxNhx6HVJLPrNS8i2cOWKlwC-TTIJ48yRYMVmT8unJpGyhjBaM Message-ID: Subject: Re: Role based access control discussion To: Aditya Toshniwal Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000007f26f4063037308e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007f26f4063037308e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 13 Mar 2025 at 10:26, Aditya Toshniwal < aditya.toshniwal@enterprisedb.com> wrote: > Hi Dave, > > On Thu, Mar 13, 2025 at 3:36=E2=80=AFPM Dave Page wro= te: > >> Hi >> >> On Thu, 13 Mar 2025 at 06:16, Aditya Toshniwal < >> aditya.toshniwal@enterprisedb.com> wrote: >> >>> Hi Hackers, >>> >>> I have started looking into a feature where users have requested for >>> custom roles. The roles can then be assigned permissions. Here's what I >>> think how it can be done: >>> >>> 1. Create a framework for roles based access control. >>> 2. Allow adding/editing/deleting roles from UI. >>> 3. User management dialog can be converted to a tab to get extra >>> space for other stuff. >>> 4. pgAdmin can have some predefined permissions. The permissions can >>> then be used to validate at the API levels and UI. >>> 5. New permissions cannot be added from UI as it will require code >>> changes. They can be added based on user requests. >>> 6. Admin can allow these permissions to the roles and roles can be >>> assigned to users. >>> 7. Permissions will be used to >>> 8. Admin role remains static with no changes allowed. >>> >>> Let me know your thoughts on this. If everything looks good then I will >>> proceed. >>> >> >> What permissions would we support initially? >> > > Based on https://github.com/pgadmin-org/pgadmin4/issues/7310, we can > start with not allowing users to register a server. We'll start 1 or 2 ma= y > be, the intention is to create a framework which will allow us to keep > adding permissions on future requests. > The reason I ask is that there's no point in creating a framework if we just end up with a single permission for adding/removing servers. I think it makes sense to be sure there are likely to be other permissions before committing to something likely to be a lot more complex than just adding an attribute to a user. --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org pgEdge: https://www.pgedge.com --0000000000007f26f4063037308e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, 13 Mar = 2025 at 10:26, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
Hi=C2=A0Dave,

=
On Thu, Mar 13, 2025 at 3:36=E2=80=AF= PM Dave Page <dpa= ge@pgadmin.org> wrote:
Hi

On Thu, 13 Mar 2025 at 06:16, Aditya Toshniwal <aditya.tosh= niwal@enterprisedb.com> wrote:
Hi Hackers,
<= div style=3D"font-family:verdana,sans-serif">
I have started looking into a feature where users= have requested for custom roles. The roles can then be assigned permission= s. Here's what I think how it can be done:
  1. Create a framework for roles based access co= ntrol.
  2. Allow adding/editing/deleting roles from UI.
  3. User ma= nagement dialog can be converted to a tab to get extra space for other stuf= f.
  4. pgAdmin can have some predefined permissions. The permissions ca= n then be used to validate at the API levels and UI.
  5. New permission= s cannot be added from UI as it will require code changes. They can be adde= d based on user requests.
  6. Admin can allow these permissions to the = roles and roles can be assigned to users.
  7. Permissions will be used = to=C2=A0
  8. Admin role remains static with no changes allowed.
    9. Let me know your thoughts on this. If everything looks good then I w= ill proceed.

What= =C2=A0permissions would we support initially?

Based on=C2= =A0https://github.com/pgadmin-org/pgadmin4/issues/7310, we can= start with not allowing users to register a server. We'll start 1 or 2= may be, the intention is to create a framework which will allow us to keep= adding permissions on future requests.
=
The reason I ask is that there's no point in creating a = framework if we just end up with a single permission for adding/removing se= rvers. I think it makes sense to be sure there are likely to be other permi= ssions before committing to something likely to be a lot more complex than = just adding an attribute to a user.
=C2=A0
--
--0000000000007f26f4063037308e--