I was checking keycloak authorization service to implement authorization service for few of the REST endpoints which do not have keycloak adapter implemented.
From keycloak quick starts example it looks like authorization service only supported for end points which has keycloak adapter implemented.
Has any one tried to perform keycloak authentication to a REST request before request actually goes to that server.
The REST endpoints are written in Node.JS and i can't implement the adapter in Node.JS because it is not maintained by us. :)
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.
currently working on wso2 identity servicer v5.7 . need a help to update service provider using soap request. i read the wso2 docs and saw the services provided by wso2 but did not find the right soap request. I want to update service provider all the details in one request: saml sso configuration as well.
You can use the updateApplication method of IdentityApplicationManagementService to update a Service Provider. To obtain the WSDL, use the following URL.
https://{IShost}:{port}/services/IdentityApplicationManagementService?wsdl
I use Apache Karaf 4.x for my rest services. I would like to provide authentication and authorization for my services via Keycloak. I do not want to make direct changes in each service. Instead, I would like to configure karaf in the way that if request is not authenticated then it will forward to keycloak to get a session. or maybe there could be client credentials or bearer token and karaf could check that token before allowing to use the service.
Any help is appreciated.
Thanks in advance
I need to connect the zuul and keycloak. But my issue is that I am not gettting any idea or code. I need from api gateway to call keycloak and get the access token and from api gateway again to validate the access token and call the request api
I have to create a client application that uses OAuth2 and a REST service. I confirmed that the REST service I can achieve it only by WSO2 ESB? WSO2 IS does not provide any REST service without using other platforms carbon?
There are some rest webservices for oauth2, check https://localhost:9443/oauth2/token
and the associated doc
https://docs.wso2.com/display/IS520/Resource+Owner+Password+Credentials+Grant