有没有人使用OpenAM / OpenDJ / OpenIDM套件而不使用ForgeRock的支持计划？

Question

我们希望实施一个开源身份管理系统，并确定ForgeRock的堆栈是最好的技术。

然而，ForgeRock支持的高成本及其每用户定价模式是一个潜在的障碍。我们目前的用户群约为45K，但我们预计在未来两年内将达到1M。

因此，我们正在研究没有FR支持的情况。 FR维护版本的缺乏似乎会对此产生影响，所以如果其他人走了这条路线，我们会感到好奇。

1. 你的经历是什么？
2. 你做了什么样的项目？大小等。
3. 在没有FR维护版本的情况下，您是否能够轻松创建自己的补丁？
4. 有哪些潜在的陷阱？

如果有博客或其他社区处理此主题，请指出我的总体方向。

感谢。

Answer 1

作为社区用户，我在过去6年左右的时间里确实使用过OpenAM（/ OpenSSO）和OpenDJ，但这是一个非常小的部署（10k用户只有1个服务器实例来自两个产品）。

1）在早期阶段，我们确实遇到过OpenAM的可靠性问题，我们主要通过重新启动服务器实例来解决这些问题 - 显然不是首选，但我们并没有真正花费太多的开发工作来实际尝试解决它（当时缺乏必要的调查知识）。在花了一些实际的努力来尝试学习产品之后，我们发现我们的大部分问题都是自己造成的（编写错误的自定义或错误配置），或者实际上是在OpenAM项目中最近解决的问题并且相对简单向后移植到我们的版本。

当然，体验本身在很大程度上取决于您希望在部署中进行配置更改的频率，因为多年来我们没有改变很多事情，OpenAM只是在很长的时间间隔内工作得很好而不需要任何类型的维护。

3）由于我们没有真正遇到新问题（配置几乎没有改变），一段时间后没有太多意外。安全补丁大多数都很简单，不会造成太大的麻烦（这确实有助于我成为FR员工一年后，我积极致力于OpenAM问题:)但

4）我认为没有订阅的运行有其风险，但它们主要涉及：

• 您打算在这两年内推出基于OpenAM功能的新功能（即您是否计划不断对部署进行更改）？
• 你有好的开发人员来处理这些功能吗？例如，使用OpenAM可以很容易地要求您查看源代码以了解工作原理，多年来文档的质量已经提高了很多。无论如何，随着时间的推移，向后移植修复将变得越来越困难，因为版本会有很大差异（因为开发团队对于每个项目变得越来越大） - 即便如此，你不能只假设所有的您遇到的问题根据定义已在trunk中解决。需要自行解决一些问题是需要考虑的成本/风险。
• 您希望在部署中使用哪种SLA？中断1分钟后你的公司破产了吗？经常重启你的服务是否可以接受（如遇到一些奇怪的问题）？
• 你真的需要支持所有3种产品吗？例如，我的背景将允许我在没有OpenAM支持的情况下轻松工作，但如果我的配置系统出现问题，我会处于最深处......

一般说法：

两年内用户增长20倍听起来有点不切实际，或至少非常有希望。也许您应该寻找的是1年订阅更合理的目标数量，然后在您更好地了解您的业务中的客户增长后再续订？