WSO2 API Cloud Issue - wso2

I hope you can help me with WSO2 API Cloud.
I have a sample app that adds two float numbers in WSO2 app cloud. Below are the details:
Endpoint: http://jab7180-sample-calc.wso2apps.com/client/calculate/add/10/20
Output:
30.0
My problem is I'm having problem calling my API after publishing to WSO2 API Cloud. The response body is no content, response code is 0, and response header is no response from server.
This is how I published my API in WSO2 API Cloud using the endpoint above:
Name: calculator
Context: /compute
version: 1.0.0
visibility: public
URL pattern: client/calculate/add/{x}/{y} where verb is GET.
Production Endpoint: http://jab7180-sample-calc.wso2apps.com
Subscription tiers: Unlimited

We found the issue. There is a problem with defining URI params with single-character parameters. As a workaround, please define your resource with different parameters.
Ex: /client/calculate/add/{xx}/{yy}
Also, you have to set the "Produces" attribute for the resource as "application/xml" since the default value is "application/json" and is not supported by your backend.
Please refer the screenshot below and define your API resource, and republish the API.

From https://docs.wso2.com/display/APICloud/Subscribe+to+and+Invoke+an+API
If you cannot invoke the API's HTTPS endpoint (causes the
SSLPeerUnverified exception), it could be because the security
certificate issued by the server is not trusted by your browser. To
resolve this issue, access the HTTPS endpoint directly from your
browser and accept the security certificate.

Related

WSO2 API Manager 4.1.0 - JSON2XML policy not working

There is Hello World API is onboarded into WSO2 APIm 4.1.0 GA release. I added JSONtoXML policy from policy List to Response flow by follows steps provided in WSO2 APIM Doc and deployed in DEV portal by clicking save and deploy option
JsonToXML.j2 - Policy file Content:
<property name="messageType" value="application/xml" scope="axis2"/>
Policy in publisher:
When I Try out this API in DEV portal or via postman, it is still giving response as JSON format, not in XML
WSO2 DEV Portal - TRY IT OUT:
POSTMAN:
As suggested below - API Gateway Sequence Hit:
CURL Request like below:
curl -k "https://127.0.0.1:9443/api/am/gateway/v2/sequence?apiName=HelloWorld&version=1.0.0" -H "Authorization: Bearer eyJ4NXQiOiJOMkpqTWpOaU0xxx"
Note: valid token is passed in above curl Request, same token used when calling apim url which gives backend response
Did I miss anything or if not why this policy enablement is not working in WSO2 APIM? Please clarify on the same
I just followed the same flow to the Pizzashack API in the APIM 4.1.0 GA pack. It worked as expected without any issue.
Can you confirm that you have created a new revision after this policy addition and deployed it in the gateway?
If you have done that as well, shall we use the gateway Rest API and check the sequences for the HelloAPI. There should be a new sequence with the above policy attached.
Edit:
If the sequence call does not contain a response, that means the policy has not been deployed properly. To apply the policy properly, create a new revision and deploy that revision in the gateway.
As suggested by #Lakshitha, i followed below STEPS and working as expected.
Restarted WSO2 APIm standalone server
Added policy in GET resourse of HelloWorld API
Deployed as new Revision
In DEV Portal, API tested via TRY OUT option and got XML response now
Gateway API also given sequence response like BELOW

GCP How do I restrict requests to my API Gateway to only being accepted from 1 domain for security concerns?

I have a GCP Cloud Function in a web app. I initially ran this by requiring authentication through a service account. I ran my app locally by authenticating with my service account's json file credentials. I will soon by deploying this app to a third party VPS server. I don't want to upload my service account credentials to a third party VPS so I set up an API Gateway. This works without requiring my credentials. My config file for the API Gateway looks like this:
swagger: '2.0'
info:
title: api-gateway
description: API Gateway
version: 1.0.0
schemes:
- https
produces:
- application/json
paths:
/v1/hello:
get:
summary: Hi Service
operationId: hello-v1
x-google-backend:
address: <CLOUD_RUN_URL>
responses:
'200':
description: OK
I just run curl https://{gatewayId}-{hash}.{region_code}.gateway.dev/v1/hello with my correct values replacing the placeholders and my cloud function actually ran without requiring any credentials.
At first I was glad that it worked, but then it occurred to me that I'm just trading 1 vulnerability with another. I can now call a function without authenticating lol. So is there at least a way to only allow my cloud function to be called through my api url when it is accessed from a particular caller domain. That way only my VPS could call the function through this link? I don't want to do this with a cors policy in my function because the function would technically still run and therefore run up my GCP bill.

AWS: Always Getting `"message": "Forbidden"` from API Gateway for Endpoints that Require an API Key

We have deployed a Chalice app to AWS, and we are receiving the following response when calling endpoints that require an API Key:
{
"message": "Forbidden"
}
Endpoints that don't require an API Key can be called without any issues.
What's strange is that we used to be able to call the endpoints that require an API Key without any issues, so we're also considering a Chalice or AWS update to have caused the issue.
We're using Postman are passing the API Key as a Header in the request:
x-api-key: Our API Key's Value.
We're also not getting any logs in CloudWatch, presumably because the endpoints aren't actually getting called due to the issue. AWS is blocking the request before it even reaches our endpoint.
Our API Key has been configured as follows:
API Key:
ID: Our key's ID.
Name: Our key's name.
API key: Our key's value.
Enabled: Enabled
Associated Usage Plan:
ID: Our plan's ID.
Name: Our plan's name.
Throttle: No throttling.
Quota: No quota.
The API Key and Usage Plans look properly configured, so we assume the issue is not with the API Key itself.
From the "Troubleshoot API Gateway 403 Forbidden errors" documentation:
If the API Key was invalid (or, we assume, incorrect), we would be getting the below message instead:
"Invalid API Key identifier specified"
However, we are getting the generic "Forbidden" error instead:
"Forbidden"
The documentation only lists three possible causes for this error:
The request is blocked by web application firewall (WAF) filtering when AWS WAF is activated in the API.
When invoking a private API from within an Amazon Virtual Private Cloud (Amazon VPC) using public DNS names, the "Host" or "x-apigw-api-id" header is missing in the request.
The caller uses the default execute-api endpoint to invoke a REST API after disabling the default endpoint.
We believe that none of the above reasons apply to us due to the following:
We don't have a WAF (nor Web ACL) configured in our API Gateway.
We're not invoking a private API from within an Amazon VPC.
We did not disable the default endpoint and are instead using the default Invoke URL.
Did we miss something, or could this be a Chalice or AWS issue?
We found the source of the issue.
Apparently, the Usage Plan that our API Key was tied to was configured for another API.
All we had to do was add our API to the Usage Plan's Associated API Stages.

WSO2 IS - How to get custom claims from WSO2 Identity Server via user-info rest service

I'm trying to get custom claims from Identity Server via user-info service in WSO2 Identity Server Version 5.3.0.
This is the invocation to the user-info service:
GET https://host:9443/oauth2/userinfo?schema=openid HTTP/1.1
And the response only contains the subject info:
{
"sub": "user#carbon.super"
}
How can I get all the claims of the user via user-info service?
Thanks in advance.
Did you add custom claims as requested claims in Service Provider configurations?
You need to define the claims that should be included in the response. That should be configured in the Claim Configuration of the Service Provider. You can refer (1) for more information.
(1) http://dinukshaish.blogspot.com/2017/02/getting-started-with-oauth-20-using.html

Is IAM Authentication to API Gateway via Cloudfront possible?

Is it possible to use IAM Roles Authentication to an API Gateway endpoint via Cloudfront?
Here is a basic use case:
/api -> API Gateway
/* -> S3 HTML/Javascript
I've been able to get this working without Authentication similar to the following setup:
https://www.codeengine.com/articles/process-form-aws-api-gateway-lambda/
How do you add CloudFront in front of API Gateway
Of particular note is to NOT forward the HOST header from Cloudfront...
When I enable IAM Authentication in the API, I receive the following response:
OPTIONS: 200
POST: 403
{"message":"The request signature we calculated does not match the
signature you provided. Check your AWS Secret Access Key and signing
method. Consult the service documentation for details.\n\nThe
Canonical String for this request should have
been\n'POST\n/test/create\n\naccept:application/json\ncontent-type:application/json\nhost:*****.execute-api.ap-****-2.amazonaws.com\nx-amz-date:20170328T044253Z\n\naccept;content-type;host;x-amz-date\na57656a9def890d9de2b637789f7e5917f4b2823765ae0122087d08f89a97380'\n\nThe
String-to-Sign should have
been\n'AWS4-HMAC-SHA256\n20170328T044253Z\n20170328/ap-southeast-2/execute-api/aws4_request\ncae7fd6b4cabd593ad2ec6ce7091c94dc8cba306e81da95d567873eea8f981a5'\n"}
The host in the Canonical String is that of the API Gateway...
As noted in comments, you'll run into difficulties due to the change of the HOST header. In theory signing the request with the API Gateway exceute-api domain as the value of HOST in theory should work, assuming CloudFront is not changing the payload in any other way.
This is a difficult one to debug, I wrote a blog here going into more detail on the solution, hope it helps someone else. Thanks #Bob for putting me on the right track: https://www.rehanvdm.com/serverless/cloudfront-reverse-proxy-api-gateway-to-prevent-cors/index.html