I wrote a sample ballerina code in choreo API to return x-jwt-header header value to the caller.
when I turn off the security for that API, the header value is not there in the request headers. Does it mean the API is unsecured?
I want to crate an unsecured API. I want to know whether the header values will be there or not?
When you disable the security, basically API is exposed without security to the consumers. Hence the API is unsecured. x-jwt-header is used to pass the enduser data to the backend services. If you don't provide an access token when invoking API, then it can't send the enduser information to the backend services. That's why you are getting the response without that header.
My intention is to create an HTTP API on Amazon API Gateway that writes a file to S3 using the PutObject action via the S3 API (without calling Lambda in between). This is the PutObject request syntax: https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html#API_PutObject_RequestSyntax
I'm not sure if this is technically possible and I'm getting a 403 Forbidden: ForbiddenException response in Postman.
So far I have:
Created the S3 bucket (with CORS configured)
Created the HTTP API in API Gateway (with CORS configured), with a 'putObject' POST action
Configured an integration on the HTTP API to https://[s3-bucket-name].s3.us-east-1.amazonaws.com
Create a Postman request to the HTTP API 'invoke URL', with 'Host' and 'x-apigw-api-id' set on the headers
The ForbiddenException obviously indicates a permission issue, either on the HTTP API or the S3 API behind it. I did configure a Cloudwatch Log Group on the HTTP API, which is showing no entries, so it seems that it's an HTTP API access issue.
I also suspect that I need to add Parameter Mappings to the HTTP API to pass in all of the necessary headers to the S3 putObject action.
My questions are:
Is this type of HTTP API integration direct to S3 possible?
What is the likely cause of the 403 Forbidden response from the service?
Would I use 'Append' Parameter Mappings in the HTTP API integration configuration to add the standard S3 API parameters (and avoid exposing them to the client)?
I managed to solve this myself. Answers to my own questions:
Is this type of HTTP API integration direct to S3 possible?
Yes. On my HTTP API I used an HTTP PUT integration that points to the S3 service endpoint (including the bucket name in the endpoint is incorrect).
What is the likely cause of the 403 Forbidden response from the service?
I didn't get the request working from Postman, however, when I made the request from the browser it worked. I had to create a Blob in Javascript before sending it as a request via navigator.beacon() to the HTTP API endpoint URL.
Would I use 'Append' Parameter Mappings in the HTTP API integration configuration to add the standard S3 API parameters (and avoid exposing them to the client)?
I did have to use Parameter Mappings to get the S3 PutObject request to work from API Gateway. My configuration is shown below.
Screenshot of Parameter Mapping configuration in my HTTP API
Edit: I have discovered a problem here with this approach: the HTTP API doesn't allow certain security-related headers to be added on the Parameter Mappings. I was trying to set header.x-amz-acl: 'bucket-owner-full-control' but I got the error message below:
Invalid mapping expression specified: Validation Result: warnings : [], errors : [Operations on header x-amz-acl are restricted]
It seems that modifying any security-related S3 API header isn't possible in the HTTP API. This is a major problem for calling the S3 API directly as it means that in order to function, the S3 bucket needs to be public.
I have a Lambda function which triggered by API Gateway service, however this API is accessed by front-end application, this application not requiring the users to login or sign up to use it.
However I would like to secure my API to allow only from my front-end application.
After my research I found that I can use custom authorization in API Gateway, this custom authorization will check the authorization header of the incoming request and validate it.
the question is, can I use Amazon Cognito for something like this(implicit grant type)?
if not what is the thing that the front-end application will send to me to be validated and how can I keep it always changeable, so no one can guess it?
Thank You.
You could check the headers, but if they're always the same, someone can send an HTTP request with those headers - from any client - and trick your Lambda into thinking it's coming from your UI.
Even if you generate a unique token every time your UI is loaded and include it in the headers, someone could take that token and send requests from another client as well.
You could build fancy JavaScript tricks to make headers more dynamic, but it would only make it harder to use your API from another client, not impossible.
I have a web service that users can sign into and so forth. I'd like to setup AWS API Gateway to allow the users to interact with the service via APIs. As the user management / password management is already in the system I don't want the user to have to go to another system.
I first looked at Cognito user pools but I couldn't automate fully the user creation / verification process, AWS in a support ticket said the user would have to verify the email separately. They then suggested to use a Lambda function to setup authorisation.
I've created a Lambda function and the API Gateway is authorizing however it looks like only one variable is sent for authorization, the Identity token. If I did this my Lambda function could find from my service that the key is valid but it's not really associated for a user.
What I'm after is a way to provide a user with a client id and passkey from my system (I can generate all of that), the user then does a request to the API Gateway end point with the client id and passkey, gateway sends the client id and passkey to the lambda function that calls my system for verification, Lambda returns the valid policy, API Gateway then sends the request to my service with either the client ID or some other identifier thats come back from the policy so my system knows the requesting client.
What would be the best way to achieve this without taking the user to a seperate system (Cognito)?
Turns out that your timing might have just been a Day or so early. What you would have experienced with custom authorizers before is the TOKEN authorizer. Today they noticed expanded support for custom authorizers with a new REQUEST authorizer type. The new REQUEST type supports a much expanded dataset for authorizing requests, such as request parameters, headers, query strings, and more. Check out the Custom authorizer types for further information.
I have been reading about OAuth and it keeps talking about endpoints. What is exactly an endpoint?
Come on guys :) We could do it simpler, by examples:
/this-is-an-endpoint
/another/endpoint
/some/other/endpoint
/login
/accounts
/cart/items
and when put under a domain, it would look like:
https://example.com/this-is-an-endpoint
https://example.com/another/endpoint
https://example.com/some/other/endpoint
https://example.com/login
https://example.com/accounts
https://example.com/cart/items
Can be either http or https, we use https in the example.
Also endpoint can be different for different HTTP methods, for example:
GET /item/{id}
PUT /item/{id}
would be two different endpoints - one for retrieving (as in "cRud" abbreviation), and the other for updating (as in "crUd")
And that's all, really that simple!
All of the answers posted so far are correct, an endpoint is simply one end of a communication channel. In the case of OAuth, there are three endpoints you need to be concerned with:
Temporary Credential Request URI (called the Request Token URL in the OAuth 1.0a community spec). This is a URI that you send a request to in order to obtain an unauthorized Request Token from the server / service provider.
Resource Owner Authorization URI (called the User Authorization URL in the OAuth 1.0a community spec). This is a URI that you direct the user to to authorize a Request Token obtained from the Temporary Credential Request URI.
Token Request URI (called the Access Token URL in the OAuth 1.0a community spec). This is a URI that you send a request to in order to exchange an authorized Request Token for an Access Token which can then be used to obtain access to a Protected Resource.
It's one end of a communication channel, so often this would be represented as the URL of a server or service.
An endpoint is a URL pattern used to communicate with an API.
An endpoint is the 'connection point' of a service, tool, or application accessed over a network. In the world of software, any software application that is running and "listening" for connections uses an endpoint as the "front door." When you want to connect to the application/service/tool to exchange data you connect to its endpoint
Endpoint, in the OpenID authentication lingo, is the URL to which you send (POST) the authentication request.
Excerpts from Google authentication API
To get the Google OpenID endpoint, perform discovery by sending either a GET or HEAD HTTP request to https://www.google.com/accounts/o8/id. When using a GET, we recommend setting the Accept header to "application/xrds+xml". Google returns an XRDS document containing an OpenID provider endpoint URL.The endpoint address is annotated as:
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/server</Type>
<URI>{Google's login endpoint URI}</URI>
</Service>
Once you've acquired the Google endpoint, you can send authentication requests to it, specifying the appropriate parameters (available at the linked page). You connect to the endpoint by sending a request to the URL or by making an HTTP POST request.
Short answer: "an endpoint is an abstraction that models the end of a message channel through which a system can send or receive messages" (Ibsen, 2010).
Endpoint vs URI (disambiguation)
The endpoint is not the same as a URI. One reason is because a URI can drive to different endpoints like an endpoint to GET, another to POST, and so on. Example:
#GET /api/agents/{agent_id} //Returns data from the agent identified by *agent_id*
#PUT /api/agents/{agent_id} //Update data of the agent identified by *agent_id*
Endpoint vs resource (disambiguation)
The endpoint is not the same as a resource. One reason is because different endpoints can drive to the same resource. Example:
#GET /api/agents/{agent_id} #Produces("application/xml") //Returns data in XML format
#GET /api/agents/{agent_id} #Produces("application/json") //Returns data in JSON format
The term Endpoint was initially used for WCF services. Later even though this word is being used synonymous to API resources, REST recommends to call these URI (URI[s] which understand HTTP verbs and follow REST architecture) as "Resource".
In a nutshell, a Resource or Endpoint is kind of an entry point to a remotely hosted application which lets the users to communicate to it via HTTP protocol.
The endpoint of the term is the URL that is focused on creating a request.
Take a look at the following examples from different points:
/api/groups/6/workings/1
/api/v2/groups/5/workings/2
/api/workings/3
They can clearly access the same source in a given API.
API stands for Application Programming Interface. It is a way for your application to interact with other applications via an endpoint. Conversely, you can build out an API for your application that is available for other developers to utilize/connect to via HTTP methods, which are RESTful. Representational State Transfer (REST):
GET: Retrieve data from an API endpoint.
PUT: Update data via an API - similar to POST but more about updating info.
POST: Send data to an API.
DELETE: Remove data from given API.
PATCH: Update data.