Securing APIs

Control data access by configuring security in API Creator.
You can control data access down to the row and column-instance level by configuring security in API Creator.
In this article:
Watch the Video
The following
Layer7 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
Layer7 Live API Creator
, see Videos.
Security Levels
You can secure access to your API using:
  • Authentication.
    Authentication defines
    admin security
    . Authentication controls access to
    Layer7 Live API Creator
    to define APIs, databases, security, and logic. It is authentication with root privilege to
    Layer7 Live API Creator
    (for example, the
    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
    . 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:
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
    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
Layer7 Live API Creator
  • Consider securing incoming requests against potential security threats (for example, DoS) and configuring request rate limit and throttling using CA API Gateway.
  • 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.
  • 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:
      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 connect your API to a Swagger consumer by temporarily removing this default setting, and then replace this setting after the consumer retrieves the API.
    • Disallow free-form filters and sorts:
      By default, API users cannot access your data using regular filters and sorts (regular filters and sorts are turned on and allowed). This checkbox is selected.
    • 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.
  • (If you are running on Apache Tomcat) Consider minimizing the security vulnerabilities on
    Layer7 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
Layer7 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 Options event for your API.
For more information:
Database Connection Security
API Creator requires access to your database.
Layer7 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
    Layer7 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
    Layer7 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.