I'm using serverless framework to create an api gateway. I did not specify any apikeys under provider/apiGateway, yet when I navigate to the API in aws console I see that an apikey is required. Do I need to explicitly state that an apikey is not required somewhere in the serverless.yml file?
Related
My stack is referencing a resource that has been deleted (long story short it's been deleted because we use Serverless for API GW and async routes at the same time).
When I look at CloudFormation I see the resource and its ID. However the resource does not exist anymore. Is there a way to remove this reference or update it? Note that the new resource was created separately using AWS CLI, not through CloudFormation updates.
Here's an image to the resource I am talking about
This command aws apigateway get-authorizers --rest-api-id however does show the correct ID for the authorizer. It's the cloudformation console Resources tab that shows it outdated.
I solved this by using the handy DefinitionBody property under Properties. You can define your API Gateway methods, authorizer and other things using OpenAPI specification. Just include the correct syntax under that property DefinitionBody.
The way I found out my DefinitionBody was by exporting an existing API gateway from the API Gateway console (API GW -> Stages -> choose stage and click on Export tab, choose Export as Swagger + API Gateway Extensions) and modifying it according to my needs. You can see the screenshot of this tab in my answer here: Defining authorizer and using it in API Gateway using Open API
OpenAPI docs can be found here: https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md
Recently I had a contracted company do some work and part of that was to create an API Gateway. When I create one I add a stage with usage plan so I can add an API key. They did not. So now when I attempt to hit it with Postman it is always reporting "forbidden".
Is a stage required for the API Gateway to be usable by Postman?
Found the answer in the docs at AWS here: Publishing REST APIs for customers to invoke
It states:
Simply creating and developing an API Gateway API doesn't automatically make it callable by your users. To make it callable, you must deploy your API to a stage.
So YES, a stage is required for the API Gateway to be usable by Postman.
I have set up an API GW with multiple resources, one requiring an API Key and the other one not requiring an API Key as shown below.
The Swagger resource is configured to not need an API Key, while the other resource has been set up to require one.
The API is deployed to a stage using a usage plan which has an API Key attached to it.
With this setup, however, I see that unless I pass a valid key in the header for the Swagger resource the call fails with 403 forbidden.
Did I miss a step somewhere?
For example, Azure API Management service allows the creation of an API "proxy" front end and the ability to create an api version such as
https://baseapi.com/apiName1/v1
Here is screenshot of that in Azure platform.
https://learn.microsoft.com/en-us/azure/api-management/api-management-get-started-publish-versions
Does AWS API Gateway RestAPIs allow this type of versioning natively?
If it does, how can I setup for example "v1" of a restAPI?
And if the AWS RestAPI "Stage" is the way to accomplish this, how would I still support the idea of creating stages per environment, while still doing versioning? To me stage seems more associated with environments, whereas versioning is a completely separate concept.
Note: The rest APIs are private
First limitation of private APIs from the documentation is the following:
Custom domain names are not supported for private APIs.
This limits what you can do with API Gateway to support multiple versions.
Run an API Gateway per version - This option grants you complete separation between API versions, however, unfortunately you will need to call a separate endpoint per API.
Deploy a single private API Gateway containing all API versions - This option scopes everything to a single endpoint but as a limitation could become quite complex and hard to manage depending on the number of verbs.
Hopefully in the future this feature from custom domains detailed below will be added.
Previous Answer - Before known using Private API
This can be done in API Gateway through the combination of stages and custom domain configuration.
If you deploy each version of API Gateway to either its own stage i.e. v1, v2 stage you have seperated the schema and actions between the versions.
Alternatively you can have a separate API and stage for each version of your specific API.
Then create a custom domain name for your API endpoint, under base path mappings you can map a specific subfolder v1 to the API and select the v1 stage in your API Gateway endpoint.
I have an existing Web API that I migrated to AWS using API Gateway and Lambda functions. However, I'm wondering how I can make use of AWS API Gateway's custom authorizer feature. My existing authorization framework is OAuth and I used ASP.Net Identity for user management. I generate bearer tokens and used the 'Authorized' attribute in my API Controllers for security. How can I do the same in AWS API gateway since I cannot change my framework cause I already have existing users. Thank you.
If you haven't already, check out the docs for custom authorizers: http://docs.aws.amazon.com/apigateway/latest/developerguide/use-custom-authorizer.html
You should be able to write the Lambda function to replicate the authorization logic used in your existing service. Then think about how you want to model permissions in terms of an IAM policy (which is the output of the authorizer). If you want simple allow|deny then you can return an IAM policy from the authorizer that says Allow * or Deny *. Or you can add fine grained permissions if you want.