The OAuth plugin in its current state fails to grab any valid JWK. The reason for this is that it evaluates the wrong property on the keys object. Here is the getJWK() function in its current state:

function getPEM(decodedToken, keys) {
    var i = 0;
    debug('jwk kid ' + decodedToken.headerObj.kid);
    for (; i < keys.length; i++) {
        if (keys.kid == decodedToken.headerObj.kid) {
            break;
        }
    }
    var publickey = rs.KEYUTIL.getKey(keys.keys[i]);
    return rs.KEYUTIL.getPEM(publickey);
}

Note how this function tries iterating over keys at its root, and accessing keys.kid, but keys is not iterable at its root, nor does it have any properties apart from keys. The structure of keys is (in my case) as follows:

{
    "keys": [
        {
            "kty": "RSA",
            "alg": "RS256",
            "kid": "99gMqQi7UIfDqij_JX_RoNkC-bU-vlGQGwXoKWbGoes",
            "use": "sig",
            "e": "AQAB",
            "n": "gDf_fZFQrmZw14aHvJWb2SaQ30XBzYqu40SRFBgGGg-2TGRJD5rKbehPWGfZpYw2UEp2-aYw2-pFzAJF4SfFo3IjsU2tM5kEFCUreJdDW0II7ZaGaxXFcyteX7ULGErdZkX8w98Zay8abOegJpsDr8UBgJ0wNIpXx_nEe_ttrj3XexJ9ximJkrHvg4X9_mYhghOO5BbernrjEkeZo1ioQj4Q_H-Cn-DUwODr9b6NJ46qvo1UrKij13Q4lNNftUgvRQy0wNCUUNNgAZpVJOruMS9DUdCv5MGjgVsW7_KLHfUj0-di19XSRrQHyK_wh22gqzUoPaj-rVmqzQ1itkELWw"
        },
        {
            "kty": "RSA",
            "alg": "RS256",
            "kid": "luIheUMdlhacSF0zk2-tNDA7qd3sns_l21arS59FX-8",
            "use": "sig",
            "e": "AQAB",
            "n": "xh8tmPpzytiEfmBOn1oA20hH2TSLTcRdZprXK4tKuWnhiBz__E_qGusFf8lAA9tN9BZM_YptLRd6fjKjbRv1D8XUEqgwQoUVI9oNK-WvaZL0ZT1AIzbP5wUN-5uxOhwczp-nQ_R7IYjED_v1snHQRNf4W-8295UzjdHwTr29cw2wdLDsnSvgtwpHd9zpcCXaFkQ6-g9M8OariL0jL7KPCUSpb1e9E-Swmq6af2E8Peq9B68Ecys2Jf1iw24oIncS-vg9ZGuq4F5MASKmLVDjbBIrU2lQ3muK6JrakKQYxqVMnaS6vR-U3bEp7CcuGo-sfRZTZT6RYusJSy2GNLutYw"
        }
    ]
}

Thus, the function should iterate over keys.keys, or keys should be populated by the keys object in this JSON object.

I've already submitted a PR that resolves this issue, and adds support for situations like https://www.googleapis.com/oauth2/v1/certs . This PR can be found here: #87

Update quota README with

https://docs.apigee.com/release/notes/edge-microgateway-release-notes-0#3.0.9

useDebugMpId: true

and failOpen properties

Is it possible to update healthcheck plugin to include the edgemicro version too.
Once it is deployed to cloud, sometimes its hard to get what is the version number of microgateway.

So please include that in the healthcheck response

@srinandan @keyurkarnik

Update oauth plugin README with

1. useUpsteamResponse
   https://docs.apigee.com/release/notes/edge-microgateway-release-notes-0#3.0.7

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  gracePeriod: 10
**useUpstreamResponse: true**

2. failOpen
   https://docs.apigee.com/release/notes/edge-microgateway-release-notes-0#3.0.8

If you send a request from an IP address and that IP is not listed in the allow list, then this plugin still allows the request to continue. It should fail in this instance.

Can we update this plugin, lines 24 - 26, as shown below?
https://github.com/apigee/microgateway-plugins/blob/master/accesscontrol/index.js#L24

if (scanIP(config.allow, sourceIP)) {
allow = true;
} else {
allow = false;
}

We should also update lines 30 - 33 as shown below.
https://github.com/apigee/microgateway-plugins/blob/master/accesscontrol/index.js#L30

if (scanIP(config.deny, sourceIP)) {
debug ('deny incoming message');
deny = true;
} else {
deny = false;
}

The plugin notes stated that EM will extract the client_id from the JWT.
Sample Log :
2019-12-11T22:00:50.582Z plugin:extauth Found JWK
2019-12-11T22:00:50.590Z plugin:extauth JWT Expiry enabled
2019-12-11T22:00:50.631Z plugin:extauth JWT is valid
2019-12-11T22:00:50.632Z plugin:oauth missing_authorization
2019-12-11T22:00:50.632Z plugin:oauth auth failure 401 missing_authorization Missing Authorization header { 'user-agent': 'PostmanRuntime/7.19.0',

AllowAPIKeyOnly and allowOAuthOnly are configuration flags that should restrain where to look for authorization details in an incoming request, i.e. headers "x-api-key" (for a consumer key) or "authorization" for an Apigee OAuth token.
allowNoAuthorization and allowInvalidautorization are used to specify if oauth plugin should return a 401 when the authentication details are missing (for the first flag) or invalid (second flag), or let the request go.
I believe the first two flags (where to get authN details from) should not impact the behavior of the second set of flags (what to do with the authN details). However, setting one of the two flags from the first set to true breaks the behavior of allowNoAuthorization. De facto, no matter what is the value of allowNoAuthorization, it behaves as if it's set to "false".

This exception gets generated when CORS plugin is enabled.

{"message":"Invalid value \"undefined\" for header \"Access-Control-Allow-Origin\""}

Perhaps these lines could be within a try and catch block. https://github.com/apigee/microgateway-plugins/blob/master/cors/index.js#L20

	  if(req.method == 'OPTIONS') {
	    res.setHeader('Access-Control-Allow-Origin', accessControlAllowOriginValue);
	    res.setHeader('Access-Control-Allow-Methods', methods);
       	    res.setHeader('Access-Control-Allow-Max-Age', maxAge);
	    res.setHeader('Access-Control-Allow-Headers', allowHeaders);
	    res.end();
	  } else {
        res.setHeader('Access-Control-Allow-Origin', accessControlAllowOriginValue);
	    next();
	  }

Lines #137 and #141

The request object has all header names in lower case, but the code uses Capital case.

req.headers['Content-Type'] = ...

This will result in the same header being appended. I.e. it ends up with 'Content-Type' and 'content-type'.
The fix should be to assign the header using the lower-case name.

n.b. setHeader(.., ..) method is not available on the IncomingRequest type.

If disable !== false, the request handlers don't accumulate the request.

Therefore, when the plugin is disabled by the 'x-apigee-json2xml-disable' header, it results in the payload not being sent to the target server.

I don't think this is intentional. Disabling the plugin should simply not change any behaviour.

When it's disabled, it should still need to accumulate the request payload.

Hi,

I'm facing an issue with the cors plugin (edgemicro : 2.5.8).

As explained here https://developer.mozilla.org/fr/docs/HTTP/Access_control_CORS, all responses from the server following a preflight request need the Access-Control-Allow-Origin header. But currently the cors plugin only adds it for OPTIONS method.

I'll try to provide a PR shortly.

Have a nice day :)

In microgateway, we have plugin sequence as

- cors
- oauth

Whenever options request reaches microgateway, the response headers are set and then the request is forwarding to oauth plugin which is wierd
As per this line it should end the options request right there. But it is being sent to next plugin

There are two ways to disable API Key caching in EM:

1. set the cacheKey equal to false in the EM config file

apikeys:
  cacheKey: false

2. include the following request header.

Cache-Control: no-cache

The 2nd option works, but the first option does not work.

The cacheKey variable is set to false by default, so apikey caching should always be disabled. The reason it is enabled is because the cacheControl variable is "undefined" when there is no cache-control header and !cacheControl changes the value to true, which is why caching is always enabled.

                if (cacheKey || (!cacheControl || (cacheControl && cacheControl.indexOf("no-cache") < 0))) { 

We should update this code to remove the !cachedControl condition.

In my edgemicro instance, I'm using a JWK set to authorize my requests. I've fixed the issues with verification at #88 locally on my edgemicro instance using the code from #87 , but I still can't seem to get past authorization. After stepping through the oauth plugin's code manually, I see that the issue is with the checkIfAuthorized() function - at present, it's looking for decodedToken.api_product_list and denying requests that don't have that object. Because I'm using a third-party JWT and JWK set (Okta), my requests are being denied at this point for not having an api_product_list property. My first thought was that I should add a claim on my token to populate api_product_list in payloadObj, but that's not where the plugin is currently looking. Is this the intended approach? Is there supposed to be a fourth field apart from header, payload, and signature named api_product_list to authorize against, or is the oauth plugin code incorrect and the reference should be to decodedToken.payloadObj.api_product_list? If that's the case, I'm happy to resolve the issue myself and submit a PR with the fixed code. If not, how do I add an entire extra section to a JWT without violating standard JWT conventions?

Follow the document of Rewriting URL in plugins, and sample eurekaclient, rewriting is broken for the following version
microgateway: 3.2.1
NodeJS: v14.17.0
in onrequest() overwriting req.targetHostname, req.targetPort, req.targetPath, req.targetSecure. The microproxy does not overwrite the URL deployed in edge.
Here are some logs:
gateway:main selected proxy https://api.example.com:443/wsdl with base path /v1/edgemicro_test for request path /v1/edgemicro_test
...
gateway:main targetRequest xxxxx GET https://api.example.com 443 /wsdl
...
plugin debug shows
req.targetHostname: test.example.com
req.targetPort: 443
req.targetSecure: true
req.tartetPath: /wsdl
...
gateway:main targetRequest error.... Hostname/IP does not match certificate ... Host: api.example.com...
which is the original target URL deployed in edge instead of the overwritten URL.

I am using accumulate plugin before my transform plugin so that all chunks of data can recieved and passed to another custom plugin, but it is passing null data which is causing failing of next plugin.

I'm trying to config microgateway to accept a third party JWT via plugin extauth.

The request passes extauth plugin without issue but fails in oauth plugin with 403 error below:

  plugin:extauth plugin onrequest +17s
  plugin:extauth Found jwt kid: thejwtkid +1ms
  plugin:extauth Found JWK +0ms
  plugin:extauth JWT Expiry enabled +6ms
  plugin:extauth JWT is valid +45ms
  plugin:oauth validating jwt +0ms
  plugin:oauth product only: false +23ms
  plugin:oauth no api product list +0ms
  plugin:oauth** auth failure 403 access_denied  { host: 'host.domain.name',..}

What failed is the following check in oauth.checkIfAuthorized;

    if (!decodedToken.api_product_list) {
        debug('no api product list');
        return false;
    }

The oauth plugin is looking for api_product_list property in decoded JWT. Well, doesn't this defeat the purpose of using extauth plugin unless there is something wrong in my setup? That property won't exist in third party JWT.

Any suggestions?

Thanks

Looking at the quota plugin, the check for local mode appears reversed:

https://github.com/apigee/microgateway-plugins/blob/master/quota/index.js#L61-L65

For the 'if' test clause to match the debug message it should be reversed: !process.env.EDGEMICRO_LOCAL or process.env.EDGEMICRO_LOCAL != "1"

This refactoring between 3.0.11 and 3.0.12 introduced a memory leak, through the dynamic creation of debug instances. See debug-js/debug#678, and the possible fix currently waiting in debug-js/debug#740. This impacts apigee-internal/microgateway in version 3.1.0 and above.

A possible fix is to locally cache the debug instance created for each component, instead of creating a new one for each request.

It would also be possible to pass the existing debug instance instead of the component name as the parameter to checkIfAuthorized(), but I guess it's less abstract.

the oauth plugin should have more debug statements (esp when the token is rejected).

Hi Team,

Was going through the monitor plugin and I would like more info/documentation on how to use it. Am running a custom build of the microgateway image.

Any pointers will be appreciated.

Regards,

Moses.

[feature request]

In apikeys (and same code in oauth and oauthv2)

A distinct expiration time is known but not passed to the cache. This could benefit

• less IPC transfer for objects that are expired
• simpler cache retrieval logic (memored already checks the TTL on retrieval)
• proactively evicting stale JWTs from cache making room for more active apiKeys

Is is possible bypass some urls match some patterns, e.g. we want bypass /healthcheck url

Please see here for details: https://community.apigee.com/questions/33149/emg-jwt-token-validated-against-both-api-proxies-a.html#answer-33336

Add a README for the cloud-foundry-route-service-plugin and describe how it works, how to configure it and when to use it.

In the function verify in the index.js file of the OAuth package, the variable err is not defined and as such throws an unhandled exception in the console.warn(), for example on line 250.

When oauth.allowAPIKeyOnly is true, oauth plugin returns a 500(Server error) response code while it should return a 401 (Unauthorized) response code.

Scenario: Oauth is enabled.

A product is created with the resourcePath set to /**

Then MG should allow both of these conditions:

1. http://localhost:8000/basePath
2. http://localhost:8000/basePath/

Only 2 works.

several variables are defined instance level which causes concurrency issues.

For example. if a request is disabled by 'x-apigee-json2xml-disable' header, disable=true will get set and thereon apply to all requests.

These variables should be scoped to the request object so that they only apply to the specific request thread.

It appears the oauth plugin does not validate scopes. The plugin has access to the scope information (in the access_token) and from /products. It should be relatively easy for the plugin to validate.

Hi, we have a requirement to expose certain endpoints without apikey/oauth validation.
The validation of whether or not to skip a certain URL is not the issue, we can do that in a separate plugin. The question is how can we tell the oauth plugin to skip execution?

I propose introducing an attribute on the request (req.skip, for example) and adding a simple check if (req.skip) next() to the oauth plugin.

1. is there another way to achieve this that I'm not seeing?
2. can we get this into the oauth plugin as I can't just fork & rename the oauth plugin (because the injected plugin configuration is dependent on the plugin name)

Regards,
Philipp

How can I run the tests of the oauth plugin? If I run npm test they are not started.