Migration and customization
|
This is not a comprehensive platform implementation guide. These sample setup instructions show a minimal integration of platform components to get you started. The ForgeRock Identity Platform offers maximum extensibility and flexibility in self-managed deployments. The platform includes many features and options these sample setup instructions do not cover. If you don’t need maximum extensibility and flexibility, there are simpler alternatives:
For help with your deployment and to validate your plans before deploying in production, contact ForgeRock. |
Previous versions of the ForgeRock Identity Platform provided a sample deployment called the Full stack sample. This kind of deployment is not supported for new integrations between IDM and AM, and you should follow the steps outlined here to set up a new deployment. There is no automated migration facility for an existing deployment based on the full stack sample, but you can follow the tips in this chapter help you move to a new integrated deployment.
|
This is not an exhaustive list and you will have additional configuration changes to make, based on how you deployed the full stack sample. |
- Self-service configuration
-
All self-service configuration is now done in the AM UI, with the exception of the following elements:
-
KBA
-
Terms & Conditions
-
Policies
-
Privacy & Consent
-
Email templates and services
You can therefore delete all the IDM
selfservice*files from your configuration, apart fromselfservice.kba.jsonandselfservice.terms.json. These two files are still used by the new AM authentication trees.You will need to rebuild all existing self-service processes as AM authentication trees. Note that tree nodes are more modular than the legacy IDM self-service stages. It might take more than one node to replace a self-service stage.
In a platform configuration, you can optionally customize the IDM admin UI to hide or remove all of the self-service functions that are no longer configured through IDM (such as registration and password reset).
-
- Authentication
-
Integrated deployments now use a single
rsFilterauthentication module that allows authentication using AM bearer tokens. You must replace your project’sconf/authentication.jsonfile with this authentication.json file and customize it, according to your setup.Configure OAuth clients and the IDM provisioning service in the AM UI.
- UI customization
-
The UI retrieves access tokens from AM. If you have customized your Self-Service UI for a full-stack deployment, it is recommended that you start a new customization, based on the Platform UI. Your existing UI customizations will not work in a new platform deployment.
- Migration for shared identities
-
As shown in Shared identity store,AM and IDM can share a DS identity store. Since version 7, this is a well-supported and recommended deployment pattern.
Previously, as shown in Separate identity stores and Reconciliation and AM in the IDM 6.5 documentation, AM used a DS-based identity store, IDM used a relational database for its repository, and IDM synchronized identities between them.
When you migrate shared identities to a shared DS identity store, follow these high-level steps:
-
Add any custom identity attributes to the shared identity store and platform components.
Many deployments define custom attributes that serve in profiles or security tokens, which are critical to authentication and authorization, such as OAuth 2.0 access tokens, OpenID Connect ID tokens, and SAML assertions.
For detailed instructions, see Custom attributes.
-
Use IDM to migrate identity data to the shared DS identity store.
Make sure that any operations to modify managed objects, such as managed users, performed as part of the mapping (in
sync.json), are reflected in the managed object schema (inmanaged.json).For more on the migration operation, see Migrate data in the IDM documentation.
-