As API services become increasingly complex, traditional access control methods relying solely on IP addresses or basic request headers are no longer sufficient. API7 Enterprise introduces the concept of "Consumers", allowing developers to bind consumers to specific API routes or services with the same authentication plugins enabled. When a consumer makes a request, the API gateway identifies the consumer based on the credentials provided in the request and applies the corresponding access control policies according to the binding relationships.
API7 Enterprise v3.2.15 enhances existing consumer authentication mechanisms. It optimizes interactions of commonly used plugins, improves permission control, and supports multiple authentication credentials per plugin. This enables more flexible credential management and rotation.
Optimized Consumer Authentication Plugin Interaction
You can easily add multiple authentication credentials in a single authentication plugin. The configuration has been upgraded from coding to intuitive form operations, making the configuration process simpler.
Currently, the consumer supports the following four authentication methods with multiple credentials.
Key Authentication
Key Authentication is a key-based authentication method. Consumers need to include a unique key in their requests, which can be included in the query string parameters or HTTP headers. When configuring requests, consumers must ensure that the key is carried in the requests correctly.
In the route or service configuration, the Key Auth plugin needs to be enabled with the appropriate rules to validate the key in the request. The gateway checks whether the request contains the expected key and whether the key matches the configuration. If the key validation passes, the request is allowed to access the backend service; if it fails, the request is denied.
Basic Authentication
Basic Authentication is a method based on a username and password. Consumers need to include authentication information containing the username and password in the request, usually encoded in the Authorization header of the HTTP request but can also be passed via query string parameters, though unrecommended due to potential exposure of sensitive information. Consumers must ensure that the encoded authentication information is correctly included when configuring requests.
In the route or service configuration, the Basic Auth plugin needs to be enabled with the appropriate rules to validate the authentication information. The gateway checks whether the request includes an Authorization header and follows the Basic Authentication format. The format is Basic <encoded-value>, where <encoded-value> is the Base64-encoded result of the username and password separated by a colon. The gateway decodes this value and compares the decoded username and password against the configured information. If they match, the request is allowed access to the backend service; if not, the request is denied.
Note that Basic Authentication transmits the username and password in plain text, only encoded in Base64 (not encrypted), which makes it unsuitable for high-security scenarios.
JWT Authentication
JWT Authentication is a method based on JSON Web Tokens (JWT). Consumers must include a valid JWT token in their requests, usually in the Authorization header using the Bearer <token> format but can also be placed in query string parameters or cookies as needed. Consumers must ensure the correctness and validity of the JWT token when configuring requests.
When adding JWT credentials, you can configure key elements of the JWT token generation, including the Key (public or private key) for signing and verification, the Secret (key for symmetric encryption), the algorithm used (e.g., HMAC-SHA256 or RSA-SHA256), and the expiration time to set the token's validity period. Only consumers holding valid and unexpired tokens can successfully access protected backend services.
HMAC Authentication
HMAC Authentication is a method based on Hash-based Message Authentication Code (HMAC). Consumers need to generate an HMAC value for the request, usually calculated using a pre-shared key and specific parts of the request (e.g., request method, URI, request body). This HMAC value can be included in query string parameters or HTTP headers.
When configuring requests, consumers must generate and include the HMAC value correctly according to the specified algorithm and format. Specifically, consumers use a known key and request information to generate the HMAC using a hashing algorithm (e.g., SHA-256) and append it to the request.
In the route or service configuration, the HMAC Auth plugin needs to be enabled with appropriate rules to validate the HMAC value in the request. The gateway checks whether the HMAC value is present in the request and recalculates the HMAC using the same pre-shared key and algorithm to verify its validity. If the recalculated HMAC matches the value in the request, the request is allowed to access the backend service.
Granular Consumer Permission Policies
In addition to optimizing credential management, we have further refined consumer permission management. You can now define permissions down to the level of individual consumers, enabling more granular access control. Read and write permissions for authentication credentials are now controlled independently, separate from consumer permissions, providing greater flexibility.
Summary
The latest version of API7 Enterprise introduces major improvements to consumer authentication and permission management. It optimizes plugin interactions, enables independent credential management, supports multiple authentication methods, and refines consumer permission strategies. These enhancements boost credential management flexibility, system security, and overall user experience.
Future updates may introduce additional authentication methods and further refine credential management, offering more innovative features and an improved user experience.
Top comments (0)