1. Security
  2. Security Considerations for Developers

Security Considerations for Developers

OpenAir API integrations and OpenAir scripts must be designed with the security requirements of cloud computing and OpenAir platform best practice guidelines in mind.

Before you start leveraging the XML API, SOAP API (Web Services), REST API, or User Scripting platform tools:

You should work with OpenAir Professional Services to design API integration and platform solutions. The knowledge you gain about how tables and data fields are used in your business processes will save development time and help you optimize your integration and platform solutions on an ongoing basis.

Important:

Develop and test your API integration or scripts in a sandbox account. It is crucial that you use a non-production environment until you can be sure that the integration or script runs smoothly without error and does not corrupt vital production data.

This chapter contains considerations for developers using OpenAir as a platform to develop integration applications or to deploy scripts customizing OpenAir functionality. This chapter includes the following sections:

Limitations

OpenAir enforces some limitations on platform tools usage to ensure the security and stability of OpenAir:

  • For API integrations, there are limits on the number of records and objects any method can accept or return and frequency limits of transactions allowed within a 24–hour or a 60–second interval.

  • For user scripting:

    • There are limits on the amount of time scripts can run for, or the amount of Web Services API time they can use, as well as the number of functions a script can call, based on a governance unit system.

    • There are limits on the number of emails a script can send, the number of log entries a script can record.

    • The number of redirects as well as the response time and size are limited for outbound calls.

    • The Web Services API limits apply when accessing the API using built-in user scripting functions.

    • User scripting is prevented from accessing DOM methods, the file system, and sockets.

Connecting to the API

When access to the API is granted, you will receive an API namespace and an API key. These are the two pieces of information required for API access in addition to your regular OpenAir sign-in credentials. The namespace and key attributes are used to verify that the request is coming from a valid partner that has permission to use our API. You will not be able to access an account with only the namespace and the key. The user credentials including Company ID, User ID, and Password are also required to initiate a session and send request calls to the API.

Connection must be made over a secure layer using the HTTPS protocol. Ensure connections from any integration tools have supported cipher suites enabled. See TLS Protocol and Cipher Suites.

Roles and Permissions

A secure enterprise application should allow its users to accomplish their tasks using the least possible access to data and lowest possible privileges to perform system tasks. In OpenAir, this is done using a set of access control mechanisms including roles, permissions and filter sets. See Configuring and Using Access Control.

These access control mechanisms grant OpenAir users permissions to the records and privileges they need to perform their work, but restrict access to other records and privileges that are not required for their jobs. As a developer, you should rely on and reuse these access control mechanisms where applicable.

By default, form scripts are executed within the context of the user who is signed in. Therefore, you need to make sure your script can run correctly for any user that may trigger the script:

  • When deploying a script, you must select a user to execute the script deployment. This user acts as a proxy, and is needed when the signed in user’s access permissions are too restrictive for the script to run successfully. You can create a dedicated user with minimum possible privileges and gradually add only those permissions required to execute the script successfully. This approach adheres to the security principle of enabling users to perform their tasks using the least possible level of access and privileges.

    Note:

    Form scripts are explicitly prevented from being deployed to be executed as Administrators. Make sure you test your scripts as the user selected to execute the script and not as an administrator.

  • The user filter sets will be applied unless disabled. If script support for web service API methods is enabled on your account, you can use the NSOA.wsapi.disableFilterSet( [ flag] ) function to enable or disable user filter sets.

The access control model for integration applications (applications that use the XML API or SOAP / Web services API) are also based on the role and filter sets assigned to the authenticated user. You will typically authenticate as an administrator when developing an integration application. The administrator role is convenient because it gives full permissions to access all records and to perform all tasks – something that is vital during development. However, the best practice is to rely on OpenAir’s role-based access control model when developing your API integration. When user privileges are too restrictive or too loose, you should create a dedicated user with role permissions and filter sets that are tailored to the specific access requirements of your integration application. The design principles for dedicated users and custom roles should be driven by the following considerations:

  • What tasks do the users need to do by using the integration application?

  • What is the lowest role level they can have to access data?

  • What is the least amount of privileges needed to perform system tasks?

Note:

An exception to the security best practice of using a non-administrator role is if your integration application needs to perform tasks that can only be accomplished with administrator privileges.

Validate Data Input

Sanitize all data inputs in your integration applications to avoid data integrity issues or security breaches. Data sanitation includes checking data type, length, ranges, and expected choices. A request must have all of its data sanitized before it is permitted to be processed.

Programmatic Access to OpenAir Passwords

OpenAir sign-in passwords for existing users cannot be accessed through the browser interface, scripts or APIs. Applications should not be designed based on the assumption that user passwords can be programmatically obtained.

On the Employee record, the password field can be set using APIs only during create and update.

For integration applications, sign-in must be done by prompting the user for passwords either during initial configuration or each time the application is invoked. OpenAir user passwords must be hashed if stored outside of OpenAir for the benefit of easier authentications.

OpenAir supports the OAuth 2.0 authorization code grant type. You can eliminate the need to store OpenAir user sign-in details outside of OpenAir or to prompt users for credentials.

OAuth 2.0 Authorization Code

OpenAir supports OAuth 2.0, a robust authorization framework. This authorization framework enables client applications to use a token to access OpenAir through the XML API, SOAP API, or REST API. The application accesses the protected resources on behalf of a user who gave an explicit permission for the access. This method eliminates the need for API integrations to store user credentials.

The OAuth 2.0 authorization code grant type eliminates the need to collect or to store OpenAir user sign-in details in your applications.

For more information, see:

Note:

OpenAir only supports the OAuth 2.0 authorization code grant type. The REST API supports OAuth 2.0 exclusively for authorization and authentication.

External System Tokens, Passwords and User Credentials

Tokens, passwords and user credentials for external systems should not be stored in OpenAir in an unencrypted format.

You may create password script parameters to store tokens, passwords and user credentials in an encrypted format. The value is hidden both on the form used to set the parameter value and in the parameters list view. You can use the NSOA.context.getParameter(name) function to read the values for specified password parameters in your outbound calling scripts. Only HTTPS URLs are supported for outbound calls to ensure end-to-end secure connections to external systems.

Similarly you may use password custom fields to store tokens, passwords and user credentials in an encrypted format, then use a read request to read the values of these custom fields in your integration applications.

Credit Card Information

Credit card information must never be stored in OpenAir.