Axway API Gateway - NIAP CCEVS · 2018-04-28 · Support for high contrast and accessible use of colors 7 1 Installation 8 Target ... The following Axway products are the targets

C O M M O N C R I T E R I A G U I D E

Axway API GatewayVersion 7.4.1

31 January 2017

Copyright © 2017 Axway

All rights reserved.

This documentation describes the following Axway software:

Axway API Gateway 7.4.1

No part of this publication may be reproduced, transmitted, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without the prior written permission of the copyright owner, Axway.

This document, provided for informational purposes only, may be subject to significant modification. The descriptions and information in this document may not necessarily accurately represent or reflect the current or planned functions of this product. Axway may change this publication, the product described herein, or both. These changes will be incorporated in new versions of this document. Axway does not warrant that this document is error free.

Axway recognizes the rights of the holders of all trademarks used in its publications.

The documentation may provide hyperlinks to third-party web sites or access to third-party content. Links and access to these sites are provided for your convenience only. Axway does not control, endorse or guarantee content found in such sites. Axway is not responsible for any content, associated links, resources or services associated with a third-party site.

Axway shall not be liable for any loss or damage of any sort associated with your use of third-party content.

Contents

Preface 5

Common Criteria overview 5

Who should read this guide 5

Prerequisites 5

How to use this guide 6

Accessibility 7

Screen reader support 7

Support for high contrast and accessible use of colors 7

1 Installation 8

Target of evaluation (TOE) product components 8

Architecture 8

Installer formats 8

License 9

API Gateway installation 9

Apply service pack (SP) and patch in high availability mode 9

Run API Gateway in FIPS mode 10

Set the Entity Store Passphrase 10

Start API Gateway 11

Log in to API Gateway Manager 11

Policy Studio installation 11

Run Policy Studio in FIPS mode 11

Start Policy Studio 11

Service pack / patch installation 11

OpenSSL 12

2 Audit capabilities 13

Audit events 13

Turn audit events off and on 13

Protected local audit trail storage 15

Relationship between local storage and remote 16

External audit offload 16

Description of the offload algorithm 16

3 Security 17

Security architecture 17

Cryptography 17

Password policy 17

AxwayAPI Gateway 7.4.1 Common Criteria Guide 3

Enable the password policy 18

Required password policy metrics and configuration 18

Credential storage 19

Advisory banner 20

Enable the banner 20

Configure the banner 20

TLS configuration 21

TLS connection configuration 22

4 Access control 23

Policies 23

Filters included in evaluated configuration 24

Access control policy definition 28

Access control policy transmission 28

Policy engine rules 28

Object and subject attribute definition 29

Object attribute definition 29

Subject attribute definition 29

Consistent security attributes 29

Authentication 30

Administrator authentication 30

Service Users authentication 31

Management functions 31

Security Management 32

Management of Object Attributes 33

Reliable timestamps 33

5 Communications 34

Communication failures 34

Failure of communication on policy transmission 35

Replay detection 35

Sessions 35

Session establishment 35

Session locking 35

Session termination 35

Trusted paths and channels 36

Trusted paths 36

Trusted channels 36

Appendix A: Required audit events for common criteria 37

Audit event format 37

Audit event descriptions 37

Glossary 38


Preface

AxwayAPI Gateway is a comprehensive platform for managing, delivering, and securing APIs. s the secure features of APIs.

This guide describes the secure features of API Gateway and Policy Studio that conform to Common Criteria requirements.

Where applicable, the reader is directed to other documents for additional information.

Common Criteria overviewThe Common Criteria for Information Technology Security Evaluation, usually known as Common Criteria or CC, is an internationally-recognized standard (ISO/IEC 15408) used as the basis for independent evaluation of the security properties of an IT product.

Under the Common Criteria Recognition Arrangement (CCRA), members agree to recognize Common Criteria certificates that have been produced by any certificate authorizing participant, in accordance with the terms laid out in the CCRA. Currently, the CCRA is comprised of 22 member nations: Australia, Austria, Canada, the Czech Republic, Finland, France, Germany, Greece, Hungary, India, Israel, Italy, Japan, the Netherlands, New Zealand, Norway, the Republic of Singapore, Spain, Sweden, Turkey, the United Kingdom, and the United States. New members are expected to join in the near future.

A system can be considered to be CC compliant if it matches an evaluated and certified configuration. This implies various requirements concerning hardware and software, as well as requirements concerning the operating environment, users, and the ongoing operating procedures.

You can find further information on Common Criteria at http://www.commoncriteria.org.

Who should read this guideThe intended audience for this guide is security teams in charge of auditing the security of the product, global network engineers, and product administrators.

PrerequisitesThis guide assumes that API Gateway and Policy Studio have been correctly and installed as per the API Gateway Installation Guide.


Preface

How to use this guideThis guide should be used in conjunction with the other guides in the API Gateway documentation set.

Before you begin, review this guide thoroughly. The following is a brief description of the contents of each section:

l Installation on page 8 – Describes the API Gateway and Policy Studio target of evaluation components, architectures, installer formats, licenses, and general information on product, service pack, and patch installations.

l Audit capabilities on page 13 – Describes the various audit capabilities available in API Gateway.

l Security on page 17 – Provides information on the security architecture, certifications and other important security information used by Axway.

l Access control on page 23 Describes the various types of access control used by the API Gateway.

l Communications on page 34 Access control on page 23 Describes the various types of inbound, outbound, and internal communication channels used by the API Gateway.

l Required audit events for common criteria on page 37 - Describes the format of the required audit events.


Accessibility

Axway strives to create accessible products and documentation for users.

This documentation provides the following accessibility features:

l Screen reader support on page 7

l Support for high contrast and accessible use of colors on page 7

Screen reader support l Alternative text is provided for images whenever necessary.

l The PDF documents are tagged to provide a logical reading order.

Support for high contrast and accessible use of colors

l The documentation can be used in high-contrast mode.

l There is sufficient contrast between the text and the background color.

l The graphics have the right level of contrast and take into account the way color-blind people perceive colors.


1 Installation

This section describes the API Gateway and Policy StudioTOE components, architectures, installer formats, licenses, and general information on product, service pack, and patch installations.

Where possible, readers are pointed to documents that provide additional information.

Additional topics in this section:

l API Gateway installation on page 9

l Policy Studio installation on page 11

l Service pack / patch installation on page 11

Target of evaluation (TOE) product components

The following Axway products are the targets of evaluation for this document:

l API Gateway 7.4.1 SP2

l API Gateway Manager 7.4.1 SP2

l Admin Node Manager 7.4.1 SP2

l Policy Studio 7.4.1 SP2

ArchitectureAPI Gateway architecture information is available in the API Gateway Concepts Guide.

Installer formatsThe API Gateway installer has the following installation modes:

l GUI mode

l Unattended command-line mode

For more information, see the API Gateway Installation Guide.


1 Installation

LicenseYou must have a valid Axway API Gateway license and a Axway FIPS mode license file to run API Gateway in FIPS mode.

You can obtain license information from your Axway Account Manager.

API Gateway installationThis section provides guidelines to:

l Apply the service pack and patch in the evaluation configuration.

l Configure API Gateway for high availability mode while in the evaluation configuration.

l Run the togglefips --enable command.

l Run API Gateway.

l Run API Gateway in FIPS mode.

l References on how to set the Entity Store Passphrase.

l References on how to start API Gateway.

l References on how to log in to API Gateway.

Use this information to supplement the installation instructions for PolAPI Gateway are located in the API Gateway Installation Guide.

Note FIPS mode is the vendor's term to signify a mode of operation of the API Gateway that is initialized by running the togglefips command, this ensures:

l The OpenSSL FIPS Object Module is invoked for native crypto operations and non-FIPS compliant algorithms and cipher suites will be disabled.

Apply service pack (SP) and patch in high availability modeThis section describes how to configure API Gateway to operate in a high availability mode.

To configure API Gateway in high availability mode a two host and two instance domain is configured and setup after the product has been installed on two physically distinct hosts.

To configure the first host:

1. Run the managedomain script from the /win32/bin or /posix/bin of your API Gateway installation.

2. Register the host: Is this the first host (Admin Node Manager) in the domain [y]: y

3. Start the Node Manager.


1 Installation

4. Run managedomain.

5. Create the API Server instance for Server1.

6. Enter the host name.

7. Enter the selection from 1-2 [Server1]: 1

8. Start API Gateway using the startinstance script, for example: ./startinstance -n "Server1" -g "Group1".

To configure the second host:


2. Register the host: Is this the first host (Admin Node Manager) in the domain [y]: n

3. Enter Admin Node Manager host: [Enter hostname of the Server1]

4. Start the Node Manager.


6. Create the API Server instance for Server2.


8. Enter selection from 1-2 [Server1]: 2

9. Enter name: Server2

10. Select a host.

l admin_NM_host

l current_host


12. Enter the selection from 1-3 [192.168.0.43]: 2

13. Start API Gateway. Use the startinstance script, for example: ./startinstance -n "Server2" -g "Group1".

Note Refer to the Configure an API Gateway domain section of the API Gateway Administrator Guide for detailed instructions on configuring your topology.

Run API Gateway in FIPS modeTo run API Gateway in FIPS mode, you must install API Gateway with a FIPS mode license. You can obtain the required license from your Axway Account Manager. For more information on FIPS and running API Gateway in FIPS mode, as well as on managing FIPS security, see the API Gateway Security Guide and the API Gateway Administrator Guide.

Set the Entity Store PassphraseFor detailed information, refer to section Start and stop the API Gateway, Set passphrases in the API Gateway Administrator Guide.


1 Installation

Start API GatewayThe instructions on how to configure API Gateway for first use and how to start and stop API Gateway are available in the API Gateway Installation Guide and the API Gateway Administrator Guide.

Log in to API Gateway ManagerFor API Gateway Manager login instructions, see the API Gateway Administrator Guide.

Policy Studio installationThis section provides guidelines to:

l References on how to run Policy Studio in FIPS mode.

l References on how to start Policy Studio.

Use this information to supplement the installation instructions for Policy Studio are located in the API Gateway Installation Guide.

Run Policy Studio in FIPS modeTo run Policy Studio in FIPS mode, you must install API Gateway and Policy Studio with a FIPS mode license. You can obtain the required license from your Axway Account Manager. For more information on FIPS and running the product in FIPS mode, as well as on managing FIPS security, see the API Gateway Security Guide and the API Gateway Administrator Guide.

Start Policy StudioThe instructions on how to start Policy Studio are available in the API Gateway Installation Guide and the API Gateway Administrator Guide.

Service pack / patch installationUse this information to supplement the general installation instructions for installing services packs and patches for API Gateway in the API Gateway Installation Guide.

Note API Gateway 7.4.1 SP2 must be installed.


1 Installation

OpenSSLThe current version of this product (7.4.1) is Federal Information Processing Standards (FIPS) 140-2 compliant when running in FIPS mode on the following platforms:

l Windows 2012 R2

l RHEL 6.x

When operating in FIPS mode, the following FIPS-certified cryptographic modules are enabled and invoked for all FIPS mode cryptographic algorithms:

Cryptographic module FIPS 140-2 certificate number

OpenSSL FIPS Object Module l AES: 4127

l RSA: 2237

l ECDSA: 945

l SHA: 3396

l DRBG: 1247

l HMAC: 2700

l Component Test: 936

Information about OpenSSL can be found in the following guides:

l API Gateway Installation Guide

l API Gateway Administrator Guide

l API Gateway Security Guide

l API Gateway Policy Developer Guide


2 Audit capabilities

This section describes the various auditing capabilities available in API Gateway. For example, you can use the API Gateway Manager web console to view and search API Gateway log and event files. Log and events can be configured in Policy Studio. You can also configure log settings at runtime from API Gateway Manager.

Topics in this section include:

l Audit events on page 13

l Protected local audit trail storage on page 15

l External audit offload on page 16

Audit eventsAPI Gateway contains the following security related audit events and capabilities:

l When the API Gateway is operating in an evaluated configuration, it can audit data on the local and a remote file system.

l Local and remote audit files can be protected from unauthorized deletion with ACLs.

l The audit files can be regularly offloaded to a HTTPS-enabled audit server. This ensures synchronicity between the local and remote logs.

l The location of the remote audit server can be configured in API Gateway Manager. All changes to the audit server configuration are audited.

l In evaluated configuration, the API Gateway logs audit events to a text file on both the local and remote file system.

For the offload scheduling algorithm, see External audit offload on page 16.

For details on the audit event required by common criteria, see Required audit events for common criteria on page 37.

For more information on configuring logging and alerting in API Gateway, refer to the section Configure events displayed in domain audit logs in the API Gateway Administrator Guide .

Turn audit events off and onIn evaluated configuration, the following events are enabled from the Settings - > Domain Audit Events page in API Gateway Manager:

Communication Events



l Node Manager Client Connection

l Node Manager Connection Failed

l Gateway instance client connection

l Gateway instance connection failed

Configuration Events

l Configuration replication started

l Configuration replication completed

l Configuration deployment started

l Configuration deployment error

l Configuration deployment completed

l Policy created

l Policy updated

l Policy deleted

l Policy transmitted

l Policy received

l Configuration Advisory Banner Update

Service Events

l Audit Event Configuration Updated

l Audit log files off-loaded

l Audit external location settings updated

l Connection to remote audit log server established

l Connection to remote audit log server failed

Session Events

l TLS session established

l HTTPS session established

l TLS session establishment failed

l HTTPS session establishment failed

l Session establishment denied

l Session terminated

User events

l User created

l User updated

l User password updated

l User password reset request

l User password reset



l User disabled

l User deleted

l User logged in

l User logged out

l Admin User logged in

l Admin user password reset

l Admin user logged out

User Store events

l Administrator user created

l Administrator user updated

l Administrator user password updated

l Administrator user removed

l Administrator user role removed

l Password policy created

l Password policy updated

l Password policy deleted

l Authentication threshold breached

l Authentication threshold reset

For instructions on how to configure and enable audit events, srefer to the section Configure events displayed in domain audit logs in the API Gateway Administrator Guide .

Protected local audit trail storageOne of the most important features of a server-based product is its ability to maintain highly detailed and configurable logging. It is crucial that a record of each and every transaction is kept, and that these records can easily be queried by an administrator to carry out detailed transaction analysis. In recognition of this requirement, API Gateway provides detailed logging to a number of possible locations.

You can configure API Gateway to log information about all requests, including:

l The request

l The time of the request

l Where the request was routed

l The response (returned to the client)

In the evaluated configuration, the logging information is written to a local log file.

For more information, see the API Gateway Administrator Guide.



Relationship between local storage and remoteEach of these logs contain the following:

l Domain Audit Log: Stores audit records for administrative and management actions on the system.

l Transaction Audit Log: Contains audit records related to service usage and policy execution.

External audit offloadThe API Gateway can periodically offload the following audit log files to an external audit server using an HTTP POST:

l Domain Audit Log: Stores audit records for administrative and management actions on the system.

l Transaction Audit Log: Contains audit records related to service usage and policy execution.

When this feature is enabled, these log files are offloaded every five minutes. The files are rolled over when the scheduler runs to ensure the records audited (up to that point) are offloaded. This guarantees a greater degree of synchronicity between the local and remote audit records.

For more information about offloading audit log files and for configuration instructions, see the API Gateway Administrator Guide.

Description of the offload algorithmThe following items describe the offload algorithm:

l By default, the domain log consists of a maximum of 50 files, 5 Mb each. This provides a total capacity of 250 Mb.

l The transaction log consists of a maximum of 20 files, 1000 Mb each. The transaction log is handling business traffic; therefore, it will contain more data than the domain log.

l The transaction log maximum files and log size settings can be configured using Policy Studio.

l A scheduler runs every five minutes, picks up all domain and transaction audit log files, and posts them to the external location.

l Log files are automatically rolled over when the scheduler is run. This guarantees that all records written (up to that point) are offloaded.

l Files are posted over a TLS-secured HTTP channel to a HTTPS server that can process and save them to disk. For example, a HTTPS-enabled API Gateway.


3 Security

This section describes the various types of security used by Axway and API Gateway, including:

l Security architecture on page 17

l Cryptography on page 17

l Password policy on page 17

l Advisory banner on page 20

l TLS configuration on page 21

Security architectureFor information about the security architecture of API Gateway, see the API Gateway Security Guide.

CryptographyThe evaluated configuration depends on the operational environment to provide cryptographic functionality for its use.

The TOE invokes services from the following cryptographic modules in its operational environment:

l OpenSSL FIPS Object module

For more information, see the API Gateway Security Guide.

Password policyWhen you log into the Policy Studio or API Gateway Manager, you must enter the user credentials stored in the local admin user store to connect to the API Gateway server instance. The API Gateway Administrator can login to API Gateway Manager where they can create, edit, and delete other administrator users.

When the passwords are created for these admin users, the passwords must adhere to the Password Policy.


The following restrictions can be applied to a password policy:

l Password must not be equal to the account name: The password cannot be identical to the admin user name.


3 Security

l Password must not be the reverse of the account name: The password cannot be the reverse of the admin user name.

l Password must not contain the account name: The password cannot contain the admin user name.

l Minimum password length: The password must be the specified minimum length. In evaluated configuation, the minimum password length is set to 16 characters.

l Password history length: Enter the number of previous passwords to be compared. This is not specified by default. If no value is specified, this rule is ignored.

l Minimum character differences from last password: Enter the minimum number of different characters from the last password. This is not specified by default. If no value is specified, this rule is ignored.

l Password lifetime (days): Enter how long the password is valid for in days. There is not a specified default. If no value is specified, this rule is ignored.

l Minimum uppercase characters: Defaults to one uppercase alphabetic character.

l Minimum lowercase characters: Defaults to one lowercase alphabetic character.

l Minimum numeric characters: Defaults to one numeric character.

l Minimum special characters: Defaults to one special character (~!@#$%^&*()-_=+\[{}];:"",< >/?). If no value is specified, the rule is ignored.

Enable the password policyThe password policy rules are disabled by default. To enable the password policy:

1. Click the Settings > Admin Users tab in API Gateway Manager.

2. Select Password Policy enabled.

3. Configure the rules.


Required password policy metrics and configurationIn evaluated configuration, the following metric must be set:

l Password min characters must be set to 16 characters

The following metrics can be configured by an administrator, but have no default values in the evaluated configuration:

l Min special chars

l Min numeric chars

l Min lowercase chars

l Min uppercase chars


3 Security

l Password lifetime

l Password history

Credential storageThis section includes information about:

l The storage of the admin password.

l Credentials for client service users.

l The secret used by API Gateway for mutual authentication.

l The secrets used to authenticate external products such as the Active Directory server, the external/remote syslog server, and the back-end servers.

Admin password storageThe administrator user passwords are stored as a base64-encoded salted hash of the plain text password in the following file: INSTALL_DIR/apigateway/conf/adminUsers.json

The salt is a 16-byte value generated using the SHA1PRNG pseudo-random number generator algorithm. The algorithm used is HMAC SHA1 using a key length of 256 bits. The algorithm repeats the digest of the password along with the salt for 1024 iterations.

Note A new salt is used for each password hash, which results in different password hashes for the same password.

Note These cryptographic operations are implemented in the cryptographic modules in the TOE environment.

Passwords stored in entity storeAll sensitive data (local user store passwords, private keys and their passwords, and passwords required to connect to third party services) can be encrypted in the Entity Store using PBE with the Entity Store passphrase. The password and a random 8-byte salt are converted using the PKCS#12 mechanism to a key and IV for the encryption algorithm. The encryption algorithm used is 3DES, EDE, 3 key, with the SHA1 digest used for generating the IV and key material.

You can change the Entity Store passphrase at any time using Policy Studio. For more information, see the API Gateway Administrator Guide.

Client service user credentialsAPI Gateway can either store client service user credentials in a local store or in a third party Identity Management product.


3 Security

When credentials are stored in the local User Store, they are encrypted with the Entity Store passphrase (as described earlier). However, in evaluated configuration, user credentials are stored in an LDAP repository and the API Gateway is configured to authenticate service clients against this repository.

In this case, it is not necessary to store any service client credentials on the API Gateway.

Secrets used by API Gateway for authenticationAll secrets and keys used by API Gateway to authenticate to third party services (for example, LDAP, Audit Server, and mutual TLS-secured Web Service) are encrypted with the Entity Store passphrase.

Advisory bannerYou must configure API Gateway to display an advisory warning message about unauthorized use of API Gateway when establishing a successful user session from Policy Studio or API Gateway Manager.

Enable the bannerThe advisory banner is configured in the API Gateway Manager by selecting Settings > Advisory Banner.

Configure the bannerOn the Advisory Banner screen in API Gateway Manager, configure the following settings:

l Advisory banner enabled: Select whether the banner is enabled. The default is disabled.

l Advisory banner text: Enter the text to display on the advisory banner. The default text is:

Warning - unauthorized use of this tool is strictly prohibited and subject to

audit, investigation, and potential prosecution.

When the banner is enabled, it is displayed on the API Gateway Manager login page and Policy Studio Connection dialog. The following screen shows how the banner is displayed on the API Gateway Manager login dialog:


3 Security

For more information about the banner, see the API Gateway Administrator Guide.

TLS configurationAPI Gateway supports Secure Sockets Layer (SSL) and Transport Layer Security (TLS) for transport-based authentication, encryption, and integrity checks. API Gateway can use certificates generated using Policy Studio and imported directly into its Trusted Certificate Store or it can easily import certificates generated using a third party tool. For additional information, see API Gateway Administrator Guide.

In evaluated configuration, in order to comply with the requirements for enabled cipher suites in the Target of Evaluation, the following cipher string was used on all inbound interfaces (for example, Node Manager interface) and all outbound connections to backend services:

AES128-SHA:AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384

This cipher string enables the following ciphers on these interfaces/connections:

TLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHATLS_DHE_RSA_WITH_AES_128_CBC_SHATLS_DHE_RSA_WITH_AES_256_CBC_SHATLS_RSA_WITH_AES_128_CBC_SHA256TLS_RSA_WITH_AES_256_CBC_SHA256TLS_DHE_RSA_WITH_AES_128_CBC_SHA256TLS_DHE_RSA_WITH_AES_256_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

This cipher string must be configured in the following locations:

l The ciphers field on the HTTPS Interface on Admin Node Manager's configuration on first host.

l The ciphers field on the HTTPS Interface on Node Manager's configuration on second host.

l The ciphers setting in the /[INSTANCE_ID]/conf/mgmt.xml file on host 1.

l The ciphers setting in the /[INSTANCE_ID]/conf/mgmt.xml file on host 2.


3 Security

l The ciphers field in all Connect to URL filters used in the evaluation to route requests to backend services.

The following setting must also be set in the java.security file in /Win32/jre/lib/security on Windows and /Linux.x86_64/jre/lib/security on Linux:

jdk.tls.disabledAlgorithms=MD5, SSLv3, ECDH, DHE_DSS, DES, ECDHE_RSA, RC4, TLS_EMPTY_RENEGOTIATION_INFO_SCSV, RSA keySize < 2048

The mandatory cipher suite required by Common Criteria, TLS_RSA_WITH_AES_128_CBC_SHA, is supported in the API Gateway default configuration. For more information, see the API Gateway Security Guide.

TLS connection configurationThe following secure connections are made in evaluation configuration:

l Connections between all product components (API Gateway, Node Manager, and Policy Studio) are TLS-secured, by default.

l Connections to the LDAP server must be TLS-secured.

l Connections to the audit servers must be made over TLS.

l Interfaces serving business traffic on the API Gateway must be TLS-secured.

l All outbound connections made by the API Gateway to destination Web Services must be made over TLS.

For additional configuration information, refer to the section Security Configuration in the API Gateway Security Guide.


4 Access control

API Gateway uses Role-Based Access Control (RBAC) to selectively share database information with other users. RBAC enables you to restrict system access to authorized users based on their assigned roles. Permissions to perform specific system operations are assigned to specific roles, and system users are granted permission to perform specific operations only through their assigned roles. This simplifies system administration because users do not need to be assigned permissions directly, and instead acquire them through their assigned roles.


This section describes the various types of access control used by the API Gateway, including:

l Policies on page 23

l Object and subject attribute definition on page 29

l Authentication on page 30

l Management functions on page 31

PoliciesA policy is a network of message filters in which each filter is a modular unit that processes a message. A message can traverse different paths through the policy, depending on which filters succeed or fail. For example, this enables you to configure policies that route messages that pass a Schema Validation filter to a back-end system, and route messages that pass a different Schema Validation filter to a different system. A policy can also contain other policies, which enables you to build modular reusable policies.

Access control policies are created automatically when a SOAP service is registered in the Web Services Repository. This policy contains all necessary logic used to resolve the request, schema validate the request, and route it to the actual web service. You can also manually create access control policies to manage service usage.

Every object or service accessible through API Gateway must have an associated policy with a configured relative path. The default policy for API Gateway is to deny access to all protected services. So if a service is not mapped to a policy, the default policy is invoked for every request for access to the service, which will always be denied.

Policies that control access to the administration interface on the Admin Node Manager are typically not modified since the defaults are sufficient for most use cases. However, they can be modified to alter the default behavior, if necessary. These types of changes should be made as part of the initial setup.


4 Access control

Note Policies are applied at the group level, where a group consists of a number of API Gateway instances. In fact, a group is defined as a collection of API Gateway instances that are running the same set of policies.

All configuration changes are pushed from either Policy Studio or API Gateway Manager to the Admin Node Manager's management interface (on port 8090) over a secure TLS 1.2 channel, which has two responsibilities:

l Push policies to all API Gateway instances running on the same host.

l Push policies to the Node Manager that runs on all other hosts in the domain, which in turn pushes the policies to all API Gateway instances that run on each hosts. In other words, policies are replicated across hosts by Node Managers that communicate with each other's Node Managers over a secure TLS 1.2 channel. The Node Managers then pushes the policies to all API Gateway instances running on the host.

Typically, policies are modified only if there is a change to how service users are allowed to access the service. For example, if users with a certain LDAP role are allowed to access a service, the LDAP RBAC filter may have to be updated and re-deployed for that change to take effect.

For more information about policies, refer to the section Schema Validation in the API Gateway Policy Developer Guide.

Filters included in evaluated configurationThe following categories of policies can be configured from Policy Studio in the evaluated configuration:

l Authentication

l Authorization

l Integrity

l Logging

l Fault handling

The following message filters can be configured in the evaluated configuration:

HTTP Basic Authentication

The API Gateway authenticates clients using HTTP basic authentication against an LDAP directory. This filter is used in conjunction with a HTTPS Interface to ensure that the client username and password are always passed over a TLS 1.2 encrypted channel.

Direct authentication is supported, where the client submits the “Authorization” header on the first request. Furthermore, a challenge-response mechanism is supported, where the client does not submit the “Authorization” header in the first request, which forces the API Gateway to return a “challenge” to the client in the form of a HTTP 401 response code. The client must then submit the “Authorization” header on the subsequent request.

Retries are supported in cases where the user enters incorrect (or no) credentials in the browser. The browser allows the user to “retry” their credentials for a number of times, which is configurable in the browser.


4 Access control

If the user supplies invalid credentials more than 6 times in a 5 minute time period, the user will be locked out for 30 minutes.

The format of the credentials can be configured to be one of the following, depending on what is configured in the LDAP directory:

l Username: applicable

l X.509 Distinguished Name: Not applicable

There is an option to remove the “Authorization” header in a post processing step, but is not relevant to access control decisions.

Refer to the HTTP basic authentication section of the Policy Developer Guide for more information.

HTML Form Authentication

User credentials are passed to the API Gateway in a HTML form and authenticated using HTML form-based authentication against an LDAP directory. The filter is used along with a HTTPS Interface that enforces the use of TLS 1.2 to secure the client credentials.

It is possible to configure the form fields used to contain the username and password.

The format of the credentials can be configured to be one of the following, depending on what is configured in the LDAP directory:

l Username: applicable

l X.509 Distinguished Name: Not applicable

As with HTTP Basic authentication, if the user submits an incorrect username and/or password more than 6 times in a 5 minute interval, that user will be locked out for 30 minutes.

With form-based authentication, the following attributes are validated on the user’s session:

l Session Expiry: By default the session expires after 60 seconds.

l Secure Flag: The filter can be configured to restrict the use of the session to secure channels only.

l HTTP Only: Sets the HttpOnly attribute on the cookie to restrict access to the cookie from client-side script.

Mutual TLS 1.2 Authentication

A HTTPS Interface is configured to require clients to present their certificates during the TLS 1.2 handshake. The CA cert that issued the client certificate must be explicitly trusted by the HTTPS Interface.

The HTTPS Interface is configured to require client certificates and to trust a certificate chain on the client certificate of up to 1 certificate by default.

The HTTPS Interface supports the cipher suites enabled by the following OpenSSL cipher string and blocks the SSLv2 and SSLv3 protocols.

A check is performed to ensure that the server SSL certificate’s Common Name resolves to a network address. SSL Server Name Identifier (SNI) is not applicable for the evaluated configuration.


4 Access control

Refer to the HTTP and HTTPS Services section of the Policy Developer Guide for more details on how to configure the HTTPS Interface to support mutual authentication.

LDAP Attribute Authorization

This filter enables authorization of an authenticated client for a backend service based on user roles stored in an LDAP directory. User attributes are retrieved from the selected LDAP directory and compared against some configurable values.

The filter can be configured to succeed if only 1 comparison succeeds or if all comparisons succeed. There are various types of matching rules that can be used in the comparison:

l Applicable: contains, doesn’t contain

l Not Applicable: matches regular expression, doesn’t match regular expression, ends with, is, is not, starts with

The advanced settings on this filter include the ability to cache retrieved attributes for use by successive filters and how to process multi-valued attributes. However these settings are not relevant to the access control decision that the filter enforces.

Refer to the LDAP Attribute Authorization Filter section in the Policy Developer Guide for more information.

SAML Authentication

The API Gateway extracts a SAML 2.0 authentication assertion from a WS-Security block in the SOAP Header. Once the assertion has been extracted, the following validation is performed:

l Ensure that the assertion is using the SAML 2.0 namespace.

l Check the Created and Expires assertions to ensure that the assertion is still valid, taking into account the configured drift time to allow for discrepancies between the machine on which the assertion was generated and the Gateway’s machine.

l Make sure that the Issuer of the assertion matches one of the Trusted Issuers configured in the filter.

Refer to the SAML Authentication Filter section of the Policy Developer Guide for more information.

XML Signature Verification

XML Signature Verification is used to verify the integrity of an XML Signature embedded within a WS-Security block with a specified SOAP actor/role.

The following types of XML Signatures are supported:

l Asymmetric

l Symmetric

l Enveloped

l Enveloping

The public key to use to validate the signature can be extracted from the KeyInfo section of the XML Signature using one of the following key referencing mechanisms:


4 Access control

l Not applicable: Public key is embedded in the message.

l Not applicable: Public key included in a certificate that is contained within an attachment

l Applicable: Security Token Reference

For the purposes of this evaluation, the key will be referenced using one of the following applicable Security Token Reference methods:

l Applicable: X509v3, EncryptedKey, EncryptedKeySHA1, Issuer DName and Serial Number, ThumbprintSHA1, X509SubjectKeyIndentifier

l Not Applicable: GSS_Kerberosv5_AP_REQ, GSS_Kerberosv5APREQSHA1, Key Identifier with x509v3, PKCS7, SAMLAssertionID, SAMLID, SecurityContextToken, X509PKIPathv1, X509v1

The nodes that must be signed by the XML Signature can be configured using the pre-configured Node Locations options, for example, SOAP 1.2 or SOAP 1.1 Body.

While all WS-SecurityPolicy AlgorithmSuites are available, for the purposes of this evaluation the XML Signature must be signed with algorithms that comply with the Basic256 suite.

The filter will block messages that do not contain an XML Signature.

Refer to the XML Signature Verification section of the Policy Developer Guide for more information.

IP Address Authentication

The API Gateway restricts access based on the client’s IP address. Filtering can be done based on a specific IP address or on a range of IP addresses.

Refer to the IP Address Authentication section of the Policy Developer Guide for more information on this filter.

Time Filter

This filter enforces time-based access control to APIs and Web Services. The filter can be configured to either block or allow requests during a configurable time period. The time period is defined using one of the following options:

l User-defined period using configurable “from” and “to” times

l Time based on message attributes (not evaluated)

l Days of the week

l Cron Expression

Refer to the Allow or block messages at certain times section of the Policy Developer Guide for more information on these configuration options.

Log Message Payload

This filter logs the request and/or response message payload to the audit trail at a particular point in the policy execution.

Refer to the Log Message Payload section of the Policy Developer Guide for more information.

SOAP Fault


4 Access control

The SOAP Fault filter is used to return a SOAP 1.1 or 1.2 Fault to the client when an error occurs anywhere in the execution of a policy.

Refer to the SOAP Fault Handling section of the Policy Developer Guide for more information on configuring SOAP Faults.

Access control policy definitionAPI Gateway uses Role-Based Access Control (RBAC) to restrict access to management APIs to only authorized users based on their assigned roles in a domain. Using this model, permissions to perform specific system operations are assigned to specific roles only. This simplifies system administration because users do not need to be assigned permissions directly, but instead acquire them through their assigned roles.

For example, the default admin user (admin) has the following user roles:

l API Gateway Administrator

l API Gateway Operator

l Policy Developer

l Deployer

For the security managment functions, see Management functions on page 31.

Access control policy transmissionTypically, access control and other policies are transmitted to a group of API Gateways using Policy Studio. However, it is also possible to transmit policies to a single gateway instance. Policies are deployed to a group of gateways by selecting the Deploy button in Policy Studio. After a successful deployment, the policies become live, and a receipt of notification is returned to Policy Studio. If the policies could not be deployed, an error message is returned to Policy Studio.

Note Policy Studio is an off-line tool; therefore, a constant connection to the Admin Node Manager is not necessary. Policy Studio only needs to connect to the Admin Node Manager when it is reading a configuration for a group or deploying configuration to the group.

The API Gateway will always enforce the last deployed policy. If a connection outage occurs while a configuration is being deployed, the API Gateway instances will continue to enforce the last received configuration.

Policy engine rulesAPI Gateway contains a set of message filters that directly or indirectly restrict access to web services. For example, filters that directly control access include XML-signature verification, CA certificate chain verification, and SAML assertion verification. With this class of filters, policy decisions are made and enforced within API Gateway's core engine.


4 Access control

Object and subject attribute definitionThe API Gateway associates object and subject attributes with various protected resources.

Object attribute definitionThe security policy protecting each resource is the main security object associated with that resource. Each back-end service is encapsulated within a Remote Host object where specific connection details for that host are configured. When the gateway attempts to send requests to that host the connection details configured for the corresponding Remote Host are used.

The service on the Remote Host is virtualized on the API Gateway using a Relative Path, which is then mapped to a specific policy. When a request is received by the API Gateway on this path the configured policy will be invoked. Only if the policy is executed successfully will the service on the Remote Host be invoked.

Note The policy ID uniquely represents the policy in the Policy Library. Whenever a policy is invoked, the policy ID is recorded in the API Gateway's Transaction Log.

Subject attribute definitionWhen a service user or administrator user authenticates to the API Gateway, a number of attributes are associated with that subject, depending on how they authenticate. For example, if the user authenticates with a certificate, that user's certificate will be associated with that request and can be used by other filters in the policy.

Other attributes that can be associated with the user include ID, role, issuing certificate, SAML Id, and so on.

Consistent security attributesPolicy Studio implicitly guards against building faulty logic in policies. For example, an error is displayed if a Policy Developer attempts to build a circular dependency in the policy invocation path.

Similarly, during configuration, Policy Studio provides an error if a filter configured in a policy does not have the required message attributes in order to perform its business logic. For example, all authorization filters require an authentication filter to precede them within the policy logic. This means only authenticated users can be authorized to access a resource. If the authorization filter is configured without a preceding authentication filter, a red colored filter is displayed the Policy Editor.


4 Access control

AuthenticationThe API Gateway offers several authentication mechanisms for both administrator users and service users. Each mechanism can be configured using specific filters, which can be combined to implement logical AND and OR flows through the policy.

For example, you can configure an LDAP Authentication filter, combined with a Time filter, to ensure only the users who are authenticated successfully against the LDAP repository have access to the protected web service in the configured time frame.

Administrator authenticationAdministrative users of the API Gateway include API Gateway Administrators, Operators,and Policy Developers. Administrative users logging in from Policy Studio must authenticate using HTTP Basic authentication. Administrative users accessing API Gateway Manager must log in using HTML Form authentication. In both cases, the connections are made over a TLS 1.2 connection. The authentication logic is implemented with a policy that uses the HTML Form Authentication and HTTP Basic Authentication filters.

Administrator user passwords are stored on disk within the API Gateway installation in hashed format using the PBKDF2 function. The policy protecting the Admin Node Manager's management interface is pre-configured to authenticate admin user requests against this internal store.

By default, the API Gateway is configured to lock administrator users out for a 30 minute period after six invalid attempts within a five minute period. The default settings can be modified if you connect directly to the Admin Node Manager's configuration (.fed) file and update the Protect Management Interface policy. The Authenticate login attempt HTML Form Authentication filter and HTTP Basic filter must both be updated with the required settings.

When an administrator user logs in to the management interface, the TOE associates, or binds, security attributes (user name, password and user role) for that user. The TOE can then use this binding to enforce RBAC rules to ensure that users with different roles can only access certain parts of the application. Similarly, the RBAC rules are also used to determine the types of users who can access Policy Studio or API Gateway Manager, as well as what operations these users can perform in the tool.

For example, while the API Gateway Administator can manage all functions of the TOE available through the API Gateway Manager dashboard and Policy Studio, the API Gateway Operator has read-only access to the dashboard, but cannot see the audit records or log in to Policy Studio. If an authorized administrator changes the role for another user while the user is logged in, the change will take effect immediately.

For more information, refer to the Password management features section of the API Gateway Security Guide.


4 Access control

Service Users authenticationThe API Gateway offers a range of authentication filters that can be used to restrict access to protected resources, for example, Mutual TLS, HTTP Basic, HTML Form, IP Address, Time, and SAML. These filters can be combined, in any order, to implement flexible and powerful access control policies.

Service Users can be stored directly in the API Gateway internal User Store; although, typically organizations have their own silos of user profiles that allow the gateway to connect to in order to authenticate users. In this scenario, the API Gateway acts more as the Policy Enforcement Point as opposed to the Policy Decision Point. In evaluated configuration, the API Gateway connects to an LDAP repository where users are stored and authenticates users against this repository. If the credentials passed to the API Gateway are successfully authenticated against the LDAP repository, the post-authentication filters can be invoked.

Service users are authenticated using username/password and certificates. When a service user presents a username/password to the API Gateway in evaluation configuration, the API Gateway forwards them to the LDAP server over a mutually authenticated TLS 1.2 channel.

The LDAP server makes the authentication decision based on the passed credentials and returns the decision to the API Gateway, which then enforces the decision. If a certificate is presented, the API Gateway validates the certificate to make sure it was issued by a trusted issuer and it is valid with respect to its creation and expiry dates.

Management functionsThe Admin Node Manager is responsible for enforcing Role-Based Access Control (RBAC) to the administrative interfaces of the API Gateway, which are listed in full in the API Gateway Administrator Guide. The following roles can be assigned to admin users in evaluation configuration:

API Gateway AdministratorThe top-level, "super" user role in the system. Has read/deploy privileges in Policy Studio and read/write privileges in API Gateway Manager.

API Gateway OperatorThis role is assigned to users whose role it is to monitor the health of the topology and diagnose problems by viewing the logs. This user has access to API Gateway Manager, but cannot access Policy Developer.


4 Access control

Policy DeveloperThe Policy Developer uses Policy Studio to read, write, and deploy policies to an Admin Node Manager. Users with this role can not access API Gateway Manager.

DeployerThe Deployer role is reserved for a DevOps user who typically scripts the build and deploy of policies from a Continuous Integration (CI) environment. It is practically identical to the Policy Developer role with some very limited restrictions. For example, a Deployer user is not allowed to lock group configuration.

For more information on User Roles, see the API Gateway Administrator Guide.

Security ManagementThe following Management Functions are available to API Gateway Administrators, Operators, and Policy Developers in API Gateway Manager and Policy Studio:

Audit EventsAPI Gateway Administrators can select the events they want to audit in the system from the list of all auditable events using API Gateway Manager. Refer to the Configure audit logs per domain section in the API Gateway Administrator Guide for a complete list of auditable events.

Location of Audit ServerIt is possible for API Gateway Administrators and Operators to configure details (such as location, server cert, and so on) of the Audit Server in API Gateway Manager. Furthermore, if the audit server requires username/password authentication, the credentials can be configured. Refer to the Configure audit logs per domain section of the API Gateway Administrator Guide for more information on how to configure audit offload.

Manage UsersAdmin users can be created, updated, and deleted from within the API Gateway Manager interface. The RBAC roles described can be assigned to admin users. Since admin users can only be configured through the API Gateway Manager interface, only API Gateway Administrators and Operators can do this. Refer to the Manager user access section of the API Gateway Administrator Guide for detailed information on how to manage users.


4 Access control

Configuration of Access Control PoliciesThe configuration of access control policies is done in Policy Studio by Policy Developers and/or API Gateway Administrators. Once a policy is ready to be pushed to a group of API Gateway instances, it can be deployed by both types of users. Refer to the API Gateway Policy Developer Guide for detailed information on how to configure policies.

Querying of PoliciesWhen a Policy Developer or API Gateway Administrator logs into Policy Studio, they can select a Group in the domain and retrieve the set of policies that constitute the configuration for that group. Refer to the API Gateway Policy Developer Guide for detailed information on reading policies from an Admin Node Manager.

Management of Object AttributesIt is important to note that configuration objects representing back-end Web Services (such as Connect to URL Filters, Remote Hosts) are not accessible by default. Any policy that include these objects cannot be accessed by a service client unless the API Gateway Administrator or Policy Developer explicitly configures this by mapping a Relative Path to the policy. Once the path-to-policy mapping has been configured, whenever the API Gateway receives a request on this path, it invokes the policy that is enforcing access control for the service object. This concept is known as service virtualization, where the back-end service is virtualized, but not hosted, on the API Gateway.

Path-to-policy mappings can either be configured manually or automatically via the Web Services Registry import wizard in cases where the back-end service interface is defined by a WSDL file. Refer to the API Gateway Policy Developer Guide for detailed information on how to use the Web Services Repository to virtualize services.

Reliable timestampsConfiguration of a reliable time source should be done in the Operational Environment as opposed to in the Target Of Evaluation. For example, ensure the OS is synchronized with a reliable NTP server.


5 Communications

There are many types of communication channels in operation with an Access Control product, such as API Gateway, including:

l Inbound and outbound connections

l Administrative channels

l Business traffic

l Connections between internal and external components

This section describes the various types of inbound, outbound, and internal communication channels used by the API Gateway, including:

l Communication failures on page 34

l Sessions on page 35

l Trusted paths and channels on page 36

Communication failuresAn important feature of any Access Control product is to block unauthorized access to the interfaces that it exposes. Furthermore, it is crucial that once such a potentially malicious request is detected and blocked the product must audit the attempted breach.

API Gateway guards against unauthorized access of its management interfaces by requiring valid client credentials to authenticate requests on those interfaces. Any unsuccessful authentication events on the API Gateway's management interfaces are reported in the Domain Audit Log.

Similarly, if invalid credentials are presented to the API Gateway's service traffic ports or if the user has valid credentials but not the right level of privileges for the requested service, the API Gateway will audit the relevant information to the API Gateway's Transaction Log.

The API Gateway and Node Manager components communicate internally over mutually authenticated TLS channels. When each gateway instance is added to the domain topology, a certificate is generated and signed for that instance by the Admin Node Manager in that domain. Because each component implicitly trusts the top-level domain certificate, each component trusts any certificates that have been issued by the domain CA. For additional information on how to set up the domain topology, refer to the Manage domain topology in API Gateway section of the API Gateway Administrator Guide.

In a typical deployment scenario, the API Gateway is configured to interact with an enterprise's security infrastructure, including corporate LDAP repository, audit servers, internal business servers/services, and so on. Whenever the API Gateway fails to route to one of these services, the Gateway logs an appropriate failure message in its Transaction Log.


5 Communications

Failure of communication on policy transmission Policies are transmitted from Policy Studio to the API Gateway using the deployment option. If there is a failure to deploy the policy (for instance, API Gateway was not available and the connection timed out), Policy Studio displays the appropriate error message to the user.

In the case where the Policy Developer is deploying to multiple API Gateways in a group, and one or more of those Gateways failed to deploy the configuration, the error message shown by the Policy Studio will indicate which instances failed to deploy the configuration.

Replay detectionThere are various ways to configure the API Gateway to detect replay attacks using policy configuration. However, in evaluated configuration, the API Gateway relies on the implicit integrity checking used in the TLS protocol.

SessionsAPI Gateway Manager is a web-based interface that is used to configure global settings in API Gateway. The management interface that API Gateway Manager connects to implements sessions to provide access to administrative users.

Session establishmentAn admin user, with the API Gateway Manager Administrator or API Gateway Manager Operator user roles, authenticates to the API Gateway Manager interface using HTML form authentication. When an administrator successfully authenticates to this interface, this creates an HTTP session.

Session lockingYou can configure the API Gateway Manager interface to lock out users for a certain time interval after a configurable number of unsuccessful authentication attempts. By default, a user is locked out for 30 minutes after six invalid attempts within a five minute period.

Session terminationBy default, user sessions in API Gateway Manager are configured to last for 12 hours. However, if necessary, you can change this value by editing the env.WEBMANAGER.SESSION.TIMEOUT setting in the following file:


5 Communications

INSTALL_DIR/conf/envSettings.props

Administrator users can also manually terminate their interactive sessions using the Log out button in API Gateway Manager. Similarly, they can terminate interactive sessions in Policy Studio by closing a configuration (admin credentials must be re-entered to download the configuration) or by exiting Policy Studio completely.

Trusted paths and channelsAPI Gateway provides trusted channels to other trusted IT entities within the organization, including LDAP servers, audit servers, FTP services, and so on. Similarly, trusted paths are used to expose (using REST and SOAP interfaces) management functions to trusted Policy Management tools, such as Policy Studio andAPI Gateway Manager.

Trusted pathsAll management interfaces exposed by the Node Manager are protected using either HTTP Basic or HTML Form authentication. Policy Developers accessing the management interface using Policy Studio authenticate with HTTP Basic authentication, while API Gateway Administrators or Operators authenticate with HTML Form authentication.

Trusted channelsCertificates and key pairs can be imported into API Gateway's trusted certificate store so that they can be used in trusted channel communications, signing and verifying data, encrypting and decrypting data, and so on. All private keys stored in the certificate store can be encrypted with the Entity Store passphrase.

Certificates and keys can also be stored in a Hardware Security Module (HSM), for example, Thales nShield Solo or Safenet Luna SA.

For detailed information on storing certificates and keys on a HSM, see API Gateway Administrator Guide.

For detailed information on the certificate store, see API Gateway Policy Developer Guide.


Appendix A: Required audit events for common criteria

This section describes the content of the required audit events.

Audit event formatThe format of all audit events is as follows:

[Message] [Event Type] [User] [Outcome] [Additional Info] [Metadata] [Date/Time] [Group] [Server]

Audit event descriptionsAttribute Description

Message A textual description of the log event.

EventType A numberical ID to indicate the event type.

User The authenticated user who "owns" the event (when applicable).

Outcome Event's success or failure.

AdditionalInfo Mode detail about the event (when necessary).

Metadata Metdata about the event.

Date/Time The time of the event.

Group The domain group where the event occurred.

Server The domain server where the event occurred.


Glossary

Common Criteria (CC)An international standard (ISO/IEC 15408) for computer security certification.

Protection Profile (PP)A document identifying security requirements for a software product or device.

Security Assurance Requirements (SARs)The descriptions of measures used to develop and evaluate a product to assure complaince with security functionality.

Security Function Policy (SFP)A policy describing the security functions of a product.

Security Functional Requirements (SFRs)Specific individual security functions provided by a product.

Security objectiveStatements of intent to counter identified threats and satisfy intended security policies.

Security Target (ST)The document identifying the target of evaluation's security properties.

Strength of Function (SOF)The strength level of a security function of a product.

Target of Evaluation (TOE)The product or subject of the security evaluation.


Documents

Axway API Gateway - NIAP CCEVS · 2018-04-28 · Support for high contrast and accessible use of colors 7 1 Installation 8 Target ... The following Axway products are the targets