2011.17: Define access restrictions for APIs
Author: Mike Joseph
Submitted On: 11 April 2011
The introduction of the new RESTful interface and API keys are a welcome step to the automation of ARIN’s database management. However, the current security model creates a particular complication. In order to use the RESTful API to automate something, it is now necessary to store that credential in a system that is most likely visible to more than just the person who the credential represents.
I therefore suggest that ARIN develop an ability to define access restrictions for each API generated. These restrictions should allow the registrant to specify exactly which RESTful (and therefore template) actions may be performed using the key (including separation of read and write access for each type of modification).
It should also be possible to limit the API key to performing actions on behalf of a specific POC, rather than all POCs to which the ARIN online account is linked. This would prevent the need for creating a number of “role” ARIN online accounts for the sole purpose of making a POC-specific API key.
Status: Open Updated: 10 April 2018
12 May 2011
The initial goal in moving to API Keys was to create a better security framework for ARIN’s provisioning system. As we investigate further improvements, we would like to take your suggestion of access control to the community for input. We will be gathering feedback from the community at large about preferences for the setup of simplified access control. It is our intent to schedule a focus time at the next ARIN meeting to discuss various approaches to this issue. The staff will then use that input as a basis for requirements to build access controls into API keys.
This suggestion will remain open until we determine the best course of action.
20 July 2011
During ARIN XXVIII in Philadelphia, there will be an ARIN Online Users Forum, during which this and several other ARIN Online-related suggestions. We encourage you to attend and participate. If you are unable to participate in person, we will also be offering remote participation and encourage you to participate remotely. Discussing ehancements with a larger audience will help us determine need and priority. This suggestion will remain open until resolved.
09 April 2012
Staff has determined that it would cost approximately $1,458,000 in engineering efforts plus significant communcations work on current API documentation to implement. Adding access level restrictions to API functions will create code complexity and possible end user confusion.
10 April 2018
This suggestion is not on the 2018 Work Plan and will be considered as part of the Community Consultation on Open ACSPs in April 2018. This consultation will serve as one of the inputs to help determine which suggestions will be included ARIN’s 2019 Work Plan.