The document discusses adding authentication and authorization to an externally facing service mesh application. It introduces authentication using the OAuth 2.0 framework with an API gateway and authentication service. Authorization is implemented using Open Policy Agent to define policies separately from services. The resulting architecture separates authentication, authorization, and application services for improved scalability and team autonomy.

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!