Centralise legacy auth at the ingress gateway, SREday

@magickatt on Twitter, GitHub
Background by M-ART Production https:/
/www.pexels.com/photo/a-back-view-of-a-man-in-brown-coat-standing-between-ticket-barriers-7252569/
Centralise legacy auth at the
ingress gateway
Andrew Kirkpatrick
SREday 2023

Image from https:/
/www.osohq.com/post/microservices-authorization-patterns
The problem?

Image from https:/
/www.osohq.com/post/microservices-authorization-patterns
A (possible) solution…?

Overview
1. But why not just use something off-the-shelf?
2. Identifying and categorising authentication
3. What information to send downstream?
4. Where to handle authorization
5. Stand-alone auth next to your gateway
6. Summary
Background by Codioful https:/
/www.pexels.com/photo/multicolor-photo-7130469/

But why not just use something
off-the-shelf?
Background by M-ART Production https:/
/www.pexels.com/photo/a-person-inserting-a-ticket-7252259/

Choosing an off-the-shelf solution
● Greenfield (brand new) project
○ No existing users?
○ No existing authentication/authorisation?
● Existing (possibly legacy) project?
○ Add to tech stack, or refactor existing?
○ Introducing a new authentication type
○ Deprecate existing authentication types?
○ Backwards compatibility with data?
○ Able to migrate/synchronise identity data?
https:/
/twitter.com/elonmusk/status/1632810081497513993

Migrate or synchronise identity data
If using an off-the-shelf solution, either have to migrate your users, or
find a way to (accurately) synchronise them
● How easy is it to copy/synchronise?
○ Extract data from your current platform
○ Add/update data in the new solution
● If migrating identity data across, move it in 1 go or keep in active
synchronisation?

Migrate or synchronise user data
If using an off-the-shelf solution, either have to migrate your users, or
find a way to (accurately) synchronise them
● How tricky is it to keep data in-sync?
○ How real-time is the synchronisation?
○ How often does user access and/or
permissions change?
○ How dangerous is it if out-of-sync?

Identifying and categorising
Background by cottonbro studio https:/
/www.pexels.com/photo/person-sitting-on-the-chair-near-the-plastic-containers-with-lables-6591427/

What mechanisms are you using?
Many, many different authentication types
● HTTP Basic
● HTTP Bearer
● Cookies
● API key
● OAuth 1.0, 1.0a
● OAuth 2.0
https:/
/blog.risingstack.com/web-authentication-methods-explained/
https:/
/blog.restcase.com/4-most-used-rest-api-authentication-methods/
https:/
/blog.stoplight.io/api-keys-best-practices-to-authenticate-apis
https:/
/www.synopsys.com/blogs/software-security/oauth-2-0-vs-oauth-1-0/
https:/
/www.wallarm.com/what/oauth-vs-jwt-detailed-comparison

How are these authentication types being used?
● What paths, subdomains and/or headers for which authentication type?
● Does each authentication type represent the same kind of identity?
(always a user?)
● How is auth configured?
○ Router
○ Method annotations/decorators
○ Middleware
○ Framework hooks/events/signals
○ Database page/object permissions
○ Configuration file
○ …

How are these authentication types being used?
● Multiple authentication types in a monolith, or different types
per-service?
● Are different implementations using different programming
languages/technology stacks?
● How would you combine these?

Example authentication identiﬁcation
Try and choose 1 (or more) authentication types based on host, path or
headers

Example authentication identiﬁcation
Alternatively try all authentication types until you determine which one is
being used

What information to send downstream?
Background by Aleksandr Burzinskij https:/
/www.pexels.com/photo/young-woman-swinging-on-swing-and-splashing-water-4834565/

Enhanced context
If handling multiple authentication types, you can consolidate their
identity/authorization information into a standardised format
● What does your current identity data look like?
● Can you represent different authentication types using a similar/same
data structure? (such as JSON)
● Ingress gateway can add headers from the auth service response to the
request sent downstream
● Header can contain identity data so do not need to look it up again
username,
password
{
user_id: 1,
company_id: 2,
name: Person
}

Example transformation
Users
Gateway
(add/remove
headers)
Auth service
Gateway removes Authorization header
Adds X-Internal-Auth header
Auth service fetches user using
credentials from Authorization
header (username and password)
Returns identity information in
header as encoded JSON

Multiple authentication types
Authorization Basic
username:password
X-Api-Key: key
If sometimes the identity object will not have a user,
does that change how you represent the company?
Each authentication type might not
represent the same thing. What if an
API key represents actions of whole a
company, rather than an individual
user in that company?
?

Where to handle authorisation
Background by Erik Mclean https:/
/www.pexels.com/photo/policeman-standing-near-modern-car-on-road-5662832/

Authentication versus authorisation
Centralise authentication, not necessarily all authorisation
● Typical auth response true/false (HTTP 2XX/4XX)
● Authentication as purely identity (who are they?)
● Authorisation as role or permission-based gate
● Most basic authorization “not logged in” (deny anonymous role)
Authenticate
identity
Authorize
identity
Fetch identity
using credentials
Does this
endpoint allow
anonymous
access?

{
"path": "/v1/admin/user/add",
"user": {
"name": "Somebody else",
"role": "member"
}
}
Broad authorization
Authenticate
identity
Authorize
identity
Fetch identity
using credentials
For this path
the user must
be an admin
{
"user_id": 1,
"name": "Somebody",
"role": "admin"
}
Request information
Identity information
(fetched during
authentication)
Use combination of
request and identity
information to
perform top-level
authorization

Delegates granular authorization
Authenticate
identity
Authorize
identity
Fetch identity
using credentials
Broad
authz
{
"user_id": 1,
"name": "Somebody",
"group": 2,
"roles": [
"document/viewer",
"group/moderator",
"report/viewer"
],
"acl": {
"document/1/admin": true,
"document/4/admin": true,
"document/8/admin": true
}
}
Too complicated
to authorize here,
let downstream
service decide…
{
"path": "/v1/document/123/attachment/456/delete"
}
Check
ACLs
Check
roles
Delete
document
Document service

Stand-alone auth next to your gateway
Background by Keenan Constance https:/
/www.pexels.com/photo/woman-sitting-on-wooden-planks-2865901/

Possible options for integrating
Most ingress gateways/proxies will allow you to specify an external auth
service via HTTP or gRPC
● Emissary Ingress AuthService (Envoy)
● Gloo Custom Auth server (Envoy)
● Kong Custom Plug-in (Nginx)
● Traefik ForwardAuth middleware
● Tyk custom plugin
● Nginx Subrequest Result
● AWS API Gateway Lambda Authorizers (Proprietary, Bearer only)
https:/
/www.getambassador.io/docs/emissary/latest/topics/running/services/auth-service
https:/
/docs.solo.io/gloo-edge/master/guides/security/auth/custom_auth/
https:/
/konghq.com/blog/custom-authentication-and-authorization-framework-with-kong
https:/
/doc.traefik.io/traefik/middlewares/http/forwardauth/
https:/
/tyk.io/blog/how-to-setup-custom-authentication-middleware-using-grpc-and-java/
https:/
/docs.nginx.com/nginx/admin-guide/security-controls/configuring-subrequest-authentication/

Web
request
Example ExtAuth request ﬂow
Gateway HTTP/gRPC
Denied
Allowed
Auth service
● Headers
● Body
● Path
● Headers
● Path
● Response code (2XX or 4XX)
● Headers (modified)
● Body
● Path
1. Allow or deny based on headers
and path?
2. If allow, optionally add identity
and/or authorization information

Envoy ext_authz (Emissary Ingress AuthService)
Gateway HTTP/gRPC Auth service
Port 3000
https:/
/www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ext_authz_ﬁlter#arch-overview-ext-authz
https:/
/www.getambassador.io/docs/emissary/latest/topics/running/services/auth-service

Practical example
Background by Ekaterina Bolovtsova https:/
/www.pexels.com/photo/a-ﬁgurine-of-the-lady-justice-on-the-table-of-a-judge-6077381/

Flask route auth via decorator request ﬂow
Denied
Allowed
Auth
service Database
Route
decorator
All within the same
running application
/orders
API route

Flask route auth via decorator

Flask route with ExtAuth request ﬂow
Gateway HTTP
Denied
Allowed
Auth service
/orders
API route
Route
decorator

Flask route with ExtAuth

Background by Mitchell Luo https:/
/www.pexels.com/photo/anonymous-woman-walking-near-pay-gates-5918868/
Summary

Summary
● Can use (almost) any type of authentication
● Try and determine what authentication types are used for which
paths/domains/headers to reduce checks/lookups (if possible)
● Pass identity and/or authorisation information onto your downstream
services
● Consider how to represent authentication/authorization data sent
downstream
● Handle none, some or all authorization before it reaches your services
● Ensure the auth service is highly available to ensure availability

© 2023 StackAdapt Inc.
StackAdapt is a self-serve programmatic advertising
platform used by the most exceptional digital marketers.
This state-of-the-art platform is where some of the most
progressive work in machine learning meets cutting-edge
user experience. Ad buyers plan, execute, and manage
data-driven digital advertising campaigns across all
devices, inventory, and publisher partners.

Thank you!
Hopefully this gives you some ideas as to how you might be
able to centralise legacy auth in some of your projects?
Slides (should be) available at
https://www.slideshare.net/magickatt/centralise-legacy-aut
h-at-the-ingress-gateway
Code example available at
https://github.com/magickatt/AuthAtTheGatewayTalk
● https://www.linkedin.com/in/andrewkirkpatrick/
● https://www.andrew-kirkpatrick.com
● https://github.com/magickatt
● https://twitter.com/magickatt

Centralise legacy auth at the ingress gateway, SREday

More Related Content

Similar to Centralise legacy auth at the ingress gateway, SREday

Recently uploaded

Centralise legacy auth at the ingress gateway, SREday