Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control

From: Christian O'Flaherty <[email-masked]>
Date: Fri, 4 Sep 2015 10:57:36 -0300

Hi Henrik,

We will follow your advise on permissions and roles. 
The Datamodel and readability issues (conventions on variable names and class attributes) were also fixed (those that you flagged when we started coding).

We will need an assessment soon to check what’s missing to be “appropriate” and what would be the next steps to be part of a Datatracker release.

Can you help us with that? 

Christian O'Flaherty - [email-masked] <mailto:[email-masked]>
Regional Development - Internet Society 
Skype/Gmail/Yahoo!:  christian.oflaherty 
Phone: +598 98769636

> On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville <[email-masked]> wrote:
> 
> 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?”
> 
> Definitely yes. I’m convinced, after reading your arguments, that having two different permission solutions in the same framework can be ok for CodeMatch but it wouldn’t 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, à(s) 10:07, Henrik Levkowetz <[email-masked]> escreveu:
>> 
>> 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
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop
>>>> 
>>> 
>>> 
> 
> _______________________________________________
> Codematch-develop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codematch-develop

---

From: Christian O'Flaherty <[email-masked]>
Date: Tue, 15 Sep 2015 19:06:53 -0300

H Henrik, 

> We will need an assessment soon to check what’s missing to be “appropriate” and what would be the next steps to be part of a Datatracker release.

Can you help us or join our call tomorrow at 16 UTC ?

Thanks,

> On Sep 4, 2015, at 10:57 AM, Christian O'Flaherty <[email-masked]> wrote:
> 
> Hi Henrik,
> 
>> On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello Henrik
>> 
>>> Em 27/08/2015, à(s) 10:07, Henrik Levkowetz <[email-masked] <mailto:[email-masked]>> escreveu:
>>> 
>>> Hi Lisandro,
>>> 
>>>  https://datatracker.ietf.org/release/ <https://datatracker.ietf.org/release/>
>>> 
>>>>>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 15 Sep 2015 17:33:15 -0500

I thought the calls were on Tuesdays - when did that change?

That aside - My advice from long ago (discussed before and during the 
Hawaii meeting), and my understanding of the plan was that this would 
initially be developed and deployed as a separate application that 
_used_ the datatracker database in read only mode, and used its own 
database to back the additional django classes it needed. We would 
integrate this into the datatracker more tightly after we had some 
runtime experience (allowing you to refactor more easily based on that 
experience).

Our more recent discussion about how to use the Role object is 
consistent with that. We can add Role records to the production 
datatracker database easily.

So, it's not clear to me that being part of a datatracker release is 
what we need to be talking about right now?

RjS

On 9/15/15 5:06 PM, Christian O'Flaherty wrote:
>> We will need an assessment soon to check what’s missing to be 
>> “appropriate” and what would be the next steps to be part of a 
>> Datatracker release.
>
> Regional Development -Internet Society
> Phone:+598 98769636
>> On Sep 4, 2015, at 10:57 AM, Christian O'Flaherty <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Henrik,
>>
>> The Datamodel and readability issues (conventions on variable names 
>> and class attributes) were also fixed (those that you flagged when we 
>> started coding).
>>
>> We will need an assessment soon to check what’s missing to be 
>> “appropriate” and what would be the next steps to be part of a 
>> Datatracker release.
>>
>> Regional Development -Internet Society
>> Phone:+598 98769636
>>> On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>> Hello Henrik
>>>
>>> Definitely yes. I’m convinced, after reading your arguments, that 
>>> having two different permission solutions in the same framework can 
>>> be ok for CodeMatch but it wouldn’t be ok for datatracker. An your 
>>> suggestion of concentrating now more on who can/cannot do what 
>>> should be a priority.
>>>
>>> Best regards,
>>>
>>> Lisandro
>>>
>>>>>>> "Secretariat”]):
>>>>>>> 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
>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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):
>>>>>>>>>
>>>>>>>>> "Secretariat"]):
>>>>>>>>> // do something that only area diretor, IAB chair, and 
>>>>>>>>> secretariat could 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.
>>>>>>>>>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 15 Sep 2015 17:39:07 -0500

> I thought the calls were on Tuesdays - when did that change?
Ignore that part - I see they've been mostly on Wednesdays for a long time.
Please forward the coordinates? (I don't know if I can make tomorrow, 
but if I can move a meeting I'll be there).

RjS

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 16 Sep 2015 01:54:32 +0000

Hi Robert,

Thank you, here is the call information for tomorrow:

JOIN WEBEX MEETING
https://isoc.webex.com/isoc/j.php?MTID=mcf3b8c886b81a58535ea02c3ba3ba940
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=MC&ED=322099332&tollFree=0

Best regards,
Kathleen 

Sent from my iPhone

> On Sep 15, 2015, at 6:39 PM, Robert Sparks <[email-masked]> wrote:
> 
> 
> 
> Please forward the coordinates? (I don't know if I can make tomorrow, but if I can move a meeting I'll be there).
> 
> RjS

---

From: Christian O'Flaherty <[email-masked]>
Date: Wed, 16 Sep 2015 10:18:11 -0300

Hi Robert,  can you join the call?

I wasn’t in Hawaii so I may have missed some discussions. Making it independent will probably simplify many things and will let us put it online faster. 

Anyway, we would like to be "Datatracker complaint” to simplify the integration in the future.

> On Sep 15, 2015, at 10:54 PM, Moriarty, Kathleen <[email-masked]> wrote:
> 
> Hi Robert,
>

---

From: Nicolás <[email-masked]>
Date: Wed, 16 Sep 2015 10:23:00 -0300

Sorry, I cannot attend the call today because full of work.

I look forward to see the recording in the aft*.

Best regards,

Nico.

El 16/09/15 a las 10:18, Christian O'Flaherty escibió:
> I wasn’t in Hawaii so I may have missed some discussions. Making it 
> independent will probably simplify many things and will let us put it 
> online faster.
>
>> On Sep 15, 2015, at 10:54 PM, Moriarty, Kathleen 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Robert,
>>
>>> Please forward the coordinates? (I don't know if I can make 
>>> tomorrow, but if I can move a meeting I'll be there).
>>>
>>> RjS

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 16 Sep 2015 20:10:47 +0200

Hi Christian,

Working through my inbox:

> Can you help us or join our call tomorrow at 16 UTC ?

Umm.  The email above landed in my inbox "today" at 6 minutes past midnight.

I don't know which "tomorrow" you refer to -- a date would be easier.  If
the tomorrow you were thinking of were today, then it's obviously too late.

Possibly Robert made it?

Sorry,

	Henrik

---

From: Christian O'Flaherty <[email-masked]>
Date: Wed, 16 Sep 2015 15:20:32 -0300

> the tomorrow you were thinking of were today, then it's obviously too late.

Yes, he made it and it was very helpful. 

I’m learning about using multiple databases with a read-only access to Datatracker. 
Some questions coming soon :-)

Christian

---

From: Robert Sparks <[email-masked]>
Date: Wed, 16 Sep 2015 13:21:27 -0500

> the tomorrow you were thinking of were today, then it's obviously too late.
I did - I'll find you on IM and talk through the call.
Kathleen also recorded it I believe.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 16 Sep 2015 20:21:58 +0200

Hi Christian,

> Some questions coming soon :-)

Aha.  Splendid.

Best regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 16 Sep 2015 20:22:44 +0200

> I did - I'll find you on IM and talk through the call.

Ok, good.  Ttys.

	Henrik

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 16 Sep 2015 14:31:22 -0400

Hello,

Yes, the call was recorded and ISOC can provide the link as they
provide the Webex access for us.

Thank you,
Kathleen

-- 

Best regards,
Kathleen