michaellaunay / alirpunkto

0 stars 0 forks source link

Adapt the way the roles of users are stored in the LDAP directory to the software platforms of the infrastructure #52

Closed SergioArbarviro closed 5 months ago

SergioArbarviro commented 8 months ago

The roles in the Cooperative are nested:

This information on the role of each user needs to be conveyed to the software platforms of the infrastructure.

Some applications, such as Drupal, provide a "role" function: for each role, a set of rights can be attributed by the local administrator of Drupal. Drupal hence needs to receive the data on the role of the user in the form of a variable containing all possible roles.

Other applications, such as NextCloud, provide a "group" function: each user can be allocated to one or several "Group(s)", but the system does not understand that, if a user is member of a "Group" with more rights (such as "Cooperator"), s/he also has the rights attached to the "Group" with fewer rights (such as "Member of the Community"). NextCloud needs to receive the data on the status of the user in the form of boolean variables, one for each of the "Groups" to which it can belong.

I hence propose that the LDAP directory contain:

The value of the "Role" variable can be changed to "Member of the Board" or to "Member of the Mediation and Arbitration Council" by the administrator of AlirPunkto.

When the user has quit the Cooperative:

michaellaunay commented 8 months ago

Thank you for outlining the nested roles within the AlirPunkto Cooperative. The proposed LDAP directory structure indeed requires careful consideration, especially in the context of integrating with various software platforms like Drupal and NextCloud.

Given the existing RFC specification for InetOrgPerson, which uses a group membership list, we need to decide whether to align with this approach or to adapt a different structure to cater to the specific needs of applications like NextCloud. The latter seems to require a non-hierarchical, flat group structure.

To proceed, I would appreciate your input on naming the variables (without spaces) and confirming the default states for the new attributes for the following categories:

OrdinaryMembers: For users who are ordinary members of the community.
    Default State: [State or Value]
    Suggested Variable Name: ordinary_member_status (Boolean)

Cooperators: For users who have completed the full identity registration process and are accepted as cooperators.
    Default State: [State or Value]
    Suggested Variable Name: cooperator_status (Boolean)

Additionally, for the enumerated Role variable, the values you proposed seem appropriate. However, I suggest naming this variable as UserRole for clarity. The default values for UserRole could be aligned as follows:

None: For users not part of the Cooperative.
OrdinaryMemberOfTheCommunity: Default for users registered via AlirPunkto.
Cooperator: For users who register as a Cooperator.
MemberOfTheBoard: Set by the AlirPunkto administrator.
MemberOfTheMediationAndArbitrationCouncil: Set by the AlirPunkto administrator.

It's important to consider how these roles and states will be managed and updated, especially when a user leaves the Cooperative or changes roles. We need a robust mechanism to update these attributes accurately.

Please confirm these suggestions or provide alternative names and default states for the new attributes. Your feedback will be crucial in implementing a system that works seamlessly across different platforms.

SergioArbarviro commented 8 months ago

Here are my suggestions regarding the names of variables and default values for the boolean variables:

IsOrdinaryMember: For users who are ordinary members of the community.
    Default State: TRUE (once they have registered to the AlirPunkto platform)
    Suggested Variable Name: is_ordinary_member (Boolean)

IsCooperator: For users who have completed the full identity registration process and are accepted as cooperators.
    Default State: TRUE (once they have registered to the AlirPunkto platform)
    Suggested Variable Name: is_cooperator (Boolean)

IsBoardMember: For users that were defined by the AlirPunkto administrator as being members of the Board
    Default State: FALSE
    Suggested Variable Name: is_board_member (Boolean)

IsMemberOfMediationArbitrationCouncil: For users that were defined by the AlirPunkto administrator as being members of the Mediation and Arbitration Council
    Default State: FALSE
    Suggested Variable Name: is_member_of_mediation_arbitration_council (Boolean)

Here are my suggestions regarding the names of possible values for the enumerated variable UserRole:

None: For users not yet part of the Community - or no longer part of the Community (but whose details are conserved during a Quarantine period to avoid immediate re-registering of a Cooperator who earned a bad reputation).
OrdinaryCommunityMember: Default for users registered via AlirPunkto.
Cooperator: For users who register as a Cooperator.
BoardMember: Set by the AlirPunkto administrator.
MemberOfMediationAndArbitrationCouncil: Set by the AlirPunkto administrator.
michaellaunay commented 8 months ago

Thank you for your detailed suggestions on the variable names and default values. This clarification greatly aids in aligning the LDAP group management with the specific requirements of the AlirPunkto platform.

In LDAP, group management is standardized primarily for static groups, meaning groups that don't automatically update when a member is removed, as per RFC LDAP 4519. Consequently, managing the addition and removal of members from a group must be handled manually. Dynamic groups vary depending on the LDAP directory, and in the case of OpenLDAP, the dynlist overlay is used to provide this functionality. However, as each implementation is dependent on the specific directory used, this is likely why applications like NextCloud do not readily accommodate dynamic groups.

Given this context, I will proceed with implementing your proposal, naming the variables with an initial lowercase letter followed by capital letters to separate words, in accordance with OpenLDAP naming conventions. I will define a specific ldif schema for AlirPunkto.

To summarize, the following changes will be implemented:

isOrdinaryMember (Boolean): TRUE by default once registered on AlirPunkto.
isCooperator (Boolean): Initially FALSE, set to TRUE upon full identity registration as a Cooperator.
isBoardMember (Boolean): Default to FALSE, set to TRUE by AlirPunkto administrator for Board members.
isMemberOfMediation_arbitration_council (Boolean): Default to FALSE, set to TRUE by AlirPunkto administrator for Mediation and Arbitration Council members.

For the UserRole enumerated variable, the values will be as follows:

None: For users not (or no longer) part of the Community.
OrdinaryCommunityMember: Default for users registered via AlirPunkto.
Cooperator: For users registered as Cooperators.
BoardMember: Set by the AlirPunkto administrator.
MemberOfMediationAndArbitrationCouncil: Set by the AlirPunkto administrator.

This approach should ensure that each application within the AlirPunkto infrastructure can correctly interpret and utilize the user roles and groups, providing a cohesive and functional user management system.

SergioArbarviro commented 5 months ago

The Issue is superseded by Issue #65