Project

General

Profile

action #1279

API authentication (was iChain integration)

Added by ancorgs almost 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Immediate
Assignee:
Category:
-
Target version:
Start date:
2014-01-27
Due date:
% Done:

100%

Estimated time:
10.00 h
Difficulty:

Description

openID is not enough, we need a more general, browser-independent and iChain-independent way of authentication for API calls (I'm reusing the old iChain issue, since it was being used in fact to log the activity related with this subject).

History

#1 Updated by ancorgs almost 9 years ago

  • Priority changed from High to Immediate

#2 Updated by ancorgs almost 9 years ago

  • Target version set to Sprint 03

#3 Updated by ancorgs almost 9 years ago

  • Assignee set to ancorgs

#4 Updated by ancorgs almost 9 years ago

  • Status changed from New to In Progress

Since we need authentication for the workers even in iChain-free environments, researching about oAuth (1.0, 1.0a and 2.0) + Perl + Mojolicious.

#5 Updated by ancorgs almost 9 years ago

Evaluating alternatives to oAuth like api key + hmac. Looks like Mojolicious includes some low level support for generation hmac sums.

#6 Updated by ancorgs almost 9 years ago

I propose to use openID for user authentication through the web interface and an API Key with HMAC headers for API authorization. I spent the WHOLE MORNING writing a blog post draft explaining the 'what' and the 'why' http://etherpad.cloud.suse.de/p/fZz2qcvyvt

#7 Updated by ancorgs almost 9 years ago

  • Subject changed from iChain integration to API authentication (was iChain integration)
  • Description updated (diff)

#8 Updated by ancorgs almost 9 years ago

  • % Done changed from 0 to 50

New branch 'auth' created in the repository with a working (but WIP) user-based authentication and authorization system.

  • Tests are not adapted yet
  • script/client contains now an example implementation of HMAC authentication that needs to be extracted and generalized
  • A user with is_operator = true is needed in the web interface
  • An API key associated to such a user is needed if no browser (no browser==no openID).
  • TODO: CSRF should probably be removed from clients

If somebody with more Perl knowledge pulls and fix the clients (to read the key and secret from a config file and that kind of things), it would be highly appreciated.

#9 Updated by ancorgs almost 9 years ago

  • % Done changed from 50 to 60

CSRF is not used in combination with HMAC anymore (made no sense). Most tests fixed. Added a helper for simulating openID logins during tests (this last point took me 3 hours).

#10 Updated by ancorgs almost 9 years ago

Trying to implement a useful OpenQA::API::V1::Client module useful for implementing scripts and for tests. Still not working, so not commited.

#11 Updated by ancorgs almost 9 years ago

  • % Done changed from 60 to 70

Preliminary version of OpenQA::API::V1::Client finally committed. It needs more features are a full API redesign. I hope somebody can help with it.

#12 Updated by ancorgs almost 9 years ago

Added a preliminary UI for managing API keys, alongside other improvements in authentication.

#13 Updated by ancorgs almost 9 years ago

  • % Done changed from 70 to 80

Tests (and some improvements) for API key management's UI.

#14 Updated by ancorgs almost 9 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 80 to 100

Some tests added for API authorization. Branch merged into devel.

Also available in: Atom PDF