serviceId problems when onboarding static API

[dmcknigh]

Describe the bug
When onboarding a static API, I've run into issues with the serviceId and the swagger docs.

According to the following documentation:
https://docs.zowe.org/stable/extend/extend-apiml/onboard-plain-java-enabler
"The serviceId uniquely identifies one or more instance of a microservice in the API ML and is used as part of the service URL path in the API ML Gateway address space."

In my case, suppose the base URL for my service is:
https://:/myapi/

I should be able to specify a serviceId according to this these naming rules shown in the docs for serviceId (by the way, I think these should say "serviceId", not "service_d_Id"):
"The same servicedId should only be set for multiple API service instances for API scalability.
The servicedId value must only contain lowercase alphanumeric characters.
The servicedId cannot contain more than 40 characters."

So, I should be able to specify "acmemyapi" as the serviceId, as per this example:

services:
  - serviceId: **acmemyapi**
    title: My API Service
    description: My API Service description
    catalogUiTileId: acmemyapitile
    instanceBaseUrls:
      - https://<host>:<port>/myapi/
    routes:
      - gatewayUrl: /api/v1/
        serviceRelativeUrl: /api/v1/
    authentication:
      scheme: zoweJwt
    apiInfo:
      - apiId: acme.myapi
        version: 1.0
        gatewayUrl: /api/v1/
        swaggerUrl: https://<host>:<port>/myapi/api-docs/swagger.json

When I do, I can see my onboarded API in the catalog and I can view the swagger documentation for it but when I try to exercise APIs from the embedded swagger, I run into problems.

For example, instead of having the swagger call this:
https://:7554/acmemyapi/api/v1/stuff

It calls this:
https://:7554/myapi/api/v1/stuff

and fails with:
{
"messages": [
{
"messageType": "ERROR",
"messageNumber": "ZWEAO404E",
"messageContent": "The service can not find the requested resource.",
"messageKey": "org.zowe.apiml.common.notFound"
}
]
}
and I can see this occurs because "myapi" is not the serviceId.

I notice that outside of the swagger I can successfully call this: https://:7554/acmemyapi/api/v1/stuff so API ML seems to be using the supplied serviceId correctly, just not with swagger.

The only way I can work around this is by changing the serviceId to be "myapi" but I should be able to name it anything that conforms to the documented rules.

[balhar-jakub]

Thanks for sharing the issue. Can you please share on which version of the Zowe you are?

It looks like some defect in the API Catalog as the static definition is correct.

Are you able to call to the service on https://:7554/acmemyapi/api/v1/stuff with some tool like curl or just from browser if it supports GET?

[dmcknigh]

Thanks for sharing the issue. Can you please share on which version of the Zowe you are?

Thanks for responding Jakub. I'm using Zowe v3.

It looks like some defect in the API Catalog as the static definition is correct.

Are you able to call to the service on https://:7554/acmemyapi/api/v1/stuff with some tool like curl or just from browser if it supports GET?

If I use the browser, curl or RestMan with a GET then this works:
GET https://:7554/acmemyapi/api/v1/stuff/resPath

However, if I use curl or RestMan with something other than GET (say DELETE) then it doesn't work.
DELETE https://:7554/acmemyapi/api/v1/stuff/resPath

[balhar-jakub]

Is there any specific message or status code in case of something else than GET?

If you are not ok with sharing the information publicly we can schedule a call or we have a ways within Zowe to share data for this purpose in non public manner.

Looking at what you see, this seems like some issue with API Catalog not the onboarding definition itself. If the onboarding failed, the GET request wouldn't work.

[dmcknigh]

When using RestMan with the serviceId and something other than GET, I'm seeing 403s.

Again, I can get around all of this by simply using a serviceId that matches my application name (i.e. "myapi"). Things work as expected in the embedded swagger as well as via other clients. With another serviceId, it at first seemed API calls would also work outside of the embedded swagger but it turns out only GETs work under those conditions. A call would be great - this week is pretty hectic for me though so maybe next week?

[balhar-jakub]

There are few questions that the 403 raises.

1. Do you use z/OSMF as authentication provider? It is default so unless you changed anything, you are.
2. Can you try changing

     authentication:
       scheme: zoweJwt

to

    authentication:
        scheme: httpBasicPassTicket
        applid: ${replace with APPLID for your service}

This looks as if the authentication method that is provided by the API ML is not accepted by the downstream service. If you use passtickets instead it should resolve the issue. The API ML will generate the passticket, if it received valid authentication e.g. JWT token or Client certificate or whatever it supports.

[dmcknigh]

I highly doubt this is an authentication issue as it works just fine for GET (which requires credentials) and it works just fine for everything else if and only if I make the serviceId the same as the application name.

[balhar-jakub]

To recap what I see from the information provided:

• The service is visible in the API Catalog and thus the onboarding of the service was succesfull.
• The GET call through the API Mediation Layer works properly
• The DELETE and POST calls fail and the return HTTP code is 403

The first two bullet points are proving that the service is onboarded and accessible from the API Mediation Layer, otherwise one of those statements would break.

The question is what changes for the DELETE and POST calls:

• Within browser the issue may be related to the CORS, but this shouldn't impact CURL

Can you verify whether the 403 code is coming from the API Mediation Layer or from the service?

• If it is coming from the service, then the authentication is off
• If it is coming directly from the API Mediation Layer, the issue is probably linked to the fact that the API Mediation Layer is trying to issue the JWT token for the service to consume and fails. This may lead to the issue with the z/OSMF which is why I asked whether z/OSMF is used as authentication provider.

[dmcknigh]

Can you verify whether the 403 code is coming from the API Mediation Layer or from the service?

It's from the API Mediation Layer. I can tell because the corresponding access log for my API doesn't get any POST, DELETE or PUT entries, only the GETs (so it's not getting to my service).

• If it is coming directly from the API Mediation Layer, the issue is probably linked to the fact that the API Mediation Layer is trying to issue the JWT token for the service to consume and fails. This may lead to the issue with the z/OSMF which is why I asked whether z/OSMF is used as authentication provider.

I didn't install or configure Zowe ML myself but I believe the underlying auth mechanism is z/OSMF. Again, the JWT tokens work just fine when using GET, and everything when the serviceId matches my application.