Forgerock AM APIs/Tree versioning, simultaneous support for multiple versions

Forgerock AM APIs/Tree versioning, simultaneous support for multiple versions

If someone has implemented for Forgerock AM APIs/Tree versioning and in a complex user journey, kindly let me know.

MobileApp must interface with AM Journey and handle 2 FR API versions (old vs. new versions of the mobile app).

Greetings Kumar,
There are many ways to satisfy this use case. The simplest would be to uniquely name the Auth-N trees as unique inner trees and reference them from your default outer tree. The outer tree provides the decision node and logic in order to target the appropriate inner tree.

There are a number of resources available for your information:
Start here: Authentication nodes and trees :: AM 7.4.0
Then: Knowledge - ForgeRock BackStage

1 Like

Thanks guy for your prompt response, suggestions and the reference links. unfortunately, the tree/journey(s) which we designed/built is complex and includes several custom and out-of-the-box, scripted authN nodes, and multiple inner trees that are connected to the parent tree (primary api). I looked at the reference, and while it contains generic information on building trees, I was unable to find info related versioning. I may have missed something, so please share if you have of any information regarding versioning for trees or custom journeys. In addition, Maintaining unique version scripted nodes and scripts (all connected nodes including inner trees) of such complex journeys seems challenging with the proposed approach.

Yes, versioning of the tree can only be accomplished by the developers naming standards for the trees in question, concurrently deployed to AM… However, typically we do not do this.

Versioning of the APIs are included in the product. Versioning of the configuration objects (of which an Authentication Tree is an example) is not included in the product.
Should such a requirement be necessary, you would need to merge the objects from your versioning service into AM. I have only ever seen this done with a suitable naming practice of the deployed artifacts supporting the Authentication Trees.
Additionally, I think the following resource may be of value to you: