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
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
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
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!