I am using JHipster's Gateway and UAA to work with microservices, to create the Gateway without the frontend I used the jhipster -skip-client command, however to create the separate front end of the Gateway I created a new folder and executed the command jhipster --skip-server --auth oauth2 --db postgres --uaa-base-name uaa-server.
The frontend generated with the command fails to authenticate because it seems that it gets lost in the addresses and tries to make a direct access to the Gateway service that is not configured in the system, how can I generate the frontend so that it is equal to the generated frontend along with Gateway?
There are two separate issues here. First, when using UAA, the auth type should be uaa instead of oauth2. Second, the uaa-base-name needs to match the base name in the generated UAA server, which by default is uaa.
Related
I am currently working with spring boot micro services. To access those services I am using api gateway with Eureka client but I have one question to secure my service.
Consider I have below 4 microservice project hosted locally.
User :- hosted on http://localhost:8080/user
owner :- hosted on http://localhost:8081/owner
security :- hosted on http://localhost:8082/security
and api gateway :- hosted on http://localhost:9090/
so now to access services of owner I am first calling api gateway than security project after authenticating it is allowing me to access service of owner project .I am calling owner project from security project using feign client.
api gateway ---> security ---> owner
using url http://localhost:9090/security/owner
I am able to access owner project using that flow but now my question is I am also able to call directly owner project using it's own port. As shown below:-
http://localhost:8081/owner
How can I restrict that direct access to owner project?
The simplest solution would be for owner service to expect some kind of access token within the request. Such a token should be provided by security service (i.e. it could inject it within Authorization header), when it forwards request.
In more complex environment, in which multiple services may required different level of access to other services, more sophisticated solution would be required, i.e. involving mutual TLS where each service has its own certificate. But that would require much more setup. However that's worth doing on complex production systems.
One more element that could be used to control such access is the service mesh. You can read up on the topic - example: Istio.
I have a vps, where my spring boot backend is running on. The frontend is a mobile app built with the ionic framework.
The backend is built this way: in the front there is an so called resource server, which is an graphql server, which redirects the requests to rest microservices which are behind the resource server. Every microservice has is own task, which he's responsible for. (e.g. an fileupload-server which uploads/downloads files to a database). The whole application, including the frontend is secured by an keycloak instance, which is running as an docker container like the whole application, except the frontend.
Now my questions is, we dont have a domain and for some reason they wont buy one, but we wont to secure the communications over ssl/lets encrypt. But lets encrypt isn't able to create ssl certificates for ip adresses. So finnaly my question is: do you guys, know a solution to my problem which fits?
So far,
Daniel
I have a dev and prod cognito pool, a dev/prod lambda function that pushes to a dev/prod dynamoDb table.
Is there a simple way to have it know when to use the prod credentials (pool id, etc), and when to use the dev credentials?
And same to do with firing the appropriate dev/prod API gateway apis that check the appropriate pools for authentication, and post to the appropriate dynamoDb tables? For now I just manually change the tokens, and in API Gateway, I manually switch out which cognito pool the API gateway authenticates and which tables they post to, which isn't very practical.
If you expose your lambda with API Gateway then just deploy it to two stages - a prod stage which calls the prod lambda which accesses prod Dynamodb & a dev stage which calls dev lambda. In your application, you would just need to change the stage name & you can do so by setting it from Info.plist.
Regarding how to get tokens for prod or dev automatically, it depends on how you get these tokens. For example, you could create a /login resource in API Gateway which takes username + password as parameters and returns tokens. Again, deploy it to two stages which use different Cognito pool in the backend calls. Now, you can use the same variable/property in your application to get the stage name for getting tokens too.
So, by just changing the value of one property you can switch between prod & dev in your app.
I have configured composer-rest-server. I had also provided fabric username/password while configuring composer-rest-server (WebAppAdmin or admin). Now, I can able to access REST API without providing any credentials (through postman or loopback).
I would like to understand how we can secure composer-rest-server. Though, I have understood that we can add participant and issue identity, but not able to connect logical dots in context of how everything will work.
How to secure composer-rest-server while accessing REST API?
When and How we are going to use "username/secret" registered against any participant?
When to authenticate composer-rest-server API and When to use participant identity to access business network?
Please see the documentation on this subject:
https://hyperledger.github.io/composer/integrating/enabling-rest-authentication.html
I am setting up an API for a mobile app (and down the line a website). I want to use oAuth 2.0 for authentication of the mobile client. To optimize my server setup, I wanted to setup an oAuth server (Lumen) separate from the API server (Laravel). Also, my db also lives on its own separate server.
My question is, if using separate servers and a package like lucadegasperi/oauth2-server-laravel do I need to have the package running on both server?
I am assuming this would be the case because the oAuth server will handle all of the authentication to get the access token and refresh access token functions. But then the API server will need to check the access token on protected endpoints.
Am I correct with the above assumptions? I have read so many different people recommending the oAuth server be separate from the API server, but I can't find any tutorials about how the multi-server dynamic works.
BONUS: I am migrating my DB from my API server, so I would assume I would need the oAuth packages migrations to be run from the API server also. Correct?