Holistic Environment Design

1. Holistic Environment Design

James Albert

Posted 9 days ago

Hello,

We’re currently moving from on-site instances of ForgeRock (v6.5) to Identity Cloud (FRIC). Before on-site ForgeRock we spent three years with another vendor. In each case, we’ve interacted exclusively with the product/services via API. Even our admin processes are coded utilizing back-end APIs. To date, we’ve only used the UI for one-offs/research. In each of these implementations we’ve had three instances. The names have differed, but their purpose has remained the same: one is production, one is load testing, and one is everything else (Test, Integration, QA and Regression).

In the Dev tenant we define accounts and roles with environment identifiers. In the other instances, it’s not an issue as they’re dedicated to a single environment. The question I have revolves around the best approach to integrating FRIC into a full development stack? As some background, our CIAM team has decades of enterprise software development experience. We can write tools to help accomplish the goal, but we don’t want to define a model that creates issues or a lot of extra work testing and maintaining deployment logic. Our task is CIAM.

Knowing that “all environments are production for someone”, since the Dev tenant houses all environments below load testing, we try to be as careful in the Dev tenant as production. One mistake and everyone on the development side, except load testers are down which means the CIAM team is having a really bad day. We need to change our design. Continually doing like-for-like migrations has worked us into a situation where all Dev tenant consumers are using the same journeys, scripts and custom endpoints (not to mention everything else). We currently have no way to implement updates and move them up the stack one development environment at a time, which means that nothing of substance can be implemented without causing issues. We don’t have a problem updating the design and coding tools to meet our needs, but I’m not sure there’s a clean, reliable, efficient solution.

  • Development Tenant/Instance
    Before speaking of concerns about the product development “Dev” tenant (test, int, qa, reg), I should say that no matter what, we need a true FRIC dev/development instance. An instance used by the CIAM team to research, design and develop FRIC updates. We’re considering a sandbox or using ForgeOps containers, but those will need to be configured from the Dev tenant and populated with at least a subset of the Dev tenant data. None of that logic exists today. We have a lot of the FRIC object CRUD logic coded (scripts, journeys, endpoints, ESVs, etc.), but nothing specific to promotions, yet.

Back to thoughts about the FRIC Dev/Staging/Prod tenants…

  1. Versioning Objects
    We could version each object, i.e.: journey1_v1, journey1_v2, script1_v1, script1_v2, etc. That causes concerns as journeys reference scripts, so each new version would mean a lot of updates (likely manual) and testing to make sure we didn’t miss any that could show up late in the development cycle. We also have a concern that all objects will be promoted to Staging and Production, creating additional, unnecessary attack surface (and bloat). One of the larger issues with this concept is that our consuming applications would need to be pointed to the appropriate/new version, which means all consuming apps would need to be updated and deployed with every ForgeRock update. This would likely slow FRIC development dramatically. The tooling required to automate it, although fun to write, would become yet another app that needed to be thoroughly tested with each FRIC “version”. Then there’s the bloat, when are older versions removed?

  2. Environment Specific Objects
    We could take the path that we have with accounts and roles. We could create a set of objects for each environment, i.e.: journey1_test, journey1_int, script1_test, script1_int, etc. This means that consuming apps would always point to objects identified for their environment. We could update ForgeRock without updating consuming applications. Again, we have a concern that all objects will be promoted to Staging and Production, creating additional, unnecessary attack surface. A question here is how updates would “move up the stack”? It feels as though updates would have to be promoted manually. If automated, the tooling required would become yet another app that needed to be thoroughly tested with each FRIC “version”. It feels as though this process would likely be more prone to mistakes than versioning.

  3. Additional Tenants
    It would be a substantial shift for FRIC and isn’t at all likely, but creating Test, Int, QA and Regression tenants, tied into the FRIC promotion process would facilitate the need. I’ve added this only because it’s a possibility, although probably not a possibility.

My questions…
Does anyone else have these types of issues?
If so, have you been able to address it satisfactorily?

I’m assuming I’ll have more ideas over time. I’ll add them to this conversation when they hit me.


James Albert