Securing APIs

Control data access by configuring security in API Creator.
lac42
You can control data access down to the row and column-instance level by configuring security in API Creator.
In this article:
 
 
2
 
 
Watch the Video
The following 
CA Live API Creator
 Security video describes the concepts and operation for declarative security:
  • Admin versus application security
    .
  • Authentication providers
    . The 
    built-in authentication
     authentication provider and defining custom authentication providers.
  • Roles
    . Access and table permissions for row/column security.
  • Globals
    . Per-user parameterization for row filter.
For more information about this video and other videos for 
CA Live API Creator
, see Videos.
Security Levels
You can secure access to your API using:
  • Authentication.
     Authentication defines 
    admin security
    . Authentication controls access to 
    CA Live API Creator
     to define APIs, databases, security, and logic. It is authentication with root privilege to 
    CA Live API Creator
     (for example, the 
    admin
     user). Admin security controls who can access API Creator.
    If the default TeamSpace is the only TeamSpace that exists, and you are the initial TeamSpace user, your user name is 
    admin
    . This user can alter logic, can define security, and can access Data Explorer in Author Mode.
    For more information about authentication, see Configure Authentication.
  • Authorization.
     Authorization defines 
    application security
    . Authorization controls who can access the API (the data, such as by API Creator) and what the API user is authorized to do. Application security operates by way of role-based endpoint access.
    For more information about authorization, see Authorization and Role-Based Endpoint Access.
Communications Security
Your API can use authentication tokens directly. It can obtain the authentication token automatically using HTTP basic authentication.
For more information about how to enable HTTP basic authentication for your API, see Obtain and Use Authentication Tokens.
Security Workflow
The following image shows the security workflow:
  LAC_Security.png  
The following workflow provides an overview of security:
  1. API owners/administrators define role permissions and custom authentication providers in API Creator. API Server stores the authentication providers in the admin repository.
  2. Applications obtain an authentication token by posting credentials (username and password) to the 
    @authentication
     resource endpoint. An authentication token typically represents an authorized user and defines the set of roles to which the API user is authorized.
    For more information:
  3. API Server passes the credentials to the custom authentication provider. The custom authentication provider obtains of set of authorized roles for the API user by authenticating to external providers such as StormPath, Lightweight Directory Access Protocol (LDAP), Active Directory (AD), OAuth, a SQL database, or any other third-party authentication mechanism.
    For more information:
  4. API Server creates an authentication token containing the roles and globals and stores these in the authentication token database. This authentication token is available to all API Server nodes in a cluster.
    For more information about the authentication token database, see Create a Database for your Authentication Tokens.
  5. API Server returns the authentication token ID to the client, who passes it in the header of subsequent requests; the API Server uses it to enforce role permissions.
Security Best Practices
We recommend the following security best practices when you are designing your APIs in 
CA Live API Creator
:
 1 incomplete Consider securing incoming requests against potential security threats (for example, DoS) and configuring request rate limit and throttling using CA API Gateway.  2 incomplete Review the security configuration of all your endpoints for all defined roles before deploying your APIs to the next environment within your CI/CD process. 9 incomplete Review the following security settings for your API:
  • HTTPS only
    : By default, API users can call your API using HTTP and HTTPS. If your data is confidential, consider requiring API user to use encryption when calling your API by clearing this checkbox.
  • Permit Authorization parameter in URL
    : By default, API users can specify their authentication token in the URL using a format such as:
    ...&auth=123456789:1
    Consider clearing this checkbox. Permitting API users to specify their authentication token in the URL has security implications. Browsers can remember URLs and URLs are typically logged in servers and routers. 
  • Allow Swagger without authentication
    : By default, API users must be authenticated to discover the API Swagger doc. If the API users that are retrieving the Swagger schema do not support authentication, consider allowing API users to retrieve the Swagger schema without authentication by removing this default setting.
    You can remove this default setting temporarily, to connect your API to a Swagger consumer, and then keep this setting after the consumer retrieves the API.
  • Disallow free-form filters and sorts
    : By default API users can access your data using regular filters and sorts (regular filters and sorts are turned on and allowed). To minimize the possibility of SQL injections, consider disallowing API users from using regular filters and sorts and require that requests to your data use named filters and sort by selecting this checkbox.
  • Enable HTTP Basic Authentication
    : By default, your API can generate authentication tokens. Consider keeping this default setting only if you are using Secure Sockets Layer (SSL)/Transport Layer Security (TLS).
For more information about these security settings, see API Properties.
10 incomplete (If you are running on Apache Tomcat) Consider minimizing the security vulnerabilities on 
CA Live API Creator
 applications, such as API Creator and Data Explorer, which are web-based applications, by adding security headers to Tomcat. HTTP security headers give browsers explicit instructions about how to communicate with a website.
For more information:
For a list of all best practices, see Best Practices.
Service Connectivity
Your authentication provider provides service connectivity. For further control, you can deploy services within a private cloud using API Creator.
For more information about how to install 
CA Live API Creator
 to run as a cloud-based service, see Installing and Upgrading.
Cross Origin Resource Sharing (CORS) Enforces Unauthorized Access
To prevent a malicious site from accessing servers open on other tabs (for example, your bank), JavaScript code can access only the site from which it was loaded, unless authorized. The Cross-Origin Resource Sharing (CORS) mechanism enforces this restriction. You can protect your data from unauthorized access by creating an HTTP Options event handler for your API.
For more information:
Database Connection Security
API Creator requires access to your database. 
CA Live API Creator
 uses industry standards to protect your information with encryption and salting. The following are the common database-location scenarios:
  • Cloud database. 
    It is a common practice to deploy databases in the cloud, for automated maintenance and administration. To minimize latency, select a 
    CA Live API Creator
     service on the same cloud provider and region as your database. If your organization requires advanced security, provide API Server in your private cloud.
  • On-premises database.
     Where services are required for a database that is already deployed behind your firewall, contact your network administrator to authorize 
    CA Live API Creator
     access to your database. The basic approach is to open a port in your firewall for your database. For on-premise databases, the public cloud IP address of your API Server is required.
If your organization has rigid security requirements, configure an on-premises API Server. This generally does not include elastic support to dynamically add servers.