Creating APIs‎ > ‎

Security

You can control data access down to the row and column-instance level by configuring security in API Creator.

Security includes:

  • Authentication. To control who is allowed to access the system.
  • Authorization. To control what rows and columns a user can see and change.

For more information:

  • About how to effectively use the security services, including how to use authentication and authorization and security concepts, see the Security Examples.
  • About viewing a video that illustrates managing rules and security, see the Welcome Tour for API Creator video and the video that describes the concepts and operation for declarative security on the Videos page.

Admin versus Application Security

Security operates at the following levels in Live API Creator:

Admin Security

Admin security is what controls access to Live API Creator to define APIs, databases, logic, security, etc. It is authentication with "root privilege" to the system (for example, admin account). Admin users can alter logic and define security. Admin security controls who can access the the API Creator and (therefore) can update the admin data. Admin users also have access to Data Explorer in Author Mode.

For more information:

Application Security

Application security defines who can access the API (the data, such as by API Creator) and what the user is authorized to do. Application users are distinct from Admin users. Application users do not have access to the definitions of security, resources, and logic.

If you are using the built-in authentication provider, you can define users and their roles in API Creator. The built-in authentication provider looks up users defined in API Creator. This authentication provider is most appropriate for development.

For more information about the built-in authentication provider, including how to use it, see Authentication.

Communications Security

API Creator provides options for https-based communications.

Security Workflow

The following image shows the security workflow:

The following workflow provides an overview of security:
  1. Owners/Administrators define role permissions and custom auth providers in API Server, which stores them in the admin database.
  2. Applications obtain an auth token by posting credentials to the @authentication endpoint. An auth token typically represents an authorized user and defines the set of roles to which the user is authorized.
    For more information about the roles assigned to the auth token, see Authorization.
  3. The API Server invokes the custom authentication provider. Your custom authentication provider is passed the credentials, such as the name and password, and obtains of set of authorized roles by looking it up in your available and configured identity provider, such as Lightweight Directory Access Protocol (LDAP), Active Directory (AD), or OAuth.
  4. API Server creates an auth token containing the roles and globals and stores these in the Admin database. The auth token is available to all API Server nodes in a cluster.
  5. The auth token ID is returned to the client, who passes it in the header of subsequent requests; the API Server uses it to enforce role permissions.

Service Connectivity

Your authentication provider provides service connectivity. For further control, you can deploy services within a private cloud using API Creator.

Cross Origin Resource Sharing (CORS)

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 specifically authorized. The CORS mechanism enforces this restriction. API Creator security protects itself against such attacks by providing an HTTP header. This header stipulates that calls from any JavaScript application (for example, another tab in your browser) are accepted.

For more information about CORS, see the CORS wiki page.

Database Connection Security

API Creator requires access to your database. Your information is protected by both encryption and salting, using industry standards.

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 an 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 already deployed behind your firewall, contact your network administrator to authorize access by API Creator. 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.

More Information

For more information, see: