describe propagating user context

1 files changed, 63 insertions, 0 deletions

diff --git a/learn/authz/README.md b/learn/authz/README.md
index 7e6d8e5..a5d26b8 100644
--- a/learn/authz/README.md
+++ b/learn/authz/README.md
@@ -173,8 +173,70 @@ Example Flow:
 
 [Auth0][2] can be used as the OP in the diagram above.
 
+## Microservices Security in Action
+
+* https://learning.oreilly.com/library/view/microservices-security-in/9781617295959/
+
+* TLS Bridging: proxy server terminates TLS for incoming connection and creates
+  a new TLS connection to the destination of the message.
+* TLS Tunneling creates a tunnel between the client and the microservices.
+
+The API gateway terminates all client connections at the edge. It dispatches
+requests to the upstream service if all looks good. The initial client/user
+context needs to be passed through as well.
+
+Service to Server authn
+
+1. Trust the network
+1. Mutual TLS
+1. JSON Web Tokens
+
+Service-level authz
+
+1. centalized PDP
+1. embedded PDP
+
+Propagating User Context
+
+1. Send user context as an HTTP Header
+1. Use a self signed JWT
+1. Use a JWT issued by a trusted external STS
+
+```plaintext
+                   ----------
+                   | Client |
+                   ----------
+                       |
+||=====================|========================||
+||                     V                        ||
+||              |--------------|                ||
+||              | API Gateway  |                ||
+||              |--------------|                ||
+||                 |                            ||
+||        ----<----|                            ||
+||        |                                     ||
+|| *******V*********       *******************  ||
+|| *      |  |----->----------------         *  ||
+|| *      |  |     *       *       |         *  ||
+|| *      V  |     *       *       V         *  ||
+|| * =========     *       *    ---------    *  ||
+|| * |       |<----<-----| *    |       |    *  ||
+|| * | API A |     *     | *    | API B |    *  ||
+|| * |       |----->--|  | *    |       |    *  ||
+|| * =========     *  |  | *    ---------    *  ||
+|| *  |     A      *  |  | *                 *  ||
+|| *  V     |      *  V  |-<-----<-----|     *  ||
+|| *  |  -------   *  |    *        -------  *  ||
+|| *  |->| STS |   *  |---->------->| STS |  *  ||
+|| *     -------   *       *        -------  *  ||
+|| *****************       *******************  ||
+||                                              ||
+||=====================|========================||
+```
+
 ## Glossary
 
+* PAP: Policy Administration Point.
 * PEP: Policy Enforcement Point is a gateway that protects all requests routed
   to this point to make a decision. It takes the incoming HTTP request and
   creates an authz specific request. Usually this is the API Gateway.
@@ -183,6 +245,7 @@ Example Flow:
 * RP: Relying Party is the OAuth 2.0 Client application.
 * OP: OpenID Provider is the OAuth 2.0 Authorization Server that is capable of
   Authn and providing claims to a RP about the authn event and User.
+* STS: Security Token Service
 
 [1]: https://datatracker.ietf.org/doc/html/rfc7662#section-2
 [2]: https://auth0.com/docs/authenticate/login/oidc-conformant-authentication/oidc-adoption-access-tokens