GitHub: https://github.com/geekchow/micro-service-auth在本地把 PoC 跑起来实时观察每一次认证/授权决策的发生并对任何行为异常的服务进行排查。快速开始在仓库根目录下mvn-qtestdockercompose up-d--buildbashscripts/demo.sh脚本在每一步之后都会暂停要求你输入yes才继续。这样你有时间在各步骤之间检查日志或端点。演示脚本做了什么脚本按顺序运行以下步骤等待Keycloak、Kong与identity-bootstrap-service就绪。通过identity-bootstrap-service创建alice用户。通过identity-bootstrap-service创建ops-admin用户。让alice经Keycloak登录并捕获她的令牌。让ops-admin经Keycloak登录并捕获其令牌。用alice的令牌调用受 Kong 保护的 API 访问她自己的账户 —— 期望200。用alice的令牌调用受 Kong 保护的 API 访问他人账户 —— 期望403。用ops-admin的令牌调用受 Kong 保护的 API 访问任意账户 —— 期望200。不带令牌调用受 Kong 保护的 API —— 期望401。用被篡改的令牌调用受 Kong 保护的 API —— 期望401。第 6–10 步演练了概念文档中描述的完整 IdP → PEP → PDP → 资源服务器 链路。常用端点服务URLKeycloakIdPhttp://localhost:9081Kong proxyPEPhttp://localhost:8000Kong adminhttp://localhost:8001OPAPDPhttp://localhost:8181identity-bootstrap-service与banking-api-service是 Compose 网络内部的服务不对宿主机暴露。请用curl辅助容器来访问它们见下文。用 curl 容器做内部检查Compose 文件中包含一个位于同一内部 Docker 网络上的curl辅助服务。用它来访问那些未对宿主机暴露的服务。在容器中打开一个 shelldockercomposeexeccurlsh或运行一次性命令# Keycloak OIDC discoverydockercomposeexeccurlcurlhttp://keycloak:8080/realms/banking-poc/.well-known/openid-configuration# List demo users (identity-bootstrap-service)dockercomposeexeccurlcurl-ihttp://identity-bootstrap-service:8080/demo/users# Query OPA policy statedockercomposeexeccurlcurlhttp://opa:8181/v1/data/banking_authz/allow# Check banking-api-service healthdockercomposeexeccurlcurlhttp://banking-api-service:8080/actuator/health注意Keycloak 的内部地址是keycloak:8080。面向宿主机的端口9081只用于来自你本机的流量。如果出错了先做一次宽泛的检查dockercomposepsdockercompose logs --no-color--tail200再按症状缩小范围症状排查位置登录失败Keycloak的 realm、用户与 client 配置合法用户却得到401Kong 的令牌校验或banking-api-service的 JWT 配置本应允许却得到403OPA 的策略输入与 JWT 声明意外的5xx服务日志与容器健康状态排查流程4014035xxLogin errorDemo failedWhich status?Check token creation or token validationCheck OPA decision and account claimsCheck service logs and container healthCheck Keycloak realm, user, clientKong logsbanking-api-service logsOPA policyJWT claimsdocker compose logsKeycloak logs如何正确理解这个 PoC本项目是一个学习与可行性验证环境并非生产蓝图。它证明了Keycloak能够签发所需的身份声明。Kong能够在流量到达服务之前执行访问控制。OPA能够做出外部化的授权决策。banking-api-service能够充当受保护的资源服务器。上述四个组件能够端到端地协同工作。它并未覆盖每一项生产关注点例如企业级密钥管理高可用部署生产级的用户接入onboarding流程生产级的可观测性自包含的 Docker 镜像构建← Prev: 03 — 请求流程 · Next: 05 — 组件巡览 → 返回专栏目录