RFC 0001: Authorization APIs (and JWT) for CKAN

[rufuspollock]

Zoom Meeting Video: https://drive.google.com/drive/folders/1lhwHnAw7p7DmT_hTzC-2OK-RbnRXjY4n?usp=sharing

tl;dr

• Having APIs for Authorization would be really useful
  • /api/3/action/is_authorized?object=dataset/abc&action=update&userid=XXX => True/False
  • Why? Because it makes it possible to build separate web apps/services that can incorporate authorization information. E.g. a decoupled (read) frontend or Admin UI.
• Even better these would be for CKAN to get full JWT support and issue tokens so as to improve security and performance, and so that CKAN can evolve to a more componentized architecture
  • /api/3/action/authorize?scopes=... => token
  • See below for more on token based approach
  • Why is a more componentized/decoupled architecture good? that's a broader discussion (see below)
• At Datopian we have just built an extension to do this https://github.com/datopian/ckanext-authz-service

Working implementation

https://github.com/datopian/ckanext-authz-service

Overview

• Definitions: auth(entication) and (authz)orization - see http://tech.datopian.com/permissions/
  • Authentication has 3 parts

Introduction to JWT and tokens (or What's the problem with API Keys?)

• API keys are unscoped: they have full power for that given user ... => scoped API Keys / tokens ...
• ...

Service A, Service B, Permissions Service "P|

graph LR

Client --want to do X, apikey--> A[service A]
A --check api key, permission--> P[Permissions Service]

Client --want to do X, apikey--> B[service B]
B --check api key, permission--> P

Loading

Every action on every service is going to hit Service P

Also any compromise in any service compromises your API key! Which is universal, full power token!! (b/c i send my api key to every service ...)

A token setup is INVERSION of CONTROL ...

graph LR

Client --permission request for service A--> P[Permissions Service]
P --token for A--> Client

Client --token--> A[Service A]

Client --permission request for service B--> P[Permissions Service]
P --token for B--> Client
Client --token--> B[Service B]

Loading

If i compromise your token for A i have only that ... (scoping)

Also one request to service P and then i can do lots of requests on A ... => high performance, no latency ...

Qu: how does service A know the token is valid? Because P signs it with its public key ...

Use Case

Frontend

When building a decoupled read frontend I want to display edit buttons (or other permissions based UI) to users based on their permissions so that they have a great experience

Cloud Storage

Storage access with a microservice "Storage Access Granter"

sequenceDiagram
  participant browser as Browser/Script
  participant Authz as CKAN Authz Ext
  participant giftless as Storage Access Granter
  participant storage as Cloud Storage

  browser->>browser: Select files to upload
  browser->>Authz: authorize(scopes, API Key)
  Authz->>Authz: check authorization in logic layer
  Authz->>browser: JWT token
  
  browser->>giftless: request_storage_access(fileinfo, JWT)
  giftless->>browser: signed upload URLs
  
  browser->>storage: Upload file1.csv
  storage->>browser: File OK

Loading

How it works internally

TODO

  sequenceDiagram
  
  participant client as Client
  participant authorize as authorize()
  participant scopes as Scopes
  participant authziie as Authziie

Loading

FAQs

How does this relate to Sergey's work in ckan/ckan#5146

Sergey's work is somewhat related and somewhat orthogonal. It is primarily about

• Making API keys time limited

Bonus

• Being able to invalidate or rate limit these tokens