Authorization concept
Goals
- Mostly agnostic client
- Easy to expand/improve
- Scalable
- No user authentication in the services
- Easy to migrate to future schemes
- Supporting generic tooling (like swagger)
- Services should handle their role specific logic themselves and not need to share information
Preconditions
When the client sends a request that is connected to a room access (e.g. patching content, locking feedback, writing a comment), the Route needs to have the room id and assumed role encoded. A request needs to be sent to a gateway which intersects the requests. HTTP routes and STOMP queues can be handled in a similar manner, because the queue can have the room id and role
Webclient
- Authenticates the user and gets a JWT
- Every request (both WS and HTTP) besides the auth should have the JWT
Gateway(s)
- If a request has a room id and role, it queries the auth service
- The gateway drops the JWT from the user and replaces it with a JWT (with a very short TTL) with the answer from the auth service as data
Auth Service
- The service listens to specific queues to update a local db with the room access
- Exposes an HTTP API endpoint to get the room access based on room id and user id
- If there is no specific entry in the database, it returns one (for a participant role), but doesn't save it
Services
- Get a request that can have a JWT encoding room access
- If the service decides, that the request needs a specific role, it can check the JWT
Drawbacks
- Gateway has to always query the auth service (--> it could learn which routes actually need a role > participant)
- Routes like
/room/~11223344
cost a roundtrip more to resolve the short id - Services need to handle JWT
First and second drawback profit from caching, but make the system more 'eventual' (a short id doesn't change though).