I am trying to implement ALB with OIDC for grant type Client Credentials.
I have given Issuer, Token endpoint, Client ID, and Client Secret, Authorization endpoint and User info endpoint in Listeners tab of ALB
But i get 400 invalid redirect_uri while trying to access the url.
We explored ALB for client credentials authentication but failed to implement that. After checking with AWS support team, we got confirmation that AWS ALB don't support Client credential authentication mechanism and supports only Authentication code flow.
We switched to AWS API gateway with lambda authoriser to implement client credential flow.
Related
I am setting up AWS ALB to authenticate using OIDC.
I am getting the below response: error=redirect_uri_mismatch&error_description=redirect_uri%20must%20match%20configuration
How should this be handled.
And for AWS ALB be able to authenticate is there anything special to be done in SFDC side
I have done following configurations
Created loadbalancer
Created user pool
created client with secret and enabled authorization code grant and openid scope
Configured authentication in loadbalancer with above created resource details
Created a listener rule with cognito authentication
Added needed configuration including scope as openid
Configured deny for unauthenticated requests
Problem is when I call the loadbalancer url with the id token or access token(as cookies) that is retrieved from another app client configured to application, The loadbalancer is returning 401
When I try the the configuration authenticate for unauthenticated request. I was able to successfully call the loadbalancer url where I am getting success response(loadbalancer will redirect to cognito login and after successfull login, loadbalancer will set the cookies).
The cookie that being set in the success scenario is being sharded
The cookie entry were like cookie_name-0 and cookie_name-1 (Which I do not know how to reproduce/recreate manually)
The below excerpt from aws docs confirms above sharding behaviour
The load balancer creates the authentication session cookie and sends it to the client so that the client's user agent can send the cookie to the load balancer when making requests. Because most browsers limit a cookie to 4K in size, the load balancer shards a cookie that is greater than 4K in size into multiple cookies. If the total size of the user claims and access token received from the IdP is greater than 11K bytes in size, the load balancer returns an HTTP 500 error to the client and increments the ELBAuthUserClaimsSizeExceeded metric.
How can I successfully call the loadbalancer url with the configuration for unauthenticated request as deny where I need to set the cookie manually?
Manually generated id token/ access token length are around 1k in size, why the loadbalancer retrieved token exceeds 4k in size?
Reference - https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#authentication-flow
https://aws.amazon.com/premiumsupport/knowledge-center/elb-configure-authentication-alb/
I think what you're trying to do is this: you're getting JWT tokens from cognito, and you want to use them to authenticate a web request through ALB that is using cognito authentication checks. Which is to say you're trying to find some way to generate the AWSELBAuthSessionCookie cookies yourself, or craft a call to /oauth2/idpresponse so that the ALB sets these cookies.
Short answer: You can't as of June 2021.
Here's the answer I got from AWS support on this issue, where I'm trying to get a python client to call through ALB with cognito JWT tokens:
As per the design, automated clients ( such as your python script ) will not be in position to utilize this ALB functionality. Further ALB will not accept any JWT tokens passed by clients in the request. This is to prevent any kind of replay attacks while communicating with load balancer. ALB will only initiate the authentication process if client request triggers authentication rule.
Seems the only way to get those ALB cookies set is by having a web browser open the auth page. Sorry. Cognito sucks. Open standards my ____.
Architecture : Strictly Serverless
Cloud - AWS
I've an application load balancer (internal) in front of a private api gateway and the requirement is to protect the load balancer endpoint with the enterprise SAML IdP.
Lambdas, S3 are allowed, but Route 53, EC2 are not whitelisted to use on this account.
Problem here is what would be the relay state (final target) here after SAML authentication ? As the internal ALB and the private api gateway endpoints arent visible outside the AWS landscape, I dont understand how to land on the alb endpoint once the user is authenticated with the enterprise IdP ?
Many thannks !
To use the on-premise enterprise IdP with your ALB, the IdP and ALB must be able to talk to each other (via VPN or Direct Connect). you would then establish a trust relationship between your AWS account and the IdP and define an authentication action in a listener rule on your ALB.
Elastic Load Balancing uses the OIDC authorization code flow:
When users direct requests to your ALB, the ALB authentication
action will check if the session cookie exists on the incoming
requests and check its validity. If the session cookie is set and
valid then the ALB will route the request to the proper target group
containing identity information (JWT token via X-AMZN-OIDC-*
headers) that backend instances can use to identify the user. If the
cookie is not present, the load balancer redirects the user to the
IdP authorization endpoint so that the IdP can authenticate the
user.
The IdP then authenticates the user and redirects the user back to
the load balancer with an authorization code. The ALB presents the
code to the IdP token endpoint to get the ID token and access token.
After the load balancer validates the ID token, it exchanges the
access token with the IdP user info endpoint to get the user claims.
The load balancer creates the authentication session cookie and
sends it to the client so that the client can use it on subsequent
requests.
Source:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html
https://aws.amazon.com/blogs/aws/built-in-authentication-in-alb/
I need to make a secure HTTP callout from Salesforce (using Apex) to AWS Lambda and I build my first version using AWS API Gateway. I realized I can get a client certificate from API Gateway (.crt) but this looks like it is only for AWS backend and is not meant to be for the HTTP request sent to API Gateway. What are my alternatives to establish a secure connection from outside AWS (Salesforce) to a Lambda function?
So far I've found this, which is a disappointing dead-end for now.
Like the link you posted says, API Gateway does not currently support MTLS. Other options for you to add security to the calls at the moment are:
IAM permissions, and here.
API Gateway custom authorizers.
Cognito User Pools.
If you need a custom domain associated with the API Gateway:
Go to Route53 and add your domain (new Hosted Zone), if you haven't done it already.
On AWS Certificate Manager, import or request a certificat for the custom domain you intend to use in your API Gateway endpoints.
Open the API Gateway dashboard and go to "Custom Domain Names". Click "Create a custom domain name" and, in the option "ACM Certificate (region)", select the certificate you generated/imported in item 2 above.
That's it, now you should be able to trigger your Lambda functions using API Gateway from a secure connection (HTTPS). Please note that, if you do this, API Gateway will refuse connections over insecure HTTP protocol.
Everytime I searched for Mutual Auth over SSL for AWS API Gateway I can only find MTLS between AWS API Gateway and Backend Services. But I'm looking to secure my AWS API Gateway endpoints itself with MTLS (client auth).
For instance, I have a backed service QueryCustomer which I have proxied through AWS API Gateway. Now I can put an SSL Cert on API Gateway but it's usual 1-way SSL. What I want to achieve is to have an MTLS with client auth where the consumer of APIs from AWS API Gateway first have to exchange their public certificates which we configure on the AWS truststores and AWS public certificates will be stored on API consumer end as well.
Now during the handshake as with other API Gateways and application servers should there be a property which says something like this AWS API Gateway endpoint 'requires client auth' so that only if API consumer's public cert is in API Gateway truststore should be authenticated to access the endpoint, otherwise just throw normal SSL handshake error.
Can someone advise if this is achievable on AWS API Gateway?
This is not currently available from API Gateway, but we have had requests from multiple customers for this feature. Unfortunately, I can't comment on ETA or availability.
23 September 2020
AWS now supports mutual TLS
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-mutual-tls.html
Also we can now disable the execute-api-endpoint.
aws apigatewayv2 update-api \
--api-id abcdef123 \
--disable-execute-api-endpoint
To use mutual TLS, create a truststore of X.509 certificates that you trust to access your API. The certificates can be from public or private certificate authorities. Certificates can have a maximum chain length of four. You can also provide self-signed certificates. The following are supported:
SHA-256 or stronger
RSA-2048 or stronger
ECDSA-256 or stronger
API Gateway validates a number of certificate properties. You can use Lambda authorizers to perform additional checks when a client invokes an API, including checking if a certificate has been revoked. API Gateway validates the following certificate properties:
Validation Description
X.509 syntax
The certificate must meet X.509 syntax requirements.
Integrity
The certificate's content must not have been altered from that signed by the certificate authority from the truststore.
Validity
The certificate's validity period must be current.
Name chaining / key chaining
The names and subjects of certificates must form an unbroken chain. Certificates can have a maximum chain length of four.