I know too little SOAP theory and need some help.
Imagine a web service and a client. There is also a gateway (facing the internet), which requests have to be relayed through.
The client authenticates with the gateway using a client certificate (transport security).
The gateway, in turn, uses message credentials to authenticate with the web service.
My question: Is it reasonable that the gateway, after getting the response from the web service, forwards the Security header to the client?
I'm thinking that it "feels" like that should be for the GW -> Web Service link only, since the client didn't use any message security in its request but am I right or wrong?
You're talking about three completely different layers of the network stack. Whether you encrypt your transport with HTTPS has absolutely nothing with whether or not you wish to protect your message payload with WS-I security.
Two good articles on WS-Security (at least from a Microsoft/.Net perspective):
http://msdn.microsoft.com/en-us/library/ms788756%28v=vs.110%29.aspx
http://msdn.microsoft.com/en-us/library/ms977327.aspx
In answer to your question: if you have a SOAP security header, then you ARE using WS-Security, and the client IS passing it to your web service link. Typically, this is transparent to both your client code and your server code; it's handled by the "middleware" in your .Net libraries.
Related
I am supposed to send a response from my web service with an STS header, but the service itself sits behind an AWS ALB which terminates SSL and sends the traffic on via http. This seems to be a common scenario and likely not limited to AWS, i.e. many LB's have the capability to terminate SSL as this is a very useful feature!
I have read through some messages from people who have already had this issue and have not seen any answers that seem anything other than a workaround - it seems to me to be a catch 22 situation, the LB doesn't send it as it isn't within its remit (according to one response from AWS support) and the target web server can't add it coz that header can only be added to https responses which the web server is not processing!
So my question is, is the sts header really that important if my web service can only respond on an https endpoint (no http enpdoint, not even a redirect)? Or is it still vulnerable to things like mitm attacks etc?
thanks in advance
I'm planning on setting up ALB (Amazon Load Balancer) for authentication. It'll sit in front of my client app and only forward authenticated requests with the access_token and user claim jwt's as headers, x-amzn-oidc-accesstoken + x-amzn-oidc-data respectively [0].
My client application will need to capture these forwarded headers and store them in localStorage for accessing other AWS resources in later requests (ex. S3).
If I'm the client app receiving the ALB request, how would I intercept these headers? Would they come in as a request or response?
[0] See step #10 in the diagram: https://www.exampleloadbalancer.com/auth_detail.html
These headers wouldn't be received by your client by default. The client makes a request to the ALB and, after the user is authenticated, the ALB would pass the headers to your backend.
If the client needs these headers, your backend could add them to the response headers and your client could then retrieve them there.
That being said, keep in mind that if you do return these headers to the client, that anyone using some simple browser debug tools can see the headers and then craft their own requests using them. It may be better add the functionality that you need to the backend so that no credentials are potentially exposed to users.
I want to secure a REST API with mutual authentication on AWS. This means, only clients with a specific client certificate should be able to access the API. What is the best way to secure a REST API on AWS with mutual authentication?
I know, there is client certificate support for API Gateway, but this is not what I am looking for. As far as I understand, this only authenticates Api Gateway against backend and is not able to authenticate clients to Api gateway.
Is Api Gateway, Load balancer or any other AWS product able to do mutual authentication to secure a rest API or do I need to implement this by my own?
You'll have to do this on your servers.
None of the services that terminate TLS and forward requests or connections to your app tier -- Elastic Load Balancers (Classic, Application, and Network), CloudFront, or API Gateway -- support TLS mutual auth.
Of course, a Network Load Balancer without TLS termination or a Classic Load Balancer in TCP mode will pass-through your payload, whatever it is, so either of these can be used in front of your servers, but the servers will need to handle all the TLS.
Also, your conclusion is correct that API Gateway's client certificates are not what you are looking for. They work as you described them.
As of 17th September, 2020, support for Mutual Authentication using TLS is available on AWS API Gateway: https://aws.amazon.com/about-aws/whats-new/2020/09/amazon-api-gateway-supports-mutual-tls-authentication/ . It can be used to authenticate clients calling an API on API Gateway.
I am looking to build an API orchestration layer using API Gateway and Lambda.
For my basic use case I want to have a Python script in Lambda that will just relay the request received at the API Gateway from the client (mobile app in this case) and call an external HTTPS service as the backend.
My question is:
Our mobile client uses client certificates to talk to our HTTPS endpoint today.
How do I go about intercepting that client certificate in my new API Gateway + Lambda setup?
Responded here. Copying the answer below for StackOverflow audience-
===
Unfortunately, API Gateway does not support client certificate validation from clients to API Gateway at the moment. We do, however, support client side SSL certificates for authentication by the backends.
Depending on your use-case, you can use various other options in API Gateway to authenticate/authorize your calls from the mobile client; eg API Keys, Custom Authorizers etc. The request from API Gateway to Lambda should already be encrypted.
Hope that helps,
Ritisha.
I have generated a JAX-WS web service with RAD 8.5 which automatically generated an endpoint for the service at "http:endpoint". I generated a client for the web service from the WSDL and added transport security (SSL) to the web service and added a secure endpoint using the following line of code in my client:
proxy._getDescriptor().setEndpoint("https:endpoint");
Everything seems to work fine. My question is do I need to do anything about the existence of the original endpoint ant "http:endpoint". This is an in-house web service so all of the apps which use it in house will use the secure endpoint, but is the availability of the unsecure endpoint a security risk for the web service? If so, what do I need to do to fix it? Any help would be appreciated.
I am not familiar with the Framework you are using, but there should be a configuration in your proxy to not allow http calls at all. If you have that option, turn it on so that your service only listens on port 443 (secure port).
An alternative would be to rewrite all http requests with https.