ramgrandhi / serverless-wso2-apim Goto Github PK

When running sls remove, the removal of the WSO2 API fails if an application is subscribed to it.

Example log output:

{
  response: {
    code: 409,
    message: 'Conflict',
    description: 'Cannot remove the API 7c39e8a5-4481-4b68-b9d5-4b6adaa89797 as active subscriptions exist',
    moreInfo: '',
    error: []
  },
  responseCode: 409,
  responseHeaders: {
    'content-type': 'application/json',
    date: 'Tue, 05 Oct 2021 14:56:18 GMT',
    server: "[XXXXXXX]",
    'strict-transport-security': 'max-age=15768000',
    'x-content-type-options': 'nosniff',
    'x-frame-options': 'DENY',
    'x-xss-protection': '1; mode=block',
    'content-length': '163',
    connection: 'Close'
  }
}
Serverless: [serverless-wso2-apim] Deleting [stack name].. NOT OK, proceeding further.

The desired behaviour would be that the subscription is cleaned up as well and the WSO2 is deleted.

Currently, it is only possible to assign a static URL as string to 'custom.wso2apim.backend.http.baseUrl' field.

However, in cases when you would like to refer a Cloudformation output value (e.g. dynamically generated AWS API Gateway URL, or, dynamically calculated Load Balancer URL etc), it is not possible to map it to the 'baseUrl' field.

This issue is to track progress for this new minor capability to be able to reference same-stack cloudformation exports for the 'baseUrl' field.

Currently, whether the deployment is successful (or) failure, the plug-in gracefully completes.

It needs to change.

Currently, the plugin allows for Developer Portal Visibility options: PUBLIC and PRIVATE and no options for Publisher Portal Access.

The desired behavior would be that it (also) allows for Developer Portal Visibility and Publisher Access Control that is Restricted by Roles and that you can specify the roles that are authorized to access the api in the developer and publisher portals.

Currently Applications & automatic subscriptions of APIs deployed in WSO2 is left as a 'manual task', given it is usually one-time activity to subscribe to deployed APIs. However, if you feel there is a value in automating this - voice your opinions here.

Background

Starting from WSO2 APIM 3.x.x, you can secure APIs using mutual-SSL on top of existing OAuth2 scheme.
More is documented here.

Actual Behavior

Currently, this plugin deploys APIs using default OAuth2 scheme. There is no mechanism to supply mutual-SSL and associated client-certificate in the serverless.yml configuration.

Expected Behavior

This plugin must:

1. Allow to configure the security scheme as mutual-SSL as well as a mechanism to supply client-certificate in serverless.yml - See the proposal below. Keep oAuth2 as defaults, if not set; however when set, mutualSSL can be enabled.
2. Upload/Upsert client-certificate to WSO2 using its REST API here - See the proposal below.
3. Update securityScheme accordingly here - See the proposal below.

Proposal

1. serverless.yml configuration can be extended as below.

custom:
  wso2apim:
    securitySchemes: # Optional
      oauth2:  # Defaults to `oauth2` if not set
        enabled: true  # Defaults to `true` if not set
      mutualSsl:
        enabled: true
        clientCert: "file://certs/client-cert.crt"  # Only `file://` protocol supported, no CF Imports etc.

2. While uploading/upserting client-certificate, you can use the following naming convention for certAlias.

ClientCert___<APIName>___<Version>___<index>_at_<tenantSuffix>

3. Supported values for securityScheme by WSO2 APIM REST APIs is below, here is the permalink.

    "securityScheme": [
        "mutualssl",
        "mutualssl_mandatory",
        "oauth2"
    ]

Assumptions:

1. Potential validation for SLS config (custom.wso2apim.securitySchemes) must at least include:

• securitySchemes entry, if present, then must have either oauth2 or mutualSsl or both as its children.
• securitySchemes.oauth2 is optional. but, if it is present, then it must have valid values true or false.
• securitySchemes.mutualSsl if present, then it must have valid values true or false and valid clientCert file URL (during validation, see if the file mentioned is accessible (or) not using fs.existsSync() for example). This will help avoid run-time errors if file not found etc.

2. Potential e2e test cases must at least include:

• valid-mtls-enabled
• valid-oauth2-mtls-enabled
• valid-oauth2-enabled
• valid-no-oauth2
• invalid-securitySchemes

• Define version-agnostic serverless configuration (goal is to have single Serverless configuration structure, no matter what the underlying WSO2 version is..). It promotes re-use and trust.

• Interface definitions for all operations (createAPIDef, uploadCert etc) must stay the same across all WSO2 versions, and hide the version-specific complexity inside the under src/x.y.z/wso2apim.js.

if you need to refer the base InvokableUrl generated by WSO2 API Gateway in other cloud stacks, you're at the right spot.

This issue will address the ability to export invokableUrl of WSO2 Gateway (via CF exports) after the deployment is successful.

Add a ready-to-use Serverless configuration (a.k.a. example project) for most used scenarios.

dealing with http/s backend
dealing with jms backend

After API definition is created/updated in WSO2 the swagger spec is not published. This results in the API store only rendering the endpoints + method without any of the additional swagger information available/created by the API owner (engineers)

In terms of pre-work I already did some investigation:

• In function createAPIDef the POST /apis data endpoint will return the whole api definition including its id
• It seems that this id can be used to PUT the swagger spec (https://apim.docs.wso2.com/en/3.2.0/develop/product-apis/publisher-apis/publisher-v1/publisher-v1/#tag/APIs/paths/~1apis~1{apiId}~1swagger/put)
• It feels logical to have this happen before invoking the publishAPIDef function which transitions the api lifecycle

Create an easy to regression-test approach with stock WSO2 API Manager distributions (via docker) so contributors can have a peace of mind while adding new features / fixes.

Add support for WSO2 API Manager 3.2.0 to be able to manage your API definitions seamlessly from a similar-looking serverless.yml configuration that has been used for WSO2 API Manager 2.6.0

After an API is created (via "sls deploy"), if we change apidefs.[].backend.http.baseUrl in configuration, WSO2 API configuration isn't changed (the previous version is kept) when doing "sls deploy" for upserting.

Steps to reproduce

• Deploy an API via sls deploy
• Check the endpoint url on WSO2 console
• Change baseUrl in plugin configuration to something else
• Deploy API again via sls deploy
• Change endpoint url on WSO2 console (should be the same as in the first deploy)

The workaround that I use is to delete the API and re-create again with "sls deploy"

Super important for production-grade APIs to enable and manage CORS headers of APIs deployed to WSO2 API Manager.

This issue will provide an opportunity to supply CORS headers as a part of serverless configuration.

Currently, wso2apim.user and wso2apim.pass support either 'hardcoded' or Serverless parameter syntax (which includes ${ssm:/...), however, it only can grab values from AWS Systems Manager -> Parameter Store.

However, some teams might want to preserve credentials in AWS Secrets Manager as a secret and the plug-in shall source its values and use it for execution. Use AWS Managed Keys here, for general use.

NOTE: AWS SDK code sample to retrieve secret values from AWS Secrets Manager. : https://docs.aws.amazon.com/code-samples/latest/catalog/javascript-secrets-secrets_getsecretvalue.js.html

The current setup only supports https and jms backend. The current WSO2 installation we are working with also has support for apigw private endpoints. To solve this we need to be able to populate the endpoint_type: 'lambda. I know this is custom to our installation so I propose a solution where we are able to override the endpoint_type

I propose the following changes to the serverless plugin:

wso2apim:
  apidefs:
    - myApi:
        backend:
          endpointType: lambda

Snippet captured in developer tools:

const example = {
   production_endpoints: { url: 'https://228u8q9451.execute-api.eu-west-1.amazonaws.com/dev', endpoint_type: 'lambda', 
   template_not_supported: false },
   endpoint_type: 'lambda',
};

example:

backend:
  http:
    baseUrl: !ImportValue my-not-existing-stack export

Results in:

Production URL | org.mozilla.javascript.Undefined@674ee6cc
Sandbox URL | org.mozilla.javascript.Undefined@674ee6cc

In some cases we face random errors when re-deploying an API with the same name after deleting it manually on WSO2

Steps to reproduce

• Deploy an API with "sls deploy"
• Open WSO2 panel and delete it manually
• Deploy the api again with "sls deploy"

More info

Sometimes it works well, sometimes the plugin output log seems to be ok, but I see the API wasn't plublished (it's in "created" state), and sometimes I got the following errors on the console:

[serverless-wso2-apim] Upserting Swagger spec for ****-flavio..
[serverless-wso2-apim] Upserting.. OK
{
  response: {
    code: 403,
    message: 'Forbidden',
    description: "You don't have permission to access the API with Id *****",
    moreInfo: '',
    error: []
  },
  responseCode: 403,
  responseHeaders: {
    date: 'Fri, 10 Mar 2023 12:32:43 GMT',
    'content-type': 'application/json',
    'transfer-encoding': 'chunked',
    connection: 'close',
    'set-cookie': [
      '******; Expires=Fri, 17 Mar 2023 12:32:42 GMT; Path=/',
      'AWSALBCORS=*******; Expires=Fri, 17 Mar 2023 12:32:42 GMT; Path=/; SameSite=None; Secure'
    ],
    'x-content-type-options': 'nosniff',
    'x-xss-protection': '1; mode=block',
    server: 'EAPIM Server'
  }
}
[serverless-wso2-apim] An error occurred while retrieving Invokable API URL, proceeding further.

OR

{
  response: {
    code: 500,
    message: 'Internal server error',
    description: 'Error while adding new API : null-[name_of_my_api_here]-v1 - Error while performing registry transaction operation',
    moreInfo: '',
    error: []
  },
  responseCode: 500,
  responseHeaders: {
    date: 'Fri, 10 Mar 2023 12:28:46 GMT',
    'content-type': 'application/json',
    'transfer-encoding': 'chunked',
    connection: 'close',
    'set-cookie': [
      'AWSALB=*****; Expires=Fri, 17 Mar 2023 12:28:45 GMT; Path=/',
      'AWSALBCORS=******; Expires=Fri, 17 Mar 2023 12:28:45 GMT; Path=/; SameSite=None; Secure'
    ],
    'x-content-type-options': 'nosniff',
    'x-xss-protection': '1; mode=block',
    server: 'EAPIM Server'
  }
}