WSO2 API网关部署及自定义配置（含OAuth对接）技术咨询

Hey there! Let's tackle your questions about WSO2 API Gateway deployment and customization—this is right up my alley.

You’ve got a couple of solid deployment options depending on your infrastructure:

• Local/VM Deployment
  1. Grab the latest standalone WSO2 API Gateway (or use the gateway component from WSO2 API Manager if you need full API lifecycle management) from WSO2’s official distribution.
  2. Extract the archive to your preferred directory.
  3. Tweak core configurations in repository/conf/deployment.toml—things like port numbers, keystores, or backend connection timeouts.
  4. Start the gateway with bin/gateway.sh (Linux/macOS) or bin/gateway.bat (Windows).
• Containerized Deployment
  1. Use the official WSO2 Docker image: docker run -p 8280:8280 -p 8243:8243 wso2/wso2am-gateway:latest
  2. For persistent configs, mount your local deployment.toml and synapse configs to the container’s /home/wso2carbon/wso2am-gateway-<version>/repository/conf and /home/wso2carbon/wso2am-gateway-<version>/repository/deployment/server/synapse-configs directories.
  3. For Kubernetes, use WSO2’s official Helm chart to deploy a scalable gateway setup with proper ingress and persistence.

Absolutely—WSO2 Gateway is built on Synapse, which is highly extensible. Let’s cover your specific needs:

Integrating Your Own OAuth Server #

To replace the default OAuth validation with your server, you’ll need a custom authentication handler:

1. Write the custom authenticator
   Implement the org.wso2.carbon.apimgt.gateway.handlers.security.AuthenticationHandler interface (or extend the existing OAuth2Handler for easier customization). In the authenticate method, add logic to call your OAuth server’s token introspection endpoint, validate the token, and extract user claims if needed.
2. Package and deploy
   Compile your code into a JAR file and drop it into the gateway’s repository/components/dropins directory.
3. Configure the gateway to use it
   Update deployment.toml to enable your custom authenticator and set it as the priority handler:

   [[apim.gateway.authenticators]]
   name = "CustomOAuthAuthenticator"
   enabled = true
   priority = 1
   
   # Disable the default OAuth authenticator if needed
   [[apim.gateway.authenticators]]
   name = "OAuth2Authenticator"
   enabled = false
   

4. Restart the gateway—now all incoming requests will first go through your custom authenticator for token validation against your OAuth server.

Adding Custom Filter Logic #

You can use Synapse Sequences to inject custom filtering logic into the request/response flow:

1. Create a custom In Sequence
   In repository/deployment/server/synapse-configs/default/sequences, create an XML file (e.g., custom-request-filter.xml) with your filtering logic. Example:

   <sequence xmlns="http://ws.apache.org/ns/synapse" name="custom-request-filter">
       <!-- Log request details (optional) -->
       <log level="custom">
           <property name="REQUEST_PATH" expression="$axis2:REST_URL_POSTFIX"/>
       </log>
       <!-- Filter example: block requests missing a specific header -->
       <filter source="$ctx:request.headers['X-App-Key']" regex=".+" negate="true">
           <then>
               <respond>
                   <payloadFactory media-type="json">
                       <format>{"error": "Missing required X-App-Key header"}</format>
                   </payloadFactory>
                   <property name="HTTP_SC" value="400"/>
               </respond>
           </then>
       </filter>
       <!-- Pass the request through if validation passes -->
       <send/>
   </sequence>
   

2. Attach the sequence to APIs
   • For individual APIs: When publishing or updating an API via the API Manager publisher portal, select your custom sequence under the "In Sequence" dropdown.
   • For all APIs globally: Update deployment.toml to set the default in sequence:

     [apim.gateway.environment]
     in_sequence = "custom-request-filter"
     

3. For advanced logic
   If you need more complex filtering (like database lookups or external service calls), write a custom Synapse Mediator (implement org.apache.synapse.mediators.AbstractMediator), package it as a JAR, drop it into dropins, then reference it in your sequence.

Yes—beyond the above, you can extend or override core gateway components:

• Customize routing logic by extending org.apache.synapse.core.axis2.Axis2SynapseEnvironment
• Add custom handlers to modify the request/response flow at different stages (pre-processing, post-processing)
• Override default Synapse mediators to change how the gateway handles payloads, headers, or errors

The key here is that WSO2 Gateway is designed for extensibility, so almost any part of its behavior can be tailored to your needs.

内容的提问来源于stack exchange，提问作者Amogh Vathare