Allow the Data Deposit API to use API keys

[raprasad]

---

Author Name: Philip Durbin (@pdurbin)
Original Redmine Issue: 3208, https://redmine.hmdc.harvard.edu/issues/3208
Original Date: 2013-08-01

---

v1 of the Data Deposit API requires that passwords be sent by a SWORD client. Use of HTTPS ensures the passwords are encrypted "in flight" between the SWORD client and the server but it means that the SWORD client must have access to the actual password (and presumably store the password in clear text or using reversible encryption so that the actual password can be sent).

Better would be to use API keys, which is what Twitter, Google, Flickr, etc. allow. Commonly, OAuth is used to negotiate API keys: http://en.wikipedia.org/wiki/OAuth

From a SWORDv2 perspective, at http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#authenticationmediateddeposit the spec says the following:

1. Authentication and Mediated Deposit

In [AtomPub] Section 14, implementations MUST support HTTP Basic Authentication in conjunction with a TLS connection. The SWORD Profile relaxes this requirement: SWORD client and server implementations SHOULD be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818].

In a number of situations the authenticated user using a SWORD client is not the owner of the deposited resource. SWORD provides a way of representing this usage by allowing clients to set a HTTP header field On-Behalf-Of which, if present SHOULD contain a user principle for the owner of the resource. It is also possible to use this SWORD mediation mechanism for situations such as non-interactive batch deposit in which the authenticated user is a software acting on behalf of a user.

The mediation technique described by SWORD is not intrinsically secure - it is assumed that trust between the owning user and the mediating user will be established by extending SWORD, or outside the scope of a resource creation, using a mechanism such as that described by [OAUTH].

---

Related issue(s): #459
Redmine related issue(s): 3108, 3874

---

[raprasad]

---

Original Redmine Comment
Author Name: Philip Durbin (@pdurbin)
Original Date: 2013-08-02T17:18:06Z

---

I asked about API keys on the SWORD mailing list in a thread called "[sword-app-tech] using API keys (OAuth?) rather than HTTP Basic Authentication (username/password) in conjunction with a TLS connection".

It seems like our approach of passing usernames and passwords (over HTTPS) rather than API keys is how all known SWORDv2 implementation operate.

Richard Jones, the SWORD spec lead, said...

Nope, no attempt to use OAuth with SWORD that I'm aware of. We toyed
with trying to do this as part of the protocol, and then decided that
it was Too Hard, might put people off implementing, and also ought to
be orthogonal to the task that sword is trying to carry out, so we
decided to leave it up to implementers to decide.

in his reply at http://www.mail-archive.com/sword-app-tech@lists.sourceforge.net/msg00340.html

Richard goes on to encourage SWORDv2 implementers to attempt trying to implement API keys (OAuth specifically) and to make sure there is nothing in the spec that seems to forbid it.

At http://irclog.perlgeek.de/crimsonfu/2013-08-01#i_7398673 "semiosis" suggested looking at the auth in Amazon's APIs:

16:45 semiosis pdurbin: good docs on how AWS does API auth here http://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html

16:49 semiosis in a nutshell... you have a public & a private key, you send the public key in the clear, along with a timestamp, and your message (commands, etc), then sign that whole thing with your private key & append the signature

16:49 semiosis google HMAC

16:49 crimsonfubot https://en.wikipedia.org/wiki/Hash-based_message_authentication_code

http://docs.aws.amazon.com/AmazonS3/latest/dev/S3_Authentication2.html and http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html have more detail about this HMAC approach.

[raprasad]

---

Original Redmine Comment
Author Name: Philip Durbin (@pdurbin)
Original Date: 2014-01-27T19:54:19Z

---

Eleni noticed a possible model for API keys in a SWORD context by way of https://twitter.com/archivematica/status/427873797124145152

• Check out the Sword API we're working on for integration with @Islandora https://www.archivematica.org/wiki/Sword_API
• @archivematica looks great! @JeffSpies can you play with their API keys and tell me if that's what you want for https://redmine.hmdc.harvard.edu/issues/3208 ?
• @philipdurbin @archivematica Looks like it. Ideally, the user could assign ind. keys to services and revoke at will.

Specifically, I'm noticing wording on that page such as 'Enter the dashboard's IP address into the "Remote name" field and the user and API key noted earlier into the "Api username" and "Api key" fields.'

Also, I noticed this in their example for a POST:

Authorization: Archivematica-API api_key="XXXXXXXXXXXXXXXXXXXX", username="timh"

Some food for thought anyway... we want to make sure we build the right thing.

[pdurbin]

Implemented and documented in 686d5b7. Passing to QA.

[esotiri]

Created dataset using token
`

Must, Olev; Must, Aasa, 2014, "���Changes in test-taking patterns over time��� concerning the Flynn Effect in Estonia", http://dx.doi.org/10.5072/FK2/23, Root Dataverse, DRAFT VERSION https://dataverse.example.com/dvn/api/data-deposit/v1.1/swordv2/edit/study/doi:10.5072/FK2/22 no treatment information available `

[esotiri]

resolving issue