Context Navigation

← Previous Ticket
Next Ticket →

#806 closed enhancement (fixed)

Authenticated Invenio API

Reported by:	skaplun	Owned by:	egarciag
Priority:	major	Milestone:
Component:	WebStyle	Version:
Keywords:	http api key REST batchupload drupal	Cc:

Description

Our Indico colleagues recently added support for signed API usage, based on:

http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.html

Our Indico friends implemented it in this way:
http://indico-software.org/repo/indico/tree/doc/guides/ExportAPI/access.rst?h=v0.98-series

and we might therefore follow the same principles in order to have client code developers to reuse their code.

Note that this idea has already a first use case in the form of a Drupal module to push records to Invenio

Change History (6)

comment:1 Changed 20 months ago by skaplun

Owner set to egarciag
Status changed from new to assigned

comment:2 Changed 20 months ago by skaplun

Possible table structure to have would be:

key -- to actually store the existing keys
- id varchar (primary key)
- secret varchar
- id_user int (foreign key to user table)
- status varchar (to say e.g. OK or WARNING or REVOKED, see below)
- description varchar (free text for the user to remember why he has those key... say: Drupal photos or something else)
key_log -- to log the activities related to a certain key
- id_key varchar (foreign key to key table)
- usage_time datetime (timestamp of when the key has been used)
- url varchar the URL of the API involved in the key part
- query blob a marshaled version of the arguments (without actually the signature and the key)

This task actually affects also the WebSession module.

As part of this task, the /youraccount/edit interface should be extended to allow a user to request for a new couple of system generated key and secret. They user might have as many key/secret as he needs and should be able to provide a sensible description in order to distinguish them.

An admin interface should be used in order to monitor key usage WRT certain configurable policies. Keys that are used without respecting a policy can be revoked by this interface.

An example of policy might be that a certain API can be used only with a maximum frequency. Rules might be built taking into consideration roles, so that we can say e.g. the search API can be queried every 0.5 seconds by users in the role searchmasters.

A BibTask(let) can be introduced that will periodically scan the key_log table and rank key usage and match it against policies. This task would send warning emails and e.g. store in the status column of the key table a progressive WARNING level (e.g. WARNING1, WARNING2, WARNING3) so that the admin can immediately see which users are actually abusing the service.

The actual authentication phase, based on API keys would happen at the level of the webinterface_handler module, and a valid usage of a key and signature would result in correctly set the current user uid to the owner of the key.