Custom Microservice - authorization on top of gateway authentication?

Question

Hello community,
we are looking into the integration of yuuvis with another system by means of a yuuvis client action which will invoke a custom microservice in yuuvis - which in turn will integrate with the distanced system (built by us internaly).

I understand that we can secure custom microservices with the help of yuuvis gateway, so that every call to this service needs to be authenticated against an active user (we run an NTLM Gateway which means the users will not be prompted with another login).

However we are also interested in securing this custom microservice endpoint by authorization instead of authentication only - is there a way we can link some of our existing yuuvis rights or roles to the invocation of such an endpoint of a custom microservice within yuuvis?

Thanks a lot

Best,
Clemens

Answer 1

Hello Clemens,

you can make a rest-ws call within your microservice against the dms-service rest-ws endpoints and find out about the functional and object-type rights the user has.
For example
UserService.getState with "privileges=true&roles=true" or
DmsService.getItem with "rights=CURRENT" bzw. "rights=USER-"
You can find the username and JWT token in the header information of each rest-call.

With that information you can decide whether you want to continue or return forbidden.

Hope that helps.
Best regards
Nicolai

Comments

Hello Martin,

the problem here is that your microservice is using the gateway to communicate with the rest-ws. Instead you should be using the dms-sidecar microservice. If you are using the FeignClient you just need to annotate the class with @FeignClient("dms"). If you are using something else make sure you are using the dms-sidecar instead of the gateway.

Best regards
Nicolai

---

Hi Nicolai,

thanks for your fast response again! :)

I did a test with the dms-sidecar. I called the sidecar and with and without using the JWT as Authorization Header.
There is no difference and I always get the following answer:

Disclaimer: I am not logged in as root! ;-)

{
    "id": "1EF9EB6E7F2F41D69D5408609CFF5FFD",
    "uri": "http://localhost:8080/rest-ws/service/organization/id/1EF9EB6E7F2F41D69D5408609CFF5FFD",
    "name": "root",
    "type": "user",
    "title": ", root",
    "email": "root@optimal-systems.de",
    "useruri": "",
    "firstname": "root",
    "lastname": "",
    "active": true,
    "hasimage": false,
    "present": true,
    "locale": "de"
}

Regarding FeignClient. Haven't used it but will give it a shot. Do you happen to have a code example?

Cheers
Martin

---

Hello Martin,

if you call your custom microservice from within a bpm script it will always be called with the root user because the script is executed in the dms-service context and has no user. The microservices will then put their user in the header and this is root. If you want to get the information about the user who started the bpm step, you have to get the username / userid within the bpm script and pass it as a parameter to your microservice. you can then call "OrganizationService.getOrganizationObjectByName" to find out about the users rights and privileges.

If you call your microservice from a client custom-action, there is already a user session and the dms-sidecar will use the JWT Token from the "authorization" header. In this case you can use the whoami endpoint.

FeignClient: https://cloud.spring.io/spring-cloud-netflix/multi/multi_spring-cloud-feign.html

Best regards
Nicolai

---

Hello Nicolai,

ok, got it. We will determine the user in the BPM script.

But what is the recommended way to secure the endpoint against requests outside the system? For example, if someone with Postman or any other tool would call the endpoint of the microservice?

Our idea was to validate the JWT in the authorization header. But how?

As described above, when we call the whoami endpoint we get the "root response" as described above. No matter if we send a valid JWT, an invalid JWT or no authorization header at all.

Kind regards
Martin

EDIT:
Could this link be helpful?
https://qa.enaio.org/index.php?qa=399&qa_1=gateway-endpoint-microservice-without-asking-credentials
I wouldn't be surprised if we have a totally crazy configuration with our gateway etc. ;-)

---

Hello Martin,

the JWT validation is our recommended way. If you pass a JWT Token via the header it will not be changed to the "root response". Are you sure you have tried a valid JWT Token from a user other than root?

The link describes how to enable unauthorized access to certain endpoints. I thinks that's the opposite of what you want ;-).

Best regards
Nicolai