Modern problems in backend engineering, Siim Kaspar Uustalu

1. Practical authentication and
authorization for external facing service
mesh applications
Siim Kaspar Uustalu
Backend team lead

2. The plan
● Set the scene
● Introduce authentication
● Add authorization on top

3. whoami
● I’m a software engineer
○ Delivered work for TUNE, the Estonian Road Admin. & others
○ Currently in digital banking
● Mooncascade helps you develop products
○ Trusted by banks, telcos & startups
○ Helps you bridge the hiring gap
○ Does development work across the stack

4. The scene: application
● Put on your architect hat
○ We’re building math as a service!
○ Service oriented architecture
■ HTTP expression parser + gRPC operation services
○ Containerised w/ k8s for orchestration
● Outsourced operations services

5. Application architecture

6. The scene: our mission
● Offer MaaS API
○ Identify users
○ Support authorization levels
● Support application growth
○ Avoid introducing code dependencies
○ Plan for team growth - autonomy matters

7. Authentication
● The usual scenarios
○ Machine users
○ Backend services as user agents
○ Client side applications
● Solved problem with the OAuth 2.0 framework

8. Authentication: implementation
● Make use of service mesh facilities
○ Istio: JWT based auth out of the box
■ Signature validation
■ Drawback: not good for user facing applications
● Extend minimally
○ Replace out of box ingress with API gateway
○ Provide OAuth2 service + identity provider
○ Plug an authentication service into the API gateway

9. Authentication: the API gateway
● Authenticates requests
○ In combination with the authentication service
● Provides routing
● Terminates incoming TLS
○ Mutual TLS in the mesh
● Traefik, Ambassador & friends

10. Authentication: OAuth2 service
● Does the boring, but important parts
○ Client application management
○ Key management (maybe)
○ The actual protocol
● Integrates with an identity provider
○ That’s you!
● Should be off the shelf

11. Authentication: auth service
● Verifies issued OAuth token
○ Bridge between API gateway & OAuth2 service
● Issues short-lived internal JWTs
○ These carry requester identity, delegated down request chain
● Provides keys for the service mesh
○ Mesh verifies the signature using the public key

12. Architecture with authentication

13. Authorization
● Which actions are permitted given a set of facts?
● Retrofitting affects all services
● Separate domain with own rules in all services
● NB!: Distributed teams
● Idea: Separate the authorization policies from services

14. Authorization: implementation
● Istio enables policy definition out of the box
○ Based on JWT payload
○ Good enough for basic request control
● Adapters enable more fine-grained control
○ Response, better visibility over rule set
○ Lets roll with the Open Policy Agent adapter

15. Authorization: Open Policy Agent
● DSL for policy definition - Rego
○ Declarative policy definitions + capable standard library
○ Still testable
● Separate authorization domain per service
● Contract over library approach
○ Right tool for each job

16. Authentication policy example

17. Architecture with authorization

18. Conclusion
● Extended an external facing service to...
○ Support the OAuth2 protocol
○ Support request authentication
○ Provide authorization from a sidecar service
● Made use of Istio facilities where possible

19. The service mesh pattern enables
cleaner separation between features and
the “glue”
siimkaspar.uustalu@mooncascade.com
mooncascade/service-mesh-auth-demo
Coming soon!