这是一个创建于 346 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近试用了下，看起来功能很多有点重，不知道生产环境用的多不多哦。有没有过来人给点经验，有哪些功能是比较稳定好用的，不想踩坑咯。
 | 1 vinsa 346 天前  1 拿他做个登录中间件挺好，功能很完善。 至于是否用它做权限管理，取决于系统和设计了。 |
 | 2 sunzhenyucn 345 天前 我们在用它搭建企业内的 IAM ，你的问题是什么呢？ |
 | 3 COW OP @sunzhenyucn 目前暂时想先把 gitea 、jenkins 之类跟产品交付流程相关的内部系统集利用 ldap 集成进去，做 SSO 和统一认证。 对于一些额外的功能，比如日志审计，像 gitea 、jenkins 本来就已经有这些功能了，keycloak 用上是不是功能重叠了？还有角色权限这块，是不是可以利用 keycloak 统一设置，然后 gitea 、jenkins 也能自动同步设置好角色权限？（或者利用一些插件同步，不知道靠不靠谱） |
| 4 sunzhenyucn 345 天前 1 1. 关于你说的利用 LDAP 集成，这边建议是统一采用泛用性更强的 OIDC 协议 2. Keycloak 的 Audit 和其他系统的 Audit 并不相同，Keycloak 的 Audit 更关注的是认证与授权事件的审计，而类似于 Jenkins 等系统的审计更关注的是系统本身的业务操作审计 3. Keycloak 的角色权限较为复杂，Authorization 功能也仅限于 OIDC 协议使用，如果需要做集成的话可能需要对客户端（类似但不限于 Jenkins 、Gitea 等）做二次开发才能够实现 P.S. 我们对于 Keycloak 的 Authorization 等概念做了一些更高层的抽象，并且我们的鉴权模型为 PBAC ，我们的做法是通过开发 Keycloak 插件将 Authorization 内的一些概念类似但不限于 Permission, Scope, Resource 等与 PBAC 中的概念做了一一映射。 |
| 5 COW OP @sunzhenyucn #4 好吧，感觉我是想多了，这样要二次开发的系统就太多了，角色权限这块还是用系统自身的好了，不过很好奇你们为什么要在 Keycloak 已有授权的基础上加一层呢，是业务上不满足需求还是有别的原因？ |
| 6 sunzhenyucn 345 天前 @COW 因为我们使用 IAM 的目的是为我们自己的应用云平台上的所有 SaaS 或 On-Permis 应用提供统一的认证和鉴权框架，包括我们自己的应用云平台上的 Open API 类产品也是托管在我们平台上进行认证和鉴权的，这种场景的细粒度授权 RBAC 不合适所以我们自己基于 Keycloak 封装了一套 PBAC |
Select Language