Requesting new features
Ideas for new features can be submitted using the IBM Application Gateway Ideas Community.
- Authorization policies can now indicate that a client must re-authenticate before accessing a resource. (see: Tasks/Re-Authentication)
- Rate limiting data can now be distributed across multiple IAG instances using a Redis database. (See Sharing rate limiting data across instances, server/rate_limiting and services/redis)
- Bug Fixes, Security Updates and behind the scenes improvements.
- Bug Fixes, Security Updates and behind the scenes improvements.
- IAG can now redirect clients to a configured URL when authentication is completed. (See Controlling Redirects, and auth_complete_redirect)
- Additional Bug Fixes, Security Updates and behind the scenes improvements.
- IAG now supports the PROXY protocol for identifying clients. (See PROXY Protocol, server/protocols, server/client_ip_rules)
- IAG can now include additional HTTP headers when making requests to OAuth introspection endpoints. (see oauth)
- Each server in a resource server can now be assigned a priority group, which can be used to control which server IAG will direct traffic to. (See Multi-server Applications and resource_servers/servers)
- The UUID of each each server in a resource server can now be configured, which allows stateful applications to span multiple instances. (see Stateful Applications and resource_servers/servers)
- IAG can now directly reference data from a Kubernetes ConfigMap by name and field in the configuration YAML (see: "Special Types Available in Kubernetes" in Concepts/Configuration)
- IAG can now direct unauthenticated clients to a specific URL to perform authentication. (See auth_challenge_redirect)
- Applications running on protected resource servers can now authenticate clients using the External Authentication Interface. (See External Authentication)
- An authorization policy can now redirect clients to a specific URL when denying access. (See obligation/redirect_url)
- A new browser based application which can be used to author and visualise the IAG configuration YAML has been made available at the following URL: ibm.biz/ibm-app-gateway-yaml.
- Session state can now be stored in an external Redis database and shared between multiple instances of IAG. (see Sharing Sessions Between Containers)
- IAG can now perform single sign-on to Kerberos protected resource servers using Constrained Delegation. (see Passing Identity Information to Applications)
- IAG can now perform OAuth introspection to authenticate clients. (see Protecting Applications with IBM Security Verify and Protecting Applications with IBM Security Verify Access)
- A new Kubernetes operator can be used to configure and manage IAG instances. (see Deployment/Kubernetes/Overview)
- The Kubernetes operator is available from OperatorHub.io. (See Deployment/Kubernetes/OperatorHub)
- The Kubernetes operator can produce combined configuration from multiple sources, including literal definitions, config maps and web-based sources. (See Deployment/Kubernetes/Operator)
- The Kubernetes operator can be used for sidecar injection when deploying applications in Kubernetes. (See Deployment/Kubernetes/Sidecar)
- The Kubernetes operator can perform dynamic OIDC client registration to register new OIDC clients for IAG instances with the identity provider. (See Deployment/Kubernetes/OIDC Dynamic Client)
- IAG can now retrieve credentials for use in single sign-on from an external credential service. (see Using a Credential service for single sign-on)
- IAG can now generate LTPA token for single sign-on to protected applications. (see identity_headers/ltpa)
- A new "Hello World" topic which demonstrates the various IAG deployment models has been added to the Developer Portal (see Hello World in the sidebar)
- A new demonstration resource server application has been created. This application can be used when exploring IAG deployment models or experimenting with configuration (see References/Demo Resource Server)
- IAG can now perform OAuth introspection to authenticate clients. (see Current Preview Features)
Note: This is a preview capability and may be changed in a future release.
- Authentication requirements can now be enforced as part of an authorization policy (see: Tasks/Authentication Requirements)
- IAG can now read obfuscated and encrypted entries from the configuration YAML (see: "Special Types" in Concepts/Configuration)
- Certificate related entries can now be specified as an array of certificate and key entries and do not need to be concatenated into a single string (see: Tasks/Managing Certificates)
- IAG can now directly reference data from Kubernetes Secrets by name and field in the configuration YAML (see: "Special Types Available in Kubernetes" in Concepts/Configuration)
- Credentials from an IBM Security Verify Access or IBM Security Access Manager 126.96.36.199+ identity provider can be consumed, where IBM Application Gateway (IAG) acts as OpenID Connect (OIDC) Relying Party (see: Protecting Web Applications with IBM Security Verify Access);
- The 'identity/ci_oidc' YAML configuration node is no longer the preferred way to configure IBM Security Verify as the Identity Provider. The new 'identity/oidc' YAML configuration node should be used instead (see: OIDC).
- IAG can now be configured to listen on port 8080 for HTTP traffic (see: Server/Protocols)
- Signed JSON Web tokens (JWT) can now be generated and sent to resource servers (see: Passing Identity Information to Applications);
- The content injection capability now supports a partial line match (see Inserting Content into Responses).
- Statistics information can now be sent to a remote statsd server for monitoring purposes (see: Enabling Statistics Gathering);
- Credentials from an IBM Security Verify tenant can be consumed, where IBM Application Gateway (IAG) acts as OpenID Connect (OIDC) Relying Party (see: Protecting Web Applications with IBM Security Verify);
- An application can be defined and identified using either a path or host header (see: Protecting an Application);
- An attribute/claims based authorization policy can be defined to control access to resources (see: Defining the Authorization Policy);
- Access to resources can be rate limited (see: Rate Limiting Requests);
- HTTP requests or responses can be modified using XSLT defined rules (see: Transforming Requests and Responses);
- Cross-Origin Resource Sharing (CORS) policies can be handled on behalf of the application (see: Defining the Cross-Origin Resource Sharing Policy);
Updated 5 months ago
Do you have an idea for a new feature? Learn about requesting new capabilities.
Did this page help you?