search

c0c0n3 / kitt4sme.live

On a mission to bring AI to the shop floor: https://kitt4sme.eu/
MIT License
1 stars 28 forks source link

Securing VIQE #163

Open c0c0n3 opened 2 years ago

c0c0n3 commented 2 years ago

Summary

Even though PR #162 didn't implement security, it could be easily bolted on top since the service is exposed through Istio path-based routing. We could easily apply an OPA policy similar to the one we've implemented for the FIWARE services. Once that's in place, we can restrict access to the VIQE service to requests containing a valid Keycloak token.

Intended outcome

The VIQE service can only be accessed by users who have got an authorisation token from Keycloak. Also, a user can only see the resources they've been authorised to see for the tenant (realm) they belong in. They can't see any other resource in a different realm.

How will it work?

Similar to Dazzler. VIQE gets a security token from Keycloak before sending data. Then it connects to KITT4SME through HTTPs and adds a Bearer Auth header containing that token to each HTTP request.

c0c0n3 commented 2 years ago

Notice #83 basically asked for the same secure setup, except that setup referred to the old VIQE service implementation where communication would go through Orion. With the latest implementation (c0c0n3/kitt4sme.viqe#1), the VIQE clients talk directly to the VIQE service. So this issue supplants #83.