我们正在寻求实现开源身份管理系统，并已将 ForgeRock 的堆栈确定为最佳实现技术。
然而，ForgeRock 支持及其按用户定价模型的高成本是一个潜在的障碍。我们目前的用户群约为 45K，但我们预计在未来 2 年内将增加到 100 万。
因此，我们正在研究在没有 FR 支持的情况下继续进行的情况。缺少 FR 维护版本似乎会阻碍这一点，所以我们很好奇其他人是否已经走上了这条路。
- 您的经历如何？
- 您做过哪些项目？尺寸等
- 在没有 FR 维护版本的情况下，您是否能够轻松创建自己的补丁？
- 有哪些潜在的陷阱？
如果有处理此主题的博客或其他社区，请指出他们的大致方向。
谢谢。
最佳答案
作为一名社区用户，我在过去 6 年左右的时间里确实使用过 OpenAM(/OpenSSO) 和 OpenDJ，但这是一个非常小的部署(10k 用户只有两个产品的 1 个服务器实例)。
1) 在早期阶段，我们确实遇到了 OpenAM 的可靠性问题，我们主要通过重新启动服务器实例来解决这个问题——显然这不是首选，但我们并没有真正花费太多的开发精力来实际尝试解决它(加上当时缺乏必要的调查知识)。在花费一些实际努力尝试学习产品后，结果证明我们的大部分问题要么是我们自己造成的(自定义编写不当或配置错误)，要么实际上是最近在 OpenAM 项目中解决的问题并且相对简单向后移植到我们的版本。
当然，体验本身在很大程度上取决于您希望在部署中更改配置的频率，因为多年来我们并没有改变很多东西，OpenAM 只是在很长的时间间隔内工作得很好，不需要任何类型的维护。
3) 因为我们并没有真正遇到新问题(配置几乎没有改变)，所以一段时间后并没有太多惊喜。安全补丁大多很容易向后移植，并没有造成太大的麻烦(这确实帮助了我在 1.5 年后成为一名 FR 员工，并且我积极致力于 OpenAM 问题 :))
4) 我认为在没有订阅的情况下运行有其风险，但它们主要与:
- 您是否计划在那 2 年内推出基于 OpenAM 功能的新功能(即您是否计划不断更改部署)？
- 您有优秀的开发人员来处理这些功能吗？例如，使用 OpenAM 可以很容易地要求您查看源代码以弄清楚它是如何工作的，尽管这些年来文档的质量已经有了很大的提高。无论如何，随着时间的推移，向后移植修复将变得越来越困难，因为版本将有很大差异(因为每个项目的开发团队越来越大)——即使那样你也不能假设所有的根据定义，您遇到的问题已经在主干中得到解决。需要自行解决一些问题是您需要考虑的成本/风险。
- 您希望您的部署具有哪种 SLA？停电 1 分钟后您的企业会破产吗？频繁重启服务是否可以接受(以防遇到一些奇怪的问题)？
- 您真的需要对所有 3 种产品的支持吗？例如，我的背景可以让我在没有 OpenAM 支持的情况下轻松工作，但如果我的供应系统出现问题，我将陷入困境......
还有一个通用的评论:
让用户在两年内增长 20 倍听起来有点不现实，或者至少很有希望。也许您应该寻找更合理的目标数量的 1 年订阅，然后在您更好地了解您的业务中的客户增长后续订？
关于openam - 有没有人在没有使用 ForgeRock 的支持计划的情况下使用 OpenAM/OpenDJ/OpenIDM 套件？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29829702/