Implementing Kenya National Health Terminology Service - User Management & Feature Enhancements

General
1

In our journey implementing the Kenya National Health Terminology Service (which is an instance of OCL), we identified a few buckets of work that can be a starting point for discussions here.

  • User management (Public/Anonymous User, Normal/Authenticated User, Curator User & Admin User)

  • Enhancement of OCL features to support the different users.

So far I have managed to capture my thoughts in these 3 draft documents that should serve as a reference point as we move forward with this work:

1 Like
2

Thanks @k-ngari for kicking off this discussion. Look forward to collaborating with you and the Kenya team to implement these new features in OCL, including an advanced user roles & permissions framework.

One question that came up is how can we start to support advanced roles and permissions in the API and potentially only introduce the user interface portion of roles/permissions in v3 of the TermBrowser (which is under active development). Once we have requirements better defined, let’s talk with the core team to plan out the sequencing.

3

Thanks @k-ngari for the post! I also wanted to share the document in which we are collaborating the early requirements, user stories, etc. This is open to comments and input from all!

A good next step might be to make sure that a good portion of our allowable actions are filled in with the tables near the bottom of the document below. We have divided them up into Org-level actions, Repo-level actions, and Server-level actions. We also have places to add potential role groups e.g. content writer vs. maintainer. We can do this early organization that should start to clarify what are some of our expectations for permissions and roles in OCL.

4

@k-ngari We discussed the account approval workflow on the OCL Architecture call this morning (see notes if interested). Here’s the key takeaways:

  • OCL works with Keycloak as a Single Sign-on (SSO) tool, which already has user account approval features. We recommend that Kenya sets this up for their KNHTS to get both this short term benefits and the long term benefits that come from OpenID. See below for the rationale of why we recommend this.

  • If you do use the Keycloak approach, here would be the proposed steps for KNHTS:

    1. Enable Keycloak on the KNHTS OCL instance, which @Sny will help to document the setup
    2. Make as many admin users as necessary who would be able to approve accounts

Rationale:

  • Django-auth (which KNHTS currently uses) is supported by OCL primarily for development and testing purposes. We do not recommend using django-auth in production except for simpler deployments that do not require user account and access management features that are common in modern applications.
  • OpenID compatible services, such as KeyCloak, provide a rich suite of features that are intended for production and enterprise-level use that django-auth does not support. Example features include: single sign on, user account approvals, social login, and an administrator user interface.
  • OCL does not plan to re-create OpenID functionality for the django-auth deployment configuration. OCL also does not plan to implement identity and access management features that are not covered by the OpenID protocol.
1 Like