search

JiscSD / archivematica

Free and open-source digital preservation system designed to maintain standards-based, long-term access to collections of digital objects.
http://www.archivematica.org
GNU Affero General Public License v3.0
0 stars 0 forks source link

Problem: change of API auth not described in Dashboard #9

Closed joel-simpson closed 7 years ago

joel-simpson commented 7 years ago

Archivematica v1.6 authenticates API calls using an ip whitelist (defined in Admin / rest API screen) as well as an API Key. A component calling the API must have it's ip address in the ip whitelist, AND it must provide a valid API key.

The use of an ip whitelist is problematic with container-based deployments where ip addresses are very dynamic.

In Sprint 3 this authentication approach was changed so that, in the current JiscRDSS version of Archivematica, a component calling the API must have it's ip address in the ip whitelist, OR it must provide a valid API key. This is an improvement for running Archivematica in AWS for Jisc, because it no longer matters that all ip addresses are not known in advance.

Issue: This change adds complexity to the Archivematica solution that is not reflected in the Dashboard UI. The Rest API screen still shows the whitelist but does not indicate it is optional.

At the very least, the GUI should be updated with text to explain that the ip whitelist is optional.

Alternatively, use of the ip whitelist could be removed altogether. Pros: This would remove some complexity in the code as well as configuration documentation / tasks for users. It would prevent a situation where the only security is ip whitelist is used inadvertently (e.g. failing to configure the calling component with an API key). It should not have any impact on existing users of AM v 1.6 when upgrading (given that the API key was introduced as mandatory anyway).
Cons: it may be possible that some existing users prefer the added security of using both the ip whitelist and the API key? Is that a reasonable security concern?

helenst commented 7 years ago

For a containerized setup I agree it makes sense not to have the whitelist. I think it would be a question of whether to remove the functionality or just make it optional (i.e. in terms of how we backport this to AM core).

IP auth's not reliable or secure on its own but I can see its value as an extra layer of protection (i.e. the 'ip AND api key' logic that exists in core) rather than a second means to authenticate ('ip OR api key' as is currently in the Jisc branch).

Perhaps the answer would be to make it an optional feature, with the IP whitelist providing an extra layer of security on top of the API key, but only if whitelist IPs have been entered. If no whitelist is set up, no IP checks are performed. (This does invert the meaning of no IPs having been entered, I don't know if that would be a problem).