Jhipster : Proper architecture to authenticate using an existing database

Question

I'm currently working on a Jhipster prototype application. The application is a simple gateway with a microservice to access data.

Right now, I would like to use an existing database from my company to authenticate users, but Jhispter doesn't seems to supports multiple datasources (and I don't want my whole gateway to switch to another database)

My first idea was to use a microservices to authenticate user. This microservice would run on the other database, but this creates another problem : to call this service from the gateway, I need a JWT token... and this starts to look like I need to be authenticated to authenticate a user.

The other solution, as said before, would be to have two datasources on my gateway : one for user authentication (pointing to the existing database), and the other for Jhipster-related data (audits, etc..)

Do you know what would be the best practice in this case? And can you point me in the right direction for this choice ?

Answer 1

First solution: you can easily unprotect authenticate endpoint in SecurityConfioguration on your micro service so that you don't require a token for it then you will have to create a Zuul route on gateway for /api/authenticate.

Second solution is a well known question about using multiple datasources in Spring Boot which has many well docuemnted answers.

There could be another solution consisting in using an existing third party identity server like uaa or KeyCloak if you can configure them to your existing user database.

So for a prototype, I'd go with the second solution.

Answer 2

I suggest to switch to JHipster UAA to solve this, as you are looking for service-to-service authorizastion. Furthermore, should have no own entitiy served by the gateway. Every single endpoint of your microservice, should be inside a own microservice.

To sum up the use-case of UAA for you, you get a new service, which can authenticate users, to exchange username and password for a JWT, like the JWT authentication, but also internal client credentials, without a user. As this is part of spring-cloud-security, auditing works as well. Keep in mind, that the "auditor" in this case will be a service (or more precise, a oauth2 client used by the service), rather than a user.