we have web api deployed on service fabric cluster. When that api is getting called from javascript it pops up the select certificate window in browser. Can you please suggest how to avoid that? We are allowing to make calls to web api using bearer token.
while binding ssl cert, this field was being set - clientcertnegotiation=enable
And that was causing that issue
Related
Prerequisites
I have two Cloud Run services a frontend and a backend. The frontend is written in Vue.js/Nuxt.js and is using a Node backend therefore. The backend is written in Kotlin with Spring Boot.
Problem
To have an authenticated internal communication between the frontend and the backend I need to use a token thttps://cloud.google.com/run/docs/authenticating/service-to-service#javahat is fetched from the google metaserver. This is documented here: https://cloud.google.com/run/docs/authenticating/service-to-service#java
I did set it all up and it works.
For my second layer of security I integrated the Auth0 authentication provider both in my frontend and my backend. In my frontend a user can log in. The frontend is calling the backend API. Since only authorized users should be able to call the backend I integrated Spring Security to secure the backend API endpoints.
Now the backend verifies if the token of the caller's request are valid before allowing it to pass on to the API logic.
However this theory does not work. And that simply is because I delegate the API calls through the Node backend proxy. The proxy logic however is already applying a token to the request to the backend; it is the google metaserver token. So let me illustrate that:
Client (Browser) -> API Request with Auth0 Token -> Frontend Backend Proxy -> Overriding Auth0 Token with Google Metaserver Token -> Calling Backend API
Since the backend is receiving the metaserver token instead of the Auth0 Token it can never successfully authorize the API call.
Question
Due the fact that I was not able to find any articles about this problem I wonder if it's simply because I am doing it basically wrong.
What do I need to do to have a valid Cloud Run Service to Service communication (guaranteed by the metaserver token) but at the same time have a secured backend API with Auth0 authorization?
I see two workarounds to make this happen:
Authorize the API call in the Node backend proxy logic
Make the backend service public available thus the metaserver token is unnecessary
I don't like any of the above - especially the latter one. I would really like to have it working with my current setup but I have no idea how. There is no such thing like multiple authorization token, right?
Ok I figured out a third way to have a de-facto internal service to service communication.
To omit the meta-server token authentication but still restrict access from the internet I did the following for my backend cloud run service:
This makes the service available from the internet however the ingress is preventing any outsider from accessing the service. The service is available without IAM but only for internal traffic.
So my frontend is calling the backend API now via the Node backend proxy. Even though the frontend node-backend and the backend service are both somewhat "in the cloud" they do not share the same "internal network". In fact the frontend node-backend requests would be redirected via egress to the internet and call the backend service just like any other internet-user would do.
To make it work "like it is coming from internal" you have to do something similar like VPN but it's called VPC (Virtual Private Cloud). And luckily that is very simple. Just create a VPC Connector in GCP.
BUT be aware to create a so called Serverless VPC Access (Connector). Explained here: https://cloud.google.com/vpc/docs/serverless-vpc-access
After the Serverless VPC Access has been created you can select it in your Cloud Run Service "Connection" settings. For the backend service it can be simply selected. For the frontend service however it is important to select the second option:
At least that is important in my case since I am calling the backend service by it's assigned service URL instead of a private IP.
After all that is done my JWT token from the frontend is successfully delivered to the backend API without being overwritten by a MetaServer token.
I just created an REST API in API Connect and the endpoint works when I test it in the APIC assemble tab. It requires a client id and client secret. When I send a request through Postman, I currently get a “Could not get any response” message from when I try to add them as header values or OAuth authorization. I’m using the request endpoint that’s displayed when I hit the debug button from the successful response on the Assemble tab. Is this the correct endpoint to use? How do I properly include the client id and client secret in a Postman request?
If you get a "Could not get any response in Postman", that means that Postman can't reach the destination of the request.
There are several reasons for that:
Is it an intranet or internet endpoint?
Are you using a proxy? (check proxy config)
Is the hostname resolvable? (try ip)
If it is an https
endpoint, with a self signed certificate, check if you have SSL
Certificate verification enabled (Settings-> general)
On the other hand, to send the client-id and client-secret headers, just click on Headers tab and add both (see the following picture)
Please check the below things to get access to API Connect published services.
Service needs to be allowed to invoke from postman(System from which you are invoking.)
Please check the web-api MPGW service titled in DataPower default domain created when you configure your API connect with DataPower have you created an access control list in the front-side-handler.
Please disable the SSL configuration in the postman, sometime this may create a problem(since the service exposed from API Connect will be with SSL)
From the error you are getting, I suspect there is no connection or only one-way traffic is enabled which means you are blocking response. If there is an issue with the request parameters you are sending, an error will be different saying, wrong client id or client secret.
Testing API which is on-boarded from API Connect will be straightforward or same we invoke other rest services.
Thx Srikanth
I needed to include the client id and client secret in the headers using the correct name for them, which is specified when creating/editing the api under the 'Security Definitions' category as 'Parameter Name'.
I was also hitting the wrong endpoint. To find the correct endpoint click the hamburger icon in the upper left of api connect website, select dashboard, click on the environment you want such as sandbox or dev, click settings, click gateway, then you'll see the endpoint.
I need to configure an application to accept connection only from client with a certificate, the client should be ApiGateway.
I followed this step by step tutorial. But when I should upload a certificate and enable a checkbox called "Enable request of client certificate" in upload dialog box it disappear.
I tried with many browser (Chrome, Firefox, Safari) on a Mac. I'm quite that this not depend on browser, so now how can do the same thing?
Thanks for every answer.
From my understanding, the given task needs to be separated into two activities.
Client with certificate
A client with DNS APIgateway
Client with Certificate
In general, when we create an API, we expose with a gateway via HTTP protocol which has some signed certificate (Production). Please provide that public certificate to the consumer of your API. And you can test this using postman, we have an option of SSL certificate upload in Postman, make a use of it for testing.
Client with DNS Name
For this, in Datapower (API Gateway), you can create an Access control list following this IBM documentation. Access control list is something, we allow or restrict the host that we consume the services exposed using Datapower.
I have a Java app running under Websphere Liberty on IBM Bluemix. I need to be able to authenticate users 3 different ways - Basic Auth, SAML SSO, and OpenAuth SSO, in that order.
I can set up the app to do Basic Auth (using custom code) or SAML SSO (using the Bluemix Single Sign On service), but can't figure out a way to configure it to handle both at once. (I haven't even looked into how to do OpenAuth yet.) If I configure the app to use the Bluemix SSO service, then my app never sees the incoming requests to check for a userid and password to try Basic Auth before the SSO service grabs it.
I tried changing the redirect URL in the SSO service to an endpoint inside my app, but then all I get is
CWOAU0062E: The OAuth service provider could not redirect the request because the redirect URI was not valid. Contact your system administrator to resolve the problem.
I can't be the only one that needs to do this. Can anyone tell me how they did it?
We have developed a web application using angularjs and html5 and Node.js. This web application is hosted on Bluemix using the Node.js runtime. This web application calls an external RESTfull service (we are invoking the REST service using angularjs) which was developed by a third party. This REST API requires an HTTPS connection to call the service. The SSL certificate and certificate password are provided by the API development team. Our problem is how to configure the SSL certificate on Bluemix to call the external REST service over SSL from the web application. Can anyone please help us? Thanks in advance for your help.
To do this properly I would advice to create an API Management Service, where you add your external service as an API together with the SSL settings. You then call this API (proxy) without SSL from your node.js bluemix app.
The proxy will care for SSL, forward the request to the actual service implementation, and provide you also with debugging and analytics capabilities. With having API Management in place, you also benefit from a central place that manages your SSL certificates.