3

我们正在寻求实施一个开源身份管理系统，并将 ForgeRock 的堆栈确定为最佳实施技术。

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

因此，我们正在研究在没有 FR 支持的情况下继续进行的情况。缺乏 FR 维护版本似乎对此有所阻碍，所以我们很好奇其他人是否已经走这条路。

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

如果有博客或其他社区处理这个话题，请指出他们的大方向。

谢谢。

4

1 回答 1

5

作为社区用户，在过去 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 年订阅，然后在您更好地了解业务中的客户增长后进行续订？

于 2015-04-28T16:47:28.590 回答