T
tcallen@dmsi.com
Guest
There are a number of API methods that non-admin API users are prohibited from using because they lack administrator level access to Rollbase. This security model is too broad. I believe employing an API "key" methodology will greatly benefit customers looking to properly integrate with non-Rollbase systems while maintaining security. In our tenant we have a need to completely lock down a handful of objects that contain sensitive data in which API access should be blocked. All of our other objects should be able to be accessed via API calls and use those restricted methods (as I believe even Progress' DataDirect product uses and requires admin role access which is a huge security risk). To get around this limitation, I am proposing a Google-like API key methodology where each object can generate its own unique API key (upon request by a system administrator). That key can then be used in AJAX/SOAP/REST calls and the API key would be an optional parameter. For example, the getFieldDef() method would now take the following parameters: getFieldDef(string sessionId, string objDefName, string fieldDefName, string apiKey ); The API key can be built by any means Progress feels necessary (128-bit, 256-bit, AES, whatever), but this key would then be given to an API programmer (or plugged into a tool like DataDirect) that gives a non-admin API user admin-level rights to that specific object only. To revoke the API access, the API key on the object can be cleared out or simply generate an entirely new key. This will ensure data on a select number of objects can be fully accessed without assigning the API user to the Administrator role.
Continue reading...
Continue reading...