Potential Approaches for InformaCam Server Secure API¶

Fedora Repository¶

Fedora Repository is a middleware application provides:

• object oriented media storage management
• REST/SOAP APIs
• search utility
• replication
• disaster recovery utility
• malleable storage options (database and file)
• authorization via XACML standard

The XACML authorization is managed through Sun's Java classes that understand XACML. In summary, the XACML is an XML-based syntax, in which you write access/authorization policies and a requests to resources governed by these policies. When a request is made, the Java libraries read the request, refer to any written policies as the means to evaluate access rights to the requested resource. Sun's explanation can be found here: http://sunxacml.sourceforge.net/guide.html

Fedora's use of XACML assumes that authorization schema will be combined with some form of identity management that is enterprise in focus (e.g., Shibboleth, LDAP); and its default policy is 'public'. [still need deeper research to determine how this is applied to the API requests]

Notes:
benefits: not operating dependent. allows cross-operability between systems
similar to SELinix but abstracts it beyond OS

Global Leaks¶

GLobal Leaks's project plan is moving its project towards a RESTful approach. However, from the documentation that is available, authorization does not appear to have been tackled yet in its API development. In addition, from the documentation available Global Leaks does not appear to be focused on creating a verifiable chain of custody, or encryption of requests/submissions. It would be worthwhile to have a conversation with Global Leaks developers, to find commonalities. But at this time, it does appear to still be too early in its development to be of relevance to InformaCam at the moment.

HMAC Roll-Our-Own¶

This would be similar to the Amazon Web services API approach.
1. requester combines all data into blob
2. Hash blob with private key know to server and client
3. send public key with blob + timestamp
4. receiver verifies time frame of request
5. look up public key to verify 'requestor' is registered
6. if both check out move forward with request
7. checksum blob with recreated blob using private key
8. if all good return requested data (and depending on level, requester then becomes receiver in a process for returned data)

Notes:
- need to flesh out the "Hash blob with private key know to server and client". Need to include an authorization key that is created and thrown out for each request.
- too heavy for large scale system?

OAuth¶

This standard is quickly becoming "the" method for authorizing API requests. Seems really similar to rolling our own, but more specified. In addition, the focus is on securing the signature/requestor, but the request parameters itself are left unencoded, so would need to add custom encryption to the passed data on top of using this protocol [need to deeper research to determine if encrypted passed params are not also allowed]

- notes; OAuth can do the authentication. Data sent needs to be dealt with another way.
- Probably best way to manage API clients that we don't fully control
-

SE Linux¶

[research; how would SE Linux affect Fedora/other approaches?]
- could be used to create policies around specific applications
- e.g., set policy for how couchdb access is allowed on the complete os level
-