ckan / ckan/ideas

CKAN dataset authentication to row level

Open
#258 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
39
Forks
1
PR merge metrics
No merged PRs in 30d

Description

I am thinking of creating authentication for users to view datasets up to the row level e.g. User A can view Table 1 for columns x and y; User B can view Table 1 for columns x.

As I am rather new to CKAN, I would like to check on the design thinking process but would first like to share the environment:

1. CKAN 2.8
2. Ubuntu 18.04 LTS
3. Following extensions installed: Datastore, Datapusher, Filestore, Dataproxy
I would want users to be able to view remote tables (via Dataproxy) and uploaded CSV files (via Datasotre, Datapusher, Filestore) up to row level based on their individual authentications determined by the admin of the organization they are added to.

Currently this is the design that I came up with but I would like to get some feedback:

**Changes in postgresql database**
add a new database which will store tables representing each user. Each user table will contain data on which resource it can view and what data columns (or vice versa, store each resource as as a table)

**To view**
Edit select statement to have changes depending on what user can see (based on the table with user’s access rights). This is in the Dataproxy project's code

**When user is assigned to an org**
Update table with user’s access rights to every row (by default no access to any unless admin dictates so?)

**To update access rights on admin side (front end)**
A page for admins to determine what users can view in an organization

Any feedback would be greatly appreciated, thanks!

Contributor guide

No contributing guide indexed for this repository

Research direction

The issue names CKAN 2.8 and the Datastore, Datapusher, Filestore, and Dataproxy extensions, but no files or tests. Start by reviewing the Dataproxy code and the listed extensions to understand how remote and uploaded resources are queried; done would require an agreed design for row- and column-level access, admin configuration, and organization membership changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
postgresql
Domain
authorization, backend, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.