[Codematch-develop] DataTracker and CodeMatch access control

Lisandro Zambenedetti Granville <granville@inf.ufrgs.br> Tue, 25 August 2015 18:52 UTC

Return-Path: <granville@inf.ufrgs.br>
X-Original-To: codematch-develop@ietfa.amsl.com
Delivered-To: codematch-develop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D351AC3F2 for <codematch-develop@ietfa.amsl.com>; Tue, 25 Aug 2015 11:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.961
X-Spam-Level:
X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYF9-vxMi_Jd for <codematch-develop@ietfa.amsl.com>; Tue, 25 Aug 2015 11:52:24 -0700 (PDT)
Received: from delivery2.ufrgs.br (delivery2.ufrgs.br [143.54.2.212]) by ietfa.amsl.com (Postfix) with ESMTP id 42D701A0368 for <codematch-develop@ietf.org>; Tue, 25 Aug 2015 11:52:24 -0700 (PDT)
Received: from delivery2.ufrgs.br (localhost [127.0.0.1]) by delivery2.ufrgs.br (Postfix) with ESMTP id 30F7120A3D8; Tue, 25 Aug 2015 15:52:20 -0300 (BRT)
Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery2.ufrgs.br (Postfix) with ESMTP id 34E8A3007D5; Tue, 25 Aug 2015 15:52:20 -0300 (BRT)
From: Lisandro Zambenedetti Granville <granville@inf.ufrgs.br>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Tue, 25 Aug 2015 15:52:19 -0300
Message-Id: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br>
To: codematch-develop <codematch-develop@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
X-Mailer: Apple Mail (2.2102)
X-AV-Checked: ClamAV using ClamSMTP
Archived-At: <http://mailarchive.ietf.org/arch/msg/codematch-develop/vntH1iOHX3Itb96_kwCy7c4nuIc>
Cc: Henrik Levkowetz <henrik@levkowetz.com>, Robert Sparks <rjsparks@nostrum.com>
Subject: [Codematch-develop] DataTracker and CodeMatch access control
X-BeenThere: codematch-develop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" <codematch-develop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codematch-develop>, <mailto:codematch-develop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/codematch-develop/>
List-Post: <mailto:codematch-develop@ietf.org>
List-Help: <mailto:codematch-develop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codematch-develop>, <mailto:codematch-develop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2015 18:52:29 -0000

Dear All

Last week we had our traditional CodeMatch meeting. One of the questions discussed in the meeting was about role-based access control (RBAC) in CodeMatch. We would like to propose adding an extra table in the current data model to support RBAC. However, because we want to be as aligned with DataTracker style as possible, we are sending this message to start a discussion, specially with Henrik and Robert.

1) Style of checking users’ permission

We observed the DataTracker code and it seems that in general, permission checking is hardcoded, in the following style (using “Area Director”, “IAB Chair”, and “Secretariat" as examples):

if has_role(request.user, ["Area Director", "IAB Chair", "Secretariat"]):
	// do something that only area diretor, IAB chair, and secretariat could do, like “Create CodeRequest"


In CodeMatch, we would like to check permissions in the following way:

if has_right(request.user, “Create CodeRequest”):
	// do something that only authorized people should be able to do, like “Create CodeRequest”

The “has_right” function would check the database to retrieve the users’ roles and, for each role, check if it has permission to “Create CodeRequest”. In this way, permissions are associated to roles, and roles associated to users.

Because permissions and roles in CodeMatch are being defined together with the implementation of the system prototype, the use of “has_right” would allow us to assign permissions to roles just changing the database, instead of changing the CodeMatch code if we use “has_role” instead. 

2) Database

Today, permissions are listed in table auth_permission. Roles are listed in table group_role. We would need a intermediate table linking permissions to roles, i.e., a table linking author_permissions and group_role. That would allow us to say, for example, that a mentor (inside group_role) can add documents to a codeRequest (i.e., a permission inside auth_permission). Adding this intermediate table (let’s call it role_permission for the moment) would not affect today’s database, although it would expand today’s data model.

Do you think doing that is ok?

Best regards,

Lisandro, Wanderson, Matheus