From nobody Mon Aug 17 09:51:52 2015 Return-Path: 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 796811A0266 for ; Mon, 17 Aug 2015 09:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no 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 iar5mEbHoXyk for ; Mon, 17 Aug 2015 09:51:47 -0700 (PDT) Received: from mail.lacnic.net.uy (hermes.lacnic.net.uy [IPv6:2001:13c7:7001:4000::8]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6351A0162 for ; Mon, 17 Aug 2015 09:51:47 -0700 (PDT) Received: from hermes.lacnic.net.uy (localhost [127.0.0.1]) by mail.lacnic.net.uy (Postfix) with ESMTP id 5437416B40D61 for ; Mon, 17 Aug 2015 13:51:45 -0300 (UYT) X-Virus-Scanned: amavisd-new at lacnic.net.uy Received: from mail.lacnic.net.uy ([127.0.0.1]) by hermes.lacnic.net.uy (mail.lacnic.net.uy [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvvICtEwoSAa for ; Mon, 17 Aug 2015 13:51:44 -0300 (UYT) Received: from [IPv6:2001:13c7:7001:7128:dc50:dcd7:277b:b37c] (unknown [IPv6:2001:13c7:7001:7128:dc50:dcd7:277b:b37c]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lacnic.net.uy (Postfix) with ESMTPSA id AC29216B40CF8 for ; Mon, 17 Aug 2015 13:51:44 -0300 (UYT) Message-ID: <55D21120.2030102@lacnic.net> Date: Mon, 17 Aug 2015 13:51:44 -0300 From: =?windows-1252?Q?Nicol=E1s?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: codematch-develop@ietf.org References: <961C4F52-EACF-45F4-9A4C-89D400F37D69@isoc.org> In-Reply-To: <961C4F52-EACF-45F4-9A4C-89D400F37D69@isoc.org> Content-Type: multipart/alternative; boundary="------------020903070807010304020305" Archived-At: Subject: Re: [Codematch-develop] Webex 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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 16:51:50 -0000 This is a multi-part message in MIME format. --------------020903070807010304020305 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit When will the next call take place? Thx, Nicolas - LACNIC El 29/07/15 a las 13:34, Christian O'Flaherty escibió: > > Hi, I lost my webex connection and I can’t reconnect. Something > similar happened at the beginning. > > Not sure if it was my side as I originally thought or if it was webex. > > Did you have any similar problem today? > > Christian O'Flaherty - oflaherty@isoc.org > Regional Development -Internet Society > Skype/Gmail/Yahoo!: christian.oflaherty > Phone:+598 98769636 > > > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop --------------020903070807010304020305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit When will the next call take place?

Thx,

Nicolas - LACNIC


El 29/07/15 a las 13:34, Christian O'Flaherty escibió:

Hi, I lost my webex connection and I can’t reconnect. Something similar happened at the beginning. 

Not sure if it was my side as I originally thought or if it was webex.

Did you have any similar problem today?

Christian O'Flaherty - oflaherty@isoc.org
Regional Development - Internet Society 
Skype/Gmail/Yahoo!:  christian.oflaherty 
Phone: +598 98769636



_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

--------------020903070807010304020305-- From nobody Mon Aug 17 10:01:09 2015 Return-Path: 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 482CC1A1A88 for ; Mon, 17 Aug 2015 10:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 SWjf1g7705Ty for ; Mon, 17 Aug 2015 10:01:06 -0700 (PDT) Received: from delivery2.ufrgs.br (delivery2.ufrgs.br [143.54.2.212]) by ietfa.amsl.com (Postfix) with ESMTP id 7399A1A1A4F for ; Mon, 17 Aug 2015 10:01:05 -0700 (PDT) Received: from delivery2.ufrgs.br (localhost [127.0.0.1]) by delivery2.ufrgs.br (Postfix) with ESMTP id CE07420A3E5; Mon, 17 Aug 2015 14:01:02 -0300 (BRT) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery2.ufrgs.br (Postfix) with ESMTP id 0D0313006C8; Mon, 17 Aug 2015 14:01:02 -0300 (BRT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0CF2EEA1-5518-4A3C-B665-067C64C996DB" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Lisandro Zambenedetti Granville In-Reply-To: <55D21120.2030102@lacnic.net> Date: Mon, 17 Aug 2015 14:00:59 -0300 Message-Id: References: <961C4F52-EACF-45F4-9A4C-89D400F37D69@isoc.org> <55D21120.2030102@lacnic.net> To: =?utf-8?Q?Nicol=C3=A1s?= X-Mailer: Apple Mail (2.2102) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: codematch-develop@ietf.org Subject: Re: [Codematch-develop] Webex 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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 17:01:08 -0000 --Apple-Mail=_0CF2EEA1-5518-4A3C-B665-067C64C996DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Nicol=E1s Our next call will be on Wednesday. Do you have the pointers to access = it? Best regards, Lisandro > Em 17/08/2015, =E0(s) 13:51, Nicol=E1s = escreveu: >=20 > When will the next call take place? >=20 > Thx, >=20 > Nicolas - LACNIC >=20 >=20 > El 29/07/15 a las 13:34, Christian O'Flaherty escibi=F3: >>=20 >> Hi, I lost my webex connection and I can=92t reconnect. Something = similar happened at the beginning.=20 >>=20 >> Not sure if it was my side as I originally thought or if it was = webex. >>=20 >> Did you have any similar problem today? >>=20 >> Christian O'Flaherty - oflaherty@isoc.org >> Regional Development - Internet Society=20 >> Skype/Gmail/Yahoo!: christian.oflaherty=20 >> Phone: +598 98769636 >>=20 >>=20 >>=20 >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop = >=20 > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop --Apple-Mail=_0CF2EEA1-5518-4A3C-B665-067C64C996DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Nicol=E1s

Our next call will be on Wednesday. Do you have the pointers = to access it?

Best regards,

Lisandro

Em = 17/08/2015, =E0(s) 13:51, Nicol=E1s <nfiumarelli@lacnic.net> escreveu:

=20 =20
When will the next call take place?

Thx,

Nicolas - LACNIC


El 29/07/15 a las 13:34, Christian O'Flaherty escibi=F3:

Hi, I lost my webex connection and I can=92t reconnect. Something similar happened at the = beginning. 

Not sure if it was my side as I originally thought or if it was webex.

Did you have any similar problem today?

Christian O'Flaherty - oflaherty@isoc.org
Regional Development - Internet Society 
Skype/Gmail/Yahoo!:  christian.oflaherty 
Phone: +598 98769636



_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://w=
ww.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

= --Apple-Mail=_0CF2EEA1-5518-4A3C-B665-067C64C996DB-- From nobody Wed Aug 19 08:56:46 2015 Return-Path: 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 57C591A8733 for ; Wed, 19 Aug 2015 08:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 xyYcxxLB93GT for ; Wed, 19 Aug 2015 08:56:43 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5C01B2AC0 for ; Wed, 19 Aug 2015 08:56:42 -0700 (PDT) Received: by wibhh20 with SMTP id hh20so12483204wib.0 for ; Wed, 19 Aug 2015 08:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GeCfpj9Xa6pIV1DOOey59BnoU7ElO8CG+sRXylFe/4o=; b=SGfoxcTpC0rJAft+JIAPWiIeW/IPvF2woUNcJkPpGdP/DDYupylS7D6cCHh8rGAIqC cdviCYO7yqFQ/6qoiOWkQnfl1A5D8L9ZvmN0c3t8de9znMHeZ/HhqObc+Yyh3dGWZU0i DW1T8QEs8dZ+6wj3yW7/F80e3bNwU5ALs5y9uUlVRXfK7ElOWTprji8hc9IzyF7HClst ldGeKaJfIppnPD24qPtwXwM9UaMr8KZMMpRkApslNVewlsYh19OoQXfAlH6cCSdyY4ol rSnRgCGL6NHOWubSF1Rqn6U14E+B3+4TUYnxswWa8SErvK9xEMTzTQvaKMJXoRAg9UM+ 3c2g== MIME-Version: 1.0 X-Received: by 10.180.73.229 with SMTP id o5mr52920240wiv.36.1439999801563; Wed, 19 Aug 2015 08:56:41 -0700 (PDT) Received: by 10.28.157.84 with HTTP; Wed, 19 Aug 2015 08:56:41 -0700 (PDT) In-Reply-To: References: <961C4F52-EACF-45F4-9A4C-89D400F37D69@isoc.org> <55D21120.2030102@lacnic.net> Date: Wed, 19 Aug 2015 11:56:41 -0400 Message-ID: From: Kathleen Moriarty To: Lisandro Zambenedetti Granville Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: =?UTF-8?B?Tmljb2zDoXM=?= , "codematch-develop@ietf.org" Subject: Re: [Codematch-develop] Webex 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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 15:56:45 -0000 Nicolas, Just in case you need it, here is the call information. We meet every Wednesday from 12-1PM ET. CodeMatch Wednesday, April 1, 2015 12:00 pm | Eastern Daylight Time (New York, GMT-04:00) | 1 hr JOIN WEBEX MEETING https://isoc.webex.com/isoc/j.php?MTID=3Dm061affc9f7318344402b0373d7c32db8 Meeting number: 926 480 716 Meeting password: coder JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Access code: 926 480 716 Global call-in numbers: https://isoc.webex.com/isoc/globalcallin.php?serviceType=3DMC&ED=3D32209933= 2&tollFree=3D0 Can't join the meeting? Contact support here: https://isoc.webex.com/isoc/mc IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. You should inform all meeting attendees prior to recording if you intend to record the meeting. On Mon, Aug 17, 2015 at 1:00 PM, Lisandro Zambenedetti Granville wrote: > Hello Nicol=C3=A1s > > Our next call will be on Wednesday. Do you have the pointers to access it= ? > > Best regards, > > Lisandro > > Em 17/08/2015, =C3=A0(s) 13:51, Nicol=C3=A1s esc= reveu: > > When will the next call take place? > > Thx, > > Nicolas - LACNIC > > > El 29/07/15 a las 13:34, Christian O'Flaherty escibi=C3=B3: > > > Hi, I lost my webex connection and I can=E2=80=99t reconnect. Something s= imilar > happened at the beginning. > > Not sure if it was my side as I originally thought or if it was webex. > > Did you have any similar problem today? > > Christian O'Flaherty - oflaherty@isoc.org > Regional Development - Internet Society > Skype/Gmail/Yahoo!: christian.oflaherty > Phone: +598 98769636 > > > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > > > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > --=20 Best regards, Kathleen From nobody Tue Aug 25 11:52:30 2015 Return-Path: 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 ; 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 ; 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 ; 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 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 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: Cc: Henrik Levkowetz , Robert Sparks 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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=E2=80=99 permission We observed the DataTracker code and it seems that in general, = permission checking is hardcoded, in the following style (using =E2=80=9CA= rea Director=E2=80=9D, =E2=80=9CIAB Chair=E2=80=9D, and =E2=80=9CSecretari= at" 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 =E2=80=9CCreate CodeRequest" In CodeMatch, we would like to check permissions in the following way: if has_right(request.user, =E2=80=9CCreate CodeRequest=E2=80=9D): // do something that only authorized people should be able to = do, like =E2=80=9CCreate CodeRequest=E2=80=9D The =E2=80=9Chas_right=E2=80=9D function would check the database to = retrieve the users=E2=80=99 roles and, for each role, check if it has = permission to =E2=80=9CCreate CodeRequest=E2=80=9D. 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 = =E2=80=9Chas_right=E2=80=9D would allow us to assign permissions to = roles just changing the database, instead of changing the CodeMatch code = if we use =E2=80=9Chas_role=E2=80=9D instead.=20 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=E2=80=99s call it role_permission for the moment) would not affect = today=E2=80=99s database, although it would expand today=E2=80=99s data = model. Do you think doing that is ok? Best regards, Lisandro, Wanderson, Matheus From nobody Tue Aug 25 14:47:42 2015 Return-Path: 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 0122A1A8A5A for ; Tue, 25 Aug 2015 14:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.04 X-Spam-Level: *** X-Spam-Status: No, score=3.04 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 XIq_h36MCuTT for ; Tue, 25 Aug 2015 14:47:38 -0700 (PDT) Received: from mail-mxhero-01.rnp.br (mail-mxhero-01.rnp.br [200.130.35.121]) by ietfa.amsl.com (Postfix) with ESMTP id 096E61A89A8 for ; Tue, 25 Aug 2015 14:47:37 -0700 (PDT) Received: from mail-mxhero-01.rnp.br (localhost [127.0.0.1]) by mail-mxhero-01.rnp.br (Postfix) with ESMTP id 097014003C5 for ; Tue, 25 Aug 2015 21:47:37 +0000 (UTC) Received: from mail-mtaout-proxy-01.rnp.br (mail-mtaout-proxy-01.rnp.br [200.130.35.126]) by mail-mxhero-01.rnp.br (Postfix) with ESMTPS for ; Tue, 25 Aug 2015 21:47:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail-mtaout-proxy-01.rnp.br (Postfix) with ESMTP id B96C110097E for ; Tue, 25 Aug 2015 18:47:49 -0300 (BRT) Received: from mail-mtaout-proxy-01.rnp.br ([127.0.0.1]) by localhost (mail-mtaout-proxy-01.rnp.br [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SKOBA4xLJlK7 for ; Tue, 25 Aug 2015 18:47:49 -0300 (BRT) Received: from CTICBSBPC02 (dhcp124.na-df.rnp.br [200.130.78.124]) by mail-mtaout-proxy-01.rnp.br (Postfix) with ESMTPSA id 9883110072D for ; Tue, 25 Aug 2015 18:47:49 -0300 (BRT) From: "Wanderson Paim" To: "codematch-develop" Date: Tue, 25 Aug 2015 18:47:35 -0300 Message-ID: <133e01d0df7f$a7be94b0$f73bbe10$@rnp.br> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_133F_01D0DF66.82722000" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdDff3QvjWSBsbn3TWqQVsorjAj16A== Content-Language: pt-br x-mxHero-Origin-Ip: /127.0.0.1:48786 Sender: wanderson.jesus@rnp.br Archived-At: Subject: [Codematch-develop] Suggestion of work distribution 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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 21:47:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_133F_01D0DF66.82722000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello all, In the last meeting we discussed the possibility to split the development efforts of the CodeMatch project. So, based on the 'Feature Project Plan', Matheus and I figured out some candidate features that could be developed in parallel. There they go: Visitors, Potential Coder, IETFers, Consumers of Code, etc. 1 - Will be able to view CodeRequests (and matches) by protocol or working group/IETF area 2 - Working group views of CodeRequests and Coders (matches) will be available. Reputation Scoring of Code 3 - Will be limited to features of the code repository used by the coder (ex. Github shows how active a project is, how many followers and forks have been created) Incentives/Awards 4 - Way to show top coders - by volume of projects at first The two first features refers basically to a filter for CodeRequests (and Matches). There are some sort options in the current prototype front-end, but it is not functional yet. The third, related to the reputation of a project (based in the amount of forks in GitHub, for example), lacks a bit of clarity. Maybe we can discuss better in the next meeting. The last feature might be easy to develop. It is about creating a ranking of coders based in the amount of Projects/CodeMatches associated to them. See you tomorrow. Best regards, Wanderson ------=_NextPart_000_133F_01D0DF66.82722000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

In the last meeting we discussed = the possibility to split the development efforts of the CodeMatch = project. So, based on the ‘Feature Project Plan‘, Matheus = and I figured out some candidate features that could be developed in = parallel.

 

There they go:

 

Visitors, Potential Coder, IETFers, Consumers of Code, = etc.

1 - Will be able to view CodeRequests (and matches) by = protocol or working group/IETF area

2 - Working group views of CodeRequests and Coders (matches) = will be available.

Reputation Scoring of = Code

3 - Will be limited to features of the code repository used = by the coder (ex. Github shows how active a project is, how many = followers and forks have been = created)

Incentives/Awards

4 - Way to show top coders - by volume of projects at = first

 

 

The two first features refers basically to a filter for = CodeRequests (and Matches). There are some sort options in the current = prototype front-end, but it is not functional = yet.

 

The third, related to the reputation of a project (based in = the amount of forks in GitHub, for example), lacks a bit of clarity. = Maybe we can discuss better in the next meeting.

 

The last feature might be easy to = develop.  It is about creating a ranking of coders based in the = amount of Projects/CodeMatches associated to = them.

 

See you tomorrow.

 

Best = regards,

 

Wanderson

 

------=_NextPart_000_133F_01D0DF66.82722000-- From nobody Wed Aug 26 07:54:43 2015 Return-Path: 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 18EB71B2D65 for ; Wed, 26 Aug 2015 07:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Z3MxR2BNI4UP for ; Wed, 26 Aug 2015 07:54:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7F81B2CE4 for ; Wed, 26 Aug 2015 07:54:39 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7QEsb09031830 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 26 Aug 2015 09:54:38 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <55DDD328.6020709@nostrum.com> Date: Wed, 26 Aug 2015 09:54:32 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Lisandro Zambenedetti Granville , codematch-develop References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> In-Reply-To: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Henrik Levkowetz Subject: Re: [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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 14:54:42 -0000 Hi Lisandro - Before we go too deep into this, I want to call out a way we expected Role to be used and make sure you've considered it. You are not necessarily restricted to the Role names that are defined now (like "chair"). We could add Role names like "codematcher" or "codematch_approver" or whatever other name matches the semantic for the permission you're wanting to manage. You could then have things like Lisandro Granville is codematch_approver in nmrg. Does that address the need? If not, could you walk me though a scenario where it makes it harder than it should? RjS On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: > 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 > From nobody Wed Aug 26 11:26:50 2015 Return-Path: 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 BB6581B3035 for ; Wed, 26 Aug 2015 11:26:48 -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 v6N5inTbT9rQ for ; Wed, 26 Aug 2015 11:26:45 -0700 (PDT) Received: from delivery1.ufrgs.br (delivery1.ufrgs.br [143.54.2.211]) by ietfa.amsl.com (Postfix) with ESMTP id E8EEE1B303E for ; Wed, 26 Aug 2015 11:26:44 -0700 (PDT) Received: from delivery1.ufrgs.br (localhost [127.0.0.1]) by delivery1.ufrgs.br (Postfix) with ESMTP id 675583007A2; Wed, 26 Aug 2015 15:26:41 -0300 (BRT) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery1.ufrgs.br (Postfix) with ESMTP id 969A33D71C; Wed, 26 Aug 2015 15:26:41 -0300 (BRT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lisandro Zambenedetti Granville In-Reply-To: <55DDD328.6020709@nostrum.com> Date: Wed, 26 Aug 2015 15:26:37 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.2104) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: codematch-develop , Henrik Levkowetz Subject: Re: [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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 18:26:48 -0000 Hello Roberts Comments inline... > You are not necessarily restricted to the Role names that are defined = now (like "chair"). We could add Role names like > "codematcher" or "codematch_approver" or whatever other name matches = the semantic for the permission you're wanting to manage. That=E2=80=99s great, so that we can expand the current Roles without = changing the data model. > You could then have things like Lisandro Granville is = codematch_approver in nmrg. That is also what we need. > Does that address the need? If not, could you walk me though a = scenario where it makes it harder than it should? What you mention above is the link among users, roles, and groups. There = is another link between roles and permissions that seems to be hardcoded = in datatracker. When we say if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat=E2=80=9D]): // do things the user with "permission X" can do it implies that if we want to grant to, e.g., =E2=80=9Ccodematch_approver=E2= =80=9D the =E2=80=9Cpermission X=E2=80=9D above, we should go back to = the code and change it to if has_role(request.user, ["Area Director", "IAB Chair", = =E2=80=9CSecretariat=E2=80=9D, =E2=80=9Ccodematch_approver"]):... We were then considering the possibility of moving the link between = roles and permission to the data model and implement has_right (or = has_permission) like: if has_right(request.user, =E2=80=9Cpermission X=E2=80=9D): // do things the user with "permission X" can do If we want =E2=80=9Cpermission X=E2=80=9D to be granted to other roles, = that would be a matter of including the proper records in the database, = instead of changing the code. Trying not to go too much into details, the summary is that we want to = check if assigning permission to roles is ok to be done in the database, = instead of changing the code. We are of course talking about the = CodeMatch code only; we are not talking about the datatracker code at = all, although examples were inspired by has_role, which is used in = datatracker. Lisandro > On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >> Dear All >>=20 >> 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. >>=20 >> 1) Style of checking users=E2=80=99 permission >>=20 >> We observed the DataTracker code and it seems that in general, = permission checking is hardcoded, in the following style (using =E2=80=9CA= rea Director=E2=80=9D, =E2=80=9CIAB Chair=E2=80=9D, and =E2=80=9CSecretari= at" as examples): >>=20 >> if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat"]): >> // do something that only area diretor, IAB chair, and = secretariat could do, like =E2=80=9CCreate CodeRequest" >>=20 >>=20 >> In CodeMatch, we would like to check permissions in the following = way: >>=20 >> if has_right(request.user, =E2=80=9CCreate CodeRequest=E2=80=9D): >> // do something that only authorized people should be able to = do, like =E2=80=9CCreate CodeRequest=E2=80=9D >>=20 >> The =E2=80=9Chas_right=E2=80=9D function would check the database to = retrieve the users=E2=80=99 roles and, for each role, check if it has = permission to =E2=80=9CCreate CodeRequest=E2=80=9D. In this way, = permissions are associated to roles, and roles associated to users. >>=20 >> Because permissions and roles in CodeMatch are being defined together = with the implementation of the system prototype, the use of = =E2=80=9Chas_right=E2=80=9D would allow us to assign permissions to = roles just changing the database, instead of changing the CodeMatch code = if we use =E2=80=9Chas_role=E2=80=9D instead. >>=20 >> 2) Database >>=20 >> 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=E2=80=99s call it role_permission for the moment) would not affect = today=E2=80=99s database, although it would expand today=E2=80=99s data = model. >>=20 >> Do you think doing that is ok? >>=20 >> Best regards, >>=20 >> Lisandro, Wanderson, Matheus >>=20 >=20 > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop From nobody Wed Aug 26 12:00:15 2015 Return-Path: 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 C2B891B312C for ; Wed, 26 Aug 2015 12:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ei8wEHV0Ve1D for ; Wed, 26 Aug 2015 12:00:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581AB1B311F for ; Wed, 26 Aug 2015 12:00:10 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7QJ08jW052976 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 26 Aug 2015 14:00:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <55DE0CB3.8020001@nostrum.com> Date: Wed, 26 Aug 2015 14:00:03 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Lisandro Zambenedetti Granville References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> In-Reply-To: <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: codematch-develop , Henrik Levkowetz Subject: Re: [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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 19:00:14 -0000 On 8/26/15 1:26 PM, Lisandro Zambenedetti Granville wrote: > Hello Roberts > > Comments inline... > >> You are not necessarily restricted to the Role names that are defined now (like "chair"). We could add Role names like >> "codematcher" or "codematch_approver" or whatever other name matches the semantic for the permission you're wanting to manage. > That’s great, so that we can expand the current Roles without changing the data model. > >> You could then have things like Lisandro Granville is codematch_approver in nmrg. > That is also what we need. Just to be sure - you're saying that's sufficient, and while you're explaining the idea further below, you don't need it right now? >> Does that address the need? If not, could you walk me though a scenario where it makes it harder than it should? > What you mention above is the link among users, roles, and groups. There is another link between roles and permissions that seems to be hardcoded in datatracker. When we say > > if has_role(request.user, ["Area Director", "IAB Chair", "Secretariat”]): > // do things the user with "permission X" can do > > it implies that if we want to grant to, e.g., “codematch_approver” the “permission X” above, we should go back to the code and change it to > > if has_role(request.user, ["Area Director", "IAB Chair", “Secretariat”, “codematch_approver"]):... > > We were then considering the possibility of moving the link between roles and permission to the data model and implement has_right (or has_permission) like: > > if has_right(request.user, “permission X”): > // do things the user with "permission X" can do > > If we want “permission X” to be granted to other roles, that would be a matter of including the proper records in the database, instead of changing the code. > > Trying not to go too much into details, the summary is that we want to check if assigning permission to roles is ok to be done in the database, instead of changing the code. Well, you still have to type has_right(...) in the code, and specify something concrete in that has_right that would have to change, so I don't think we're really talking about avoiding changing code as much as we are about _where_ you model the idea of a permission in the database. I think the real essence of what we're talking about is the difference in how you would implement "Give all the WG chairs codematch-approval rights". With your proposal, you would make a role to permission match to do that - one database row change - pretty efficient (*) With what we have now, you just add a Role of "codematch-approval" to any Person that has a wg chair role. So, I think what you're proposing is an optimization, and it comes with some complexity. We can keep talking about it, but I don't think we're at the point that we need it. (*) But, it's not really that easy. Right now we have a role of "chair" that is applied to all groups. There's no way to speak differently about WG chairs and RG chairs by simply saying "chair" - it takes more code. We have chairs of Teams, and _could_ have (but don't currently) chairs of other SDOs in the database. So, the apparent simplicity of matching a permission to a role-name isn't as strong as it first appears. > We are of course talking about the CodeMatch code only; we are not talking about the datatracker code at all, although examples were inspired by has_role, which is used in datatracker. > > Lisandro > >> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >>> 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 >>> >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop From nobody Wed Aug 26 12:38:17 2015 Return-Path: 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 0021F1A92B6 for ; Wed, 26 Aug 2015 12:38:16 -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 7mQTj7nHdTID for ; Wed, 26 Aug 2015 12:38:13 -0700 (PDT) Received: from delivery1.ufrgs.br (delivery1.ufrgs.br [143.54.2.211]) by ietfa.amsl.com (Postfix) with ESMTP id 808A21A8A27 for ; Wed, 26 Aug 2015 12:38:12 -0700 (PDT) Received: from delivery1.ufrgs.br (localhost [127.0.0.1]) by delivery1.ufrgs.br (Postfix) with ESMTP id 732EF3007A4; Wed, 26 Aug 2015 16:38:09 -0300 (BRT) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery1.ufrgs.br (Postfix) with ESMTP id 69D553D71C; Wed, 26 Aug 2015 16:38:09 -0300 (BRT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lisandro Zambenedetti Granville In-Reply-To: <55DE0CB3.8020001@nostrum.com> Date: Wed, 26 Aug 2015 16:38:07 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.2104) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: codematch-develop , Henrik Levkowetz Subject: Re: [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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 19:38:16 -0000 Hello Robert >>> You are not necessarily restricted to the Role names that are = defined now (like "chair"). We could add Role names like >>> "codematcher" or "codematch_approver" or whatever other name matches = the semantic for the permission you're wanting to manage. >> That=92s great, so that we can expand the current Roles without = changing the data model. >>=20 >>> You could then have things like Lisandro Granville is = codematch_approver in nmrg. >> That is also what we need. > Just to be sure - you're saying that's sufficient, and while you're = explaining the idea further below, you don't need it right now? Sorry, I was not clear. Creating new Roles and allowing users being = assigned to these new Roles are things that we need in CodeMatch too. = Further below I mention something that we are proposing (i.e., = has_right) in addition to having new roles. >>> Does that address the need? If not, could you walk me though a = scenario where it makes it harder than it should? >> What you mention above is the link among users, roles, and groups. = There is another link between roles and permissions that seems to be = hardcoded in datatracker. When we say >>=20 >> if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat=94]): >> // do things the user with "permission X" can do >>=20 >> it implies that if we want to grant to, e.g., =93codematch_approver=94 = the =93permission X=94 above, we should go back to the code and change = it to >>=20 >> if has_role(request.user, ["Area Director", "IAB Chair", = =93Secretariat=94, =93codematch_approver"]):... >>=20 >> We were then considering the possibility of moving the link between = roles and permission to the data model and implement has_right (or = has_permission) like: >>=20 >> if has_right(request.user, =93permission X=94): >> // do things the user with "permission X" can do >>=20 >> If we want =93permission X=94 to be granted to other roles, that = would be a matter of including the proper records in the database, = instead of changing the code. >>=20 >> Trying not to go too much into details, the summary is that we want = to check if assigning permission to roles is ok to be done in the = database, instead of changing the code. > Well, you still have to type has_right(...) in the code, and specify = something concrete in that has_right that would have to change, > so I don't think we're really talking about avoiding changing code as = much as we are about _where_ you model the idea of a permission in the = database. I agree. We are talking about modeling the link between roles and = permission in the database. > I think the real essence of what we're talking about is the difference = in how you would implement > "Give all the WG chairs codematch-approval rights". >=20 > With your proposal, you would make a role to permission match to do = that - one database row change - pretty efficient (*) > With what we have now, you just add a Role of "codematch-approval" to = any Person that has a wg chair role. > So, I think what you're proposing is an optimization, and it comes = with some complexity. We can keep talking about it, but I don't > think we're at the point that we need it. This complexity involves: a) Creating a new intermediate table =93role_auth_permission" composed = of, at least, two columns: role_id and auth_permission_id; b) Creating the function "has_right (user, permission_label)" which = given the user it retrieves the user=92s roles, from roles it retrieves = permissions and, among permissions, it checks if permission_label is = present.=20 Of course, the effort of doing a) and b) would be ours. And these = implementation would be used in CodeMatch only; it wouldn=92t be = changing or affecting DataTracker. > (*) But, it's not really that easy. Right now we have a role of = "chair" that is applied to all groups. There's no way to speak = differently about WG chairs and RG chairs by simply saying "chair" - it = takes more code. We have chairs of Teams, and _could_ have (but don't = currently) chairs of other SDOs in the database. So, the apparent = simplicity of matching a permission to a role-name isn't as strong as it = first appears. While coding the CodeMatch system, we notice that some portions of the = system may be or may be not available to different user roles. Although = we define somes roles now, changes on role-permissions will probably = happen along the development process.=20 The permissions we want the roles to have define, let me say, the policy = of CodeMatch. We wanted to decouple that policy from the system = implementation itself, thus implementing an RBAC model; if the link = between roles and permissions (i.e., the system policy) migrates to the = database, we can tag CodeMatch source code (i.e., define permission = labels) and redefine which roles are able to access different parts of = the system. Notice, this is just for CodeMatch, of course.=20 Thanks, Lisandro >> We are of course talking about the CodeMatch code only; we are not = talking about the datatracker code at all, although examples were = inspired by has_role, which is used in datatracker. >>=20 >> Lisandro >>=20 >>> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >>>> Dear All >>>>=20 >>>> 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. >>>>=20 >>>> 1) Style of checking users=92 permission >>>>=20 >>>> We observed the DataTracker code and it seems that in general, = permission checking is hardcoded, in the following style (using =93Area = Director=94, =93IAB Chair=94, and =93Secretariat" as examples): >>>>=20 >>>> if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat"]): >>>> // do something that only area diretor, IAB chair, and = secretariat could do, like =93Create CodeRequest" >>>>=20 >>>>=20 >>>> In CodeMatch, we would like to check permissions in the following = way: >>>>=20 >>>> if has_right(request.user, =93Create CodeRequest=94): >>>> // do something that only authorized people should be able to = do, like =93Create CodeRequest=94 >>>>=20 >>>> The =93has_right=94 function would check the database to retrieve = the users=92 roles and, for each role, check if it has permission to = =93Create CodeRequest=94. In this way, permissions are associated to = roles, and roles associated to users. >>>>=20 >>>> Because permissions and roles in CodeMatch are being defined = together with the implementation of the system prototype, the use of = =93has_right=94 would allow us to assign permissions to roles just = changing the database, instead of changing the CodeMatch code if we use = =93has_role=94 instead. >>>>=20 >>>> 2) Database >>>>=20 >>>> 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=92s call it role_permission for the moment) would not affect = today=92s database, although it would expand today=92s data model. >>>>=20 >>>> Do you think doing that is ok? >>>>=20 >>>> Best regards, >>>>=20 >>>> Lisandro, Wanderson, Matheus >>>>=20 >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop >=20 From nobody Thu Aug 27 08:20:50 2015 Return-Path: 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 6D2141B3294 for ; Thu, 27 Aug 2015 06:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 67zbKVQB_IIe for ; Thu, 27 Aug 2015 06:07:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDFA1A8A0E for ; Thu, 27 Aug 2015 06:07:11 -0700 (PDT) Received: from [2a01:3f0:1:0:14b4:7a80:7b37:8741] (port=56436 helo=tannat.netnod.se) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZUwtY-0007Km-R0; Thu, 27 Aug 2015 06:07:10 -0700 Message-ID: <55DF0B7B.7020902@levkowetz.com> Date: Thu, 27 Aug 2015 15:07:07 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Lisandro Zambenedetti Granville , Robert Sparks References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> In-Reply-To: <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:14b4:7a80:7b37:8741 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, codematch-develop@ietf.org, rjsparks@nostrum.com, granville@inf.ufrgs.br X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Archived-At: X-Mailman-Approved-At: Thu, 27 Aug 2015 08:20:40 -0700 Cc: codematch-develop Subject: Re: [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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 13:07:43 -0000 Hi Lisandro, Jumping in here with some comments: On 2015-08-26 21:38, Lisandro Zambenedetti Granville wrote: > Hello Robert > >>>> You are not necessarily restricted to the Role names that are >>>> defined now (like "chair"). We could add Role names like >>>> "codematcher" or "codematch_approver" or whatever other name >>>> matches the semantic for the permission you're wanting to >>>> manage. >>> >>> That’s great, so that we can expand the current Roles without >>> changing the data model. >>> >>>> You could then have things like Lisandro Granville is >>>> codematch_approver in nmrg. >>> >>> That is also what we need. >> >> Just to be sure - you're saying that's sufficient, and while you're >> explaining the idea further below, you don't need it right now? > > Sorry, I was not clear. Creating new Roles and allowing users being > assigned to these new Roles are things that we need in CodeMatch too. > Further below I mention something that we are proposing (i.e., > has_right) in addition to having new roles. > >>>> Does that address the need? If not, could you walk me though a >>>> scenario where it makes it harder than it should? >>> >>> What you mention above is the link among users, roles, and >>> groups. There is another link between roles and permissions that >>> seems to be hardcoded in datatracker. When we say >>> >>> if has_role(request.user, ["Area Director", "IAB Chair", "Secretariat”]): >>> // do things the user with "permission X" can do >>> >>> it implies that if we want to grant to, e.g., >>> “codematch_approver” the “permission X” above, we should go back >>> to the code and change it to >>> >>> if has_role(request.user, ["Area Director", "IAB Chair", >>> “Secretariat”, “codematch_approver"]):... >>> >>> We were then considering the possibility of moving the link >>> between roles and permission to the data model and implement >>> has_right (or has_permission) like: >>> >>> if has_right(request.user, “permission X”): >>> // do things the user with "permission X" can do >>> >>> If we want “permission X” to be granted to other roles, that >>> would be a matter of including the proper records in the >>> database, instead of changing the code. >>> >>> Trying not to go too much into details, the summary is that we >>> want to check if assigning permission to roles is ok to be done >>> in the database, instead of changing the code. >> >> Well, you still have to type has_right(...) in the code, and >> specify something concrete in that has_right that would have to >> change, so I don't think we're really talking about avoiding >> changing code as much as we are about _where_ you model the idea of >> a permission in the database. > > I agree. We are talking about modeling the link between roles and > permission in the database. So, the design you propose is elegant and matches the way permissions are handled in many contexts, especially in COTS software (and for that matter, user-configurable FOSS software). It is more flexible, but also has an added complexity, and an added abstraction level (in order to be useful, the permissions need to be named with names which express what effect they are having in the code, and this may be non-trivial). There is however one point you don't bring up, which I would like to bring up here. Summarizing the two ways of writing the code, we can either have code which says if has_role(user, ["CodeMatch Approver"]): # code to be exectuted or code which says if has_perm(user, ["approve codematch"]): # code to be exectuted For IETF roles, the list of possible roles are very well codified, while the only way to know which permissions that need to be named and listed in a role_auth_permission table is to go through the code and name all the places we check for roles today. Naming those permissions, and making clear the correspondence between the names and the actual effect they will have in code is not necessarily trivial. For the Codematch project, it may be that you have a much better grasp of the named permissions needed, and not so good a grasp of the roles. However, since irrespective of how the correspondence between roles and code is handled, whether it is via has_role() or has_perm(), you actually _need_ to be able to describe the roles well, I would suggest that you probably also have a much better grasp of the roles than of all the named permissions which may be needed. Given that, I would suggest that you start out with the same approach which has been used in the current datatracker code, and once it is possible to inspect the code and see which actual places need to check for different roles in order to determine if a given piece of code may be executed, _and_ you have experience with the tool so that you can speak with confidence about which actions a given role should or should not have, then _at that point_ we can consider refining things into roles and permissions, instead of listing roles explicitly in the code. More below. >> I think the real essence of what we're talking about is the >> difference in how you would implement "Give all the WG chairs >> codematch-approval rights". >> >> With your proposal, you would make a role to permission match to do >> that - one database row change - pretty efficient (*) With what we >> have now, you just add a Role of "codematch-approval" to any Person >> that has a wg chair role. So, I think what you're proposing is an >> optimization, and it comes with some complexity. We can keep >> talking about it, but I don't think we're at the point that we need >> it. > > This complexity involves: > > a) Creating a new intermediate table “role_auth_permission" composed > of, at least, two columns: role_id and auth_permission_id; > > b) Creating the function "has_right (user, permission_label)" which > given the user it retrieves the user’s roles, from roles it retrieves > permissions and, among permissions, it checks if permission_label is > present. > > Of course, the effort of doing a) and b) would be ours. And these > implementation would be used in CodeMatch only; it wouldn’t be > changing or affecting DataTracker. Understood. But for the datatracker, there is the added complexity of maintaining code which uses 2 different mechanisms to handle permissions. And that the technical debt of carrying two different solutions forward is something you will not have to suffer, but the datatracker project will have to deal with. >> (*) But, it's not really that easy. Right now we have a role of >> "chair" that is applied to all groups. There's no way to speak >> differently about WG chairs and RG chairs by simply saying "chair" >> - it takes more code. We have chairs of Teams, and _could_ have >> (but don't currently) chairs of other SDOs in the database. So, the >> apparent simplicity of matching a permission to a role-name isn't >> as strong as it first appears. > > While coding the CodeMatch system, we notice that some portions of > the system may be or may be not available to different user roles. > Although we define somes roles now, changes on role-permissions will > probably happen along the development process. Agreed. In which case, doing the necessary has_role() or has_perm() code changes will most likely happen along with other code changes. > The permissions we want the roles to have define, let me say, the > policy of CodeMatch. We wanted to decouple that policy from the > system implementation itself, thus implementing an RBAC model; if the > link between roles and permissions (i.e., the system policy) migrates > to the database, we can tag CodeMatch source code (i.e., define > permission labels) and redefine which roles are able to access > different parts of the system. Notice, this is just for CodeMatch, of > course. RBAC can be implemented both with has_role() and has_perm(); the difference lies in how easy it is to reconfigure the permissions which are associated with a given role. For COTS software, where you cannot easily adapt the code itself to the customer environment and wishes, other than through data lookup, the approach you suggest makes a lot of sense. For our case, where there is one and only one production system, it is far less important, and it is not obvious that the added complexity and technical debt incurred is offset by the added flexibility. Please also consider the pace with which we release software for the datatracker: Formal releases are shown in the page: https://datatracker.ietf.org/release/ and in addition to that, we often apply patches. As an example, we have done 10 formal releases within the 6.x.y series, but during the same time, we have applied 36 patches, resulting in 20 patch release numbers in addition to the formal release numbers. With this release pace, and with the possibility of applying patches, we are probably agile enough to handle the necessary code changes almost as fast as you could agree on what needs to be done and change the settings in a role_auth_permission table. Could we agree on starting an RBAC implementation using has_role(), and once we have a bit more experience, and only then, consider taking on the added complexity and technical debt of using 2 different permission handling systems in this non-COTS software? Best regards, Henrik > Thanks, > > Lisandro > >>> We are of course talking about the CodeMatch code only; we are not talking about the datatracker code at all, although examples were inspired by has_role, which is used in datatracker. >>> >>> Lisandro >>> >>>> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >>>>> 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 >>>>> >>>> _______________________________________________ >>>> Codematch-develop mailing list >>>> Codematch-develop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codematch-develop >> > > From nobody Thu Aug 27 11:30:58 2015 Return-Path: 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 B9DE91B2E93 for ; Thu, 27 Aug 2015 11:30:56 -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 fGqPAbfmrcMl for ; Thu, 27 Aug 2015 11:30:52 -0700 (PDT) Received: from delivery1.ufrgs.br (delivery1.ufrgs.br [143.54.2.211]) by ietfa.amsl.com (Postfix) with ESMTP id C4AB71B2E84 for ; Thu, 27 Aug 2015 11:30:51 -0700 (PDT) Received: from delivery1.ufrgs.br (localhost [127.0.0.1]) by delivery1.ufrgs.br (Postfix) with ESMTP id 61FF6300970; Thu, 27 Aug 2015 15:30:48 -0300 (BRT) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery1.ufrgs.br (Postfix) with ESMTP id A22EE3D847; Thu, 27 Aug 2015 15:30:48 -0300 (BRT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Lisandro Zambenedetti Granville In-Reply-To: <55DF0B7B.7020902@levkowetz.com> Date: Thu, 27 Aug 2015 15:30:47 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.2104) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Cc: codematch-develop , Robert Sparks Subject: Re: [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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 18:30:56 -0000 Hello Henrik Thanks for all clarifications. Going to the most important question: "Could we agree on starting an RBAC implementation using has_role(), and once we have a bit more experience, and only then, consider taking on the added complexity and technical debt of using 2 different permission handling systems in this non-COTS software?=E2=80=9D Definitely yes. I=E2=80=99m convinced, after reading your arguments, = that having two different permission solutions in the same framework can = be ok for CodeMatch but it wouldn=E2=80=99t be ok for datatracker. An = your suggestion of concentrating now more on who can/cannot do what = should be a priority. Best regards, Lisandro > Em 27/08/2015, =C3=A0(s) 10:07, Henrik Levkowetz = escreveu: >=20 > Hi Lisandro, >=20 > Jumping in here with some comments: >=20 > On 2015-08-26 21:38, Lisandro Zambenedetti Granville wrote: >> Hello Robert >>=20 >>>>> You are not necessarily restricted to the Role names that are >>>>> defined now (like "chair"). We could add Role names like=20 >>>>> "codematcher" or "codematch_approver" or whatever other name >>>>> matches the semantic for the permission you're wanting to >>>>> manage. >>>>=20 >>>> That=E2=80=99s great, so that we can expand the current Roles = without >>>> changing the data model. >>>>=20 >>>>> You could then have things like Lisandro Granville is >>>>> codematch_approver in nmrg. >>>>=20 >>>> That is also what we need. >>>=20 >>> Just to be sure - you're saying that's sufficient, and while you're >>> explaining the idea further below, you don't need it right now? >>=20 >> Sorry, I was not clear. Creating new Roles and allowing users being >> assigned to these new Roles are things that we need in CodeMatch too. >> Further below I mention something that we are proposing (i.e., >> has_right) in addition to having new roles. >>=20 >=20 >>>>> Does that address the need? If not, could you walk me though a >>>>> scenario where it makes it harder than it should? >>>>=20 >>>> What you mention above is the link among users, roles, and >>>> groups. There is another link between roles and permissions that >>>> seems to be hardcoded in datatracker. When we say >>>>=20 >>>> if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat=E2=80=9D]): >>>> // do things the user with "permission X" can do >>>>=20 >>>> it implies that if we want to grant to, e.g., >>>> =E2=80=9Ccodematch_approver=E2=80=9D the =E2=80=9Cpermission X=E2=80=9D= above, we should go back >>>> to the code and change it to >>>>=20 >>>> if has_role(request.user, ["Area Director", "IAB Chair", >>>> =E2=80=9CSecretariat=E2=80=9D, =E2=80=9Ccodematch_approver"]):... >>>>=20 >>>> We were then considering the possibility of moving the link >>>> between roles and permission to the data model and implement >>>> has_right (or has_permission) like: >>>>=20 >>>> if has_right(request.user, =E2=80=9Cpermission X=E2=80=9D): >>>> // do things the user with "permission X" can do >>>>=20 >>>> If we want =E2=80=9Cpermission X=E2=80=9D to be granted to other = roles, that >>>> would be a matter of including the proper records in the >>>> database, instead of changing the code. >>>>=20 >>>> Trying not to go too much into details, the summary is that we >>>> want to check if assigning permission to roles is ok to be done >>>> in the database, instead of changing the code. >>>=20 >>> Well, you still have to type has_right(...) in the code, and >>> specify something concrete in that has_right that would have to >>> change, so I don't think we're really talking about avoiding >>> changing code as much as we are about _where_ you model the idea of >>> a permission in the database. >>=20 >> I agree. We are talking about modeling the link between roles and >> permission in the database. >=20 > So, the design you propose is elegant and matches the way permissions > are handled in many contexts, especially in COTS software (and for > that matter, user-configurable FOSS software). >=20 > It is more flexible, but also has an added complexity, and an added > abstraction level (in order to be useful, the permissions need to be > named with names which express what effect they are having in the = code, > and this may be non-trivial). >=20 > There is however one point you don't bring up, which I would like to > bring up here. >=20 > Summarizing the two ways of writing the code, we can either have code > which says >=20 > if has_role(user, ["CodeMatch Approver"]): > # code to be exectuted >=20 > or code which says >=20 > if has_perm(user, ["approve codematch"]): > # code to be exectuted >=20 > For IETF roles, the list of possible roles are very well codified, > while the only way to know which permissions that need to be named > and listed in a role_auth_permission table is to go through the > code and name all the places we check for roles today. Naming those > permissions, and making clear the correspondence between the names > and the actual effect they will have in code is not necessarily > trivial. >=20 > For the Codematch project, it may be that you have a much better grasp > of the named permissions needed, and not so good a grasp of the roles. >=20 > However, since irrespective of how the correspondence between roles = and > code is handled, whether it is via has_role() or has_perm(), you = actually > _need_ to be able to describe the roles well, I would suggest that you > probably also have a much better grasp of the roles than of all the > named permissions which may be needed. >=20 > Given that, I would suggest that you start out with the same approach > which has been used in the current datatracker code, and once it is > possible to inspect the code and see which actual places need to check > for different roles in order to determine if a given piece of code may > be executed, _and_ you have experience with the tool so that you can > speak with confidence about which actions a given role should or = should > not have, then _at that point_ we can consider refining things into > roles and permissions, instead of listing roles explicitly in the = code. >=20 > More below. >=20 >>> I think the real essence of what we're talking about is the >>> difference in how you would implement "Give all the WG chairs >>> codematch-approval rights". >>>=20 >>> With your proposal, you would make a role to permission match to do >>> that - one database row change - pretty efficient (*) With what we >>> have now, you just add a Role of "codematch-approval" to any Person >>> that has a wg chair role. So, I think what you're proposing is an >>> optimization, and it comes with some complexity. We can keep >>> talking about it, but I don't think we're at the point that we need >>> it. >>=20 >> This complexity involves: >>=20 >> a) Creating a new intermediate table =E2=80=9Crole_auth_permission" = composed >> of, at least, two columns: role_id and auth_permission_id; >>=20 >> b) Creating the function "has_right (user, permission_label)" which >> given the user it retrieves the user=E2=80=99s roles, from roles it = retrieves >> permissions and, among permissions, it checks if permission_label is >> present. >>=20 >> Of course, the effort of doing a) and b) would be ours. And these >> implementation would be used in CodeMatch only; it wouldn=E2=80=99t = be >> changing or affecting DataTracker. >=20 > Understood. But for the datatracker, there is the added complexity of > maintaining code which uses 2 different mechanisms to handle = permissions. > And that the technical debt of carrying two different solutions = forward > is something you will not have to suffer, but the datatracker project > will have to deal with. >=20 >>> (*) But, it's not really that easy. Right now we have a role of >>> "chair" that is applied to all groups. There's no way to speak >>> differently about WG chairs and RG chairs by simply saying "chair" >>> - it takes more code. We have chairs of Teams, and _could_ have >>> (but don't currently) chairs of other SDOs in the database. So, the >>> apparent simplicity of matching a permission to a role-name isn't >>> as strong as it first appears. >>=20 >> While coding the CodeMatch system, we notice that some portions of >> the system may be or may be not available to different user roles. >> Although we define somes roles now, changes on role-permissions will >> probably happen along the development process. >=20 > Agreed. In which case, doing the necessary has_role() or has_perm()=20= > code changes will most likely happen along with other code changes. >=20 >> The permissions we want the roles to have define, let me say, the >> policy of CodeMatch. We wanted to decouple that policy from the >> system implementation itself, thus implementing an RBAC model; if the >> link between roles and permissions (i.e., the system policy) migrates >> to the database, we can tag CodeMatch source code (i.e., define >> permission labels) and redefine which roles are able to access >> different parts of the system. Notice, this is just for CodeMatch, of >> course. >=20 > RBAC can be implemented both with has_role() and has_perm(); the = difference > lies in how easy it is to reconfigure the permissions which are = associated > with a given role. >=20 > For COTS software, where you cannot easily adapt the code itself to = the > customer environment and wishes, other than through data lookup, the > approach you suggest makes a lot of sense. For our case, where there = is > one and only one production system, it is far less important, and it = is > not obvious that the added complexity and technical debt incurred is > offset by the added flexibility. >=20 > Please also consider the pace with which we release software for the > datatracker: Formal releases are shown in the page: >=20 > https://datatracker.ietf.org/release/ >=20 > and in addition to that, we often apply patches. As an example, we > have done 10 formal releases within the 6.x.y series, but during the > same time, we have applied 36 patches, resulting in 20 patch release > numbers in addition to the formal release numbers. With this release > pace, and with the possibility of applying patches, we are probably > agile enough to handle the necessary code changes almost as fast as = you > could agree on what needs to be done and change the settings in a=20 > role_auth_permission table. >=20 > Could we agree on starting an RBAC implementation using has_role(), = and > once we have a bit more experience, and only then, consider taking on > the added complexity and technical debt of using 2 different = permission > handling systems in this non-COTS software? >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 >> Thanks, >>=20 >> Lisandro >>=20 >>>> We are of course talking about the CodeMatch code only; we are not = talking about the datatracker code at all, although examples were = inspired by has_role, which is used in datatracker. >>>>=20 >>>> Lisandro >>>>=20 >>>>> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >>>>>> Dear All >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 1) Style of checking users=E2=80=99 permission >>>>>>=20 >>>>>> We observed the DataTracker code and it seems that in general, = permission checking is hardcoded, in the following style (using =E2=80=9CA= rea Director=E2=80=9D, =E2=80=9CIAB Chair=E2=80=9D, and =E2=80=9CSecretari= at" as examples): >>>>>>=20 >>>>>> if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat"]): >>>>>> // do something that only area diretor, IAB chair, and = secretariat could do, like =E2=80=9CCreate CodeRequest" >>>>>>=20 >>>>>>=20 >>>>>> In CodeMatch, we would like to check permissions in the following = way: >>>>>>=20 >>>>>> if has_right(request.user, =E2=80=9CCreate CodeRequest=E2=80=9D): >>>>>> // do something that only authorized people should be able to = do, like =E2=80=9CCreate CodeRequest=E2=80=9D >>>>>>=20 >>>>>> The =E2=80=9Chas_right=E2=80=9D function would check the database = to retrieve the users=E2=80=99 roles and, for each role, check if it has = permission to =E2=80=9CCreate CodeRequest=E2=80=9D. In this way, = permissions are associated to roles, and roles associated to users. >>>>>>=20 >>>>>> Because permissions and roles in CodeMatch are being defined = together with the implementation of the system prototype, the use of = =E2=80=9Chas_right=E2=80=9D would allow us to assign permissions to = roles just changing the database, instead of changing the CodeMatch code = if we use =E2=80=9Chas_role=E2=80=9D instead. >>>>>>=20 >>>>>> 2) Database >>>>>>=20 >>>>>> 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=E2=80=99s call it role_permission for the moment) would not affect = today=E2=80=99s database, although it would expand today=E2=80=99s data = model. >>>>>>=20 >>>>>> Do you think doing that is ok? >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Lisandro, Wanderson, Matheus >>>>>>=20 >>>>> _______________________________________________ >>>>> Codematch-develop mailing list >>>>> Codematch-develop@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>=20 >>=20 >>=20