diff --git a/openidm/modules/connectors-guide/pages/chap-ad.adoc b/openidm/modules/connectors-guide/pages/chap-ad.adoc index 708f160e3a..240fb3aa26 100644 --- a/openidm/modules/connectors-guide/pages/chap-ad.adoc +++ b/openidm/modules/connectors-guide/pages/chap-ad.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -37,7 +37,7 @@ Before you configure the Active Directory Connector, make sure that the .NET Con .Setting Up the Active Directory Connector ==== -. Download the Active Directory Connector from link:https://forgerock.org/downloads/[ForgeRock's download page, window=\_blank]. +. Download the Active Directory Connector from the link:https://github.com/OpenIdentityPlatform/OpenICF/releases/[GitHub, window=\_blank]. . Extract the contents of the AD Connector zip file into the directory in which you installed the Connector Server (by default `c:\Program Files (x86)\Identity Connectors\Connector Server>`). + diff --git a/openidm/modules/connectors-guide/pages/chap-google.adoc b/openidm/modules/connectors-guide/pages/chap-google.adoc index c07344a9ef..abc879ee02 100644 --- a/openidm/modules/connectors-guide/pages/chap-google.adoc +++ b/openidm/modules/connectors-guide/pages/chap-google.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -24,7 +24,7 @@ [#chap-google] == Google Apps Connector -The link:https://forgerock.org/downloads/[Enterprise build, window=\_blank] of OpenIDM includes a Google Apps connector, along with a sample connector configuration. The Google Apps Connector enables you to interact with Google's web applications. +link:https://github.com/OpenIdentityPlatform/OpenICF[OpenICF, window=\_blank] includes a Google Apps connector, along with a sample connector configuration. The Google Apps Connector enables you to interact with Google's web applications. [#google-connector-config] === Configuring the Google Apps Connector diff --git a/openidm/modules/connectors-guide/pages/chap-salesforce.adoc b/openidm/modules/connectors-guide/pages/chap-salesforce.adoc index aabe821f06..558a795f7f 100644 --- a/openidm/modules/connectors-guide/pages/chap-salesforce.adoc +++ b/openidm/modules/connectors-guide/pages/chap-salesforce.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -24,7 +24,7 @@ [#chap-salesforce] == Salesforce Connector -The link:https://forgerock.org/downloads/[Enterprise build, window=\_blank] of OpenIDM includes a Salesforce connector, along with a sample connector configuration. The Salesforce connector enables provisioning, reconciliation, and synchronization between Salesforce and the OpenIDM repository. +link:https://github.com/OpenIdentityPlatform/OpenICF[OpenICF, window=\_blank] includes a Salesforce connector, along with a sample connector configuration. The Salesforce connector enables provisioning, reconciliation, and synchronization between Salesforce and the OpenIDM repository. To use this connector, you need a Salesforce account, and a Connected App that has OAuth enabled, which will allow you to retrieve the required consumer key and consumer secret. diff --git a/openidm/modules/connectors-guide/pages/chap-sap.adoc b/openidm/modules/connectors-guide/pages/chap-sap.adoc index e3d2c9d337..ef9b2c5191 100644 --- a/openidm/modules/connectors-guide/pages/chap-sap.adoc +++ b/openidm/modules/connectors-guide/pages/chap-sap.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -37,9 +37,9 @@ The sample scripts illustrate the following scenarios: === Before You Start -* The SAP connector is provided only with the OpenIDM Enterprise build, and is available on the link:https://backstage.forgerock.com[ForgeRock Backstage, window=\_blank] site. +* The SAP connector is available on the link:https://github.com/OpenIdentityPlatform/OpenICF/releases[GitHub, window=\_blank] site. -* The SAP connector requires the SAP Java Connector (JCo) libraries, version 3.0.12 or later. ForgeRock distributes the SAP connector without these JCo libraries. Before you can use the SAP connector, you must obtain the JCo libraries that correspond to your architecture. +* The SAP connector requires the SAP Java Connector (JCo) libraries, version 3.0.12 or later. Open Identity Platform Community distributes the SAP connector without these JCo libraries. Before you can use the SAP connector, you must obtain the JCo libraries that correspond to your architecture. @@ -49,7 +49,7 @@ The sample scripts illustrate the following scenarios: ==== -. Download the SAP connector from the link:https://backstage.forgerock.com[ForgeRock Backstage, window=\_blank] site. +. Download the SAP connector from the link:https://github.com/OpenIdentityPlatform/OpenICF/releases/[GitHub, window=\_blank]. . Copy the SAP connector JAR file (`sap-connector-1.4.0.0.jar`) to the `openidm/connectors` directory: + @@ -139,7 +139,7 @@ For optimum performance, set this value to an integer between `5` and `10`. -- -. To test this connector, you can use the sample Groovy scripts available from the link:https://maven.forgerock.org/repo/webapp/#/artifacts/browse/tree/General/releases/org/forgerock/openicf/connectors/sap-connector/1.4.0.0/sap-connector-1.4.0.0-sources.jar/samples/[ForgeRock Artifact Repository Browser, window=\_blank]. You can find the source for these scripts in this location, in the `samples/` directory, as well as the `samples/hr/` subdirectory. +. To test this connector, you can use the sample Groovy scripts available on the link:https://github.com/OpenIdentityPlatform/OpenICF/releases/[GitHub, window=\_blank]. You can find the source for these scripts in this location, in the `samples/` directory, as well as the `samples/hr/` subdirectory. + [none] * `TestSAP.groovy` @@ -497,7 +497,7 @@ For optimum performance, set this value to an integer between `5` and `10`. -- -. To test this connector, you can use the sample Groovy scripts available from the link:https://maven.forgerock.org/repo/webapp/#/artifacts/browse/tree/General/releases/org/forgerock/openicf/connectors/sap-connector/1.4.0.0/sap-connector-1.4.0.0-sources.jar/samples/[ForgeRock Artifact Repository Browser, window=\_blank]. You can find the source for these scripts in this location, in the `samples/` directory, as well as the `samples/r3/` subdirectory. +. To test this connector, you can use the sample Groovy scripts available on the link:hhttps://github.com/OpenIdentityPlatform/OpenICF/releases/[GitHub, window=\_blank]. You can find the source for these scripts in this location, in the `samples/` directory, as well as the `samples/r3/` subdirectory. + [none] * `TestSAP.groovy` diff --git a/openidm/modules/getting-started/pages/chap-where-to-go.adoc b/openidm/modules/getting-started/pages/chap-where-to-go.adoc index 4092d4e59b..8017647c08 100644 --- a/openidm/modules/getting-started/pages/chap-where-to-go.adoc +++ b/openidm/modules/getting-started/pages/chap-where-to-go.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -129,7 +129,7 @@ OpenIDM is a lightweight and highly customizable identity management product. The OpenIDM documentation includes additional use cases. Most of them are known as __Samples__, and are described in xref:samples-guide:chap-overview.adoc#chap-overview["Overview of the OpenIDM Samples"] in the __Samples Guide__. -These samples include step-by-step instructions on how you can connect to different data stores, customize product behavior using JavaScript and Groovy, and administer OpenIDM with ForgeRock's commons RESTful API commands. +These samples include step-by-step instructions on how you can connect to different data stores, customize product behavior using JavaScript and Groovy, and administer OpenIDM with Open Identity Platform's commons RESTful API commands. [#gsg-integration] diff --git a/openidm/modules/install-guide/pages/chap-install.adoc b/openidm/modules/install-guide/pages/chap-install.adoc index 7b65bb7942..4de0d66a7b 100644 --- a/openidm/modules/install-guide/pages/chap-install.adoc +++ b/openidm/modules/install-guide/pages/chap-install.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -28,7 +28,7 @@ This chapter covers the tasks required to install and start OpenIDM. [NOTE] ==== -ForgeRock documentation includes a separate xref:samples-guide:index.adoc[Samples Guide]. When you have read the first two chapters of this document, you can use the xref:samples-guide:index.adoc[Samples Guide] to test OpenIDM in a number of different configurations. +Open Identity Platform documentation includes a separate xref:samples-guide:index.adoc[Samples Guide]. When you have read the first two chapters of this document, you can use the xref:samples-guide:index.adoc[Samples Guide] to test OpenIDM in a number of different configurations. ==== [#before-you-start] @@ -118,7 +118,7 @@ Follow these steps to run OpenIDM interactively: . Start the Felix container, load all OpenIDM services, and start a command shell to allow you to manage the container: + - +-- * Start OpenIDM (UNIX): + @@ -136,7 +136,6 @@ Using boot properties at /path/to/openidm/conf/boot/boot.properties * Start OpenIDM (Windows): + - [source, console] ---- C:\> cd \path\to\openidm @@ -151,9 +150,7 @@ Using boot properties at \path\to\openidm\conf\boot\boot.properties -> ---- -+ At the OSGi console `->` prompt, you can enter commands such as `help` for usage, or `ps` to view the bundles installed. To see a list of all the OpenIDM core services and their states, enter the following command: -+ [source, console] ---- @@ -220,11 +217,11 @@ At the OSGi console `->` prompt, you can enter commands such as `help` for usage [ 29] [active ] org.forgerock.openidm.maintenance -> ---- -+ + A default startup does not include certain configurable services, which will indicate an `unsatisfied` state until they are included in the configuration. As you work through the sample configurations described later in this guide, you will notice that these services are active. -+ -Startup errors and messages are logged to the console by default. You can also view these messages in the log files at `/path/to/openidm/logs`. +Startup errors and messages are logged to the console by default. You can also view these messages in the log files at `/path/to/openidm/logs`. +-- . Alternatively, you can manage the container and services from the Apache Felix Web Console. + Use these hints to connect to the Apache Felix Web Console: @@ -304,12 +301,11 @@ C:\openidm\bin> [source, console] ---- C:\openidm\bin>install-service.bat openidm -ForgeRock Launcher Java Service successfully installed as "openidm" service +Open Identity Platform Launcher Java Service successfully installed as "openidm" service ---- . Use the Windows Service manager to manage the OpenIDM service. - - ++ [#d9505e641] image::ROOT:windows-service.png[] @@ -326,15 +322,12 @@ To change the user account: .. Select This Account and browse for an Active Directory administrative account. .. Enter the password for the administrative account. - - ++ [#d9505e676] image::ROOT:service-acct.png[] - .. Click Apply to save the changes. - . Use the Windows Service Manager to start, stop, or restart the service. . To uninstall the OpenIDM service stop the service, then run the following command: @@ -525,7 +518,7 @@ $ curl \ "https://localhost:8443/openidm/managed/user/joe" \ | jq . ---- -The ForgeRock REST API includes an optional `_prettyPrint` request parameter. The default value is `false`. To use the ForgeRock REST API to format output, add a parameter such as `?_prettyPrint=true` or `&_prettyPrint=true`, depending on whether it is added to the end of an existing request parameter. In this case, the following command would return formatted output: +The Open Identity Platform REST API includes an optional `_prettyPrint` request parameter. The default value is `false`. To use the Open Identity Platform REST API to format output, add a parameter such as `?_prettyPrint=true` or `&_prettyPrint=true`, depending on whether it is added to the end of an existing request parameter. In this case, the following command would return formatted output: [source, console] ---- diff --git a/openidm/modules/install-guide/pages/chap-update.adoc b/openidm/modules/install-guide/pages/chap-update.adoc index 8197a4542a..143aa478d9 100644 --- a/openidm/modules/install-guide/pages/chap-update.adoc +++ b/openidm/modules/install-guide/pages/chap-update.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -24,23 +24,14 @@ [#chap-update] == Updating OpenIDM -The update process is largely dependent on your deployment and on the extent to which you have customized OpenIDM. Engage link:https://www.forgerock.com/support/support-services[ForgeRock Support Services, window=\_top] for help in updating an existing deployment. +The update process is largely dependent on your deployment and on the extent to which you have customized OpenIDM. Engage link:https://github.com/OpenIdentityPlatform/.github/wiki/Approved-Vendor-List[Open Identity Platform Approved Vendors, window=\_top] for help in updating an existing deployment. If you are updating from OpenIDM 4.0, you can take advantage of new OpenIDM update options from the command line and the Admin UI. For a generic view of the update process, see xref:#update-process["An Overview of the OpenIDM Update Process"]. -If you are migrating a deployment from earlier versions of OpenIDM, follow the manual update process. - -* To migrate a deployment from OpenIDM 3.1.0 to OpenIDM 4.0, see link:../../../openidm/4/install-guide/#migrate-idm-314[Migrating From OpenIDM 3.1 to OpenIDM 4.0, window=\_blank] in the __OpenIDM 4 Installation Guide__. - -* To migrate a deployment from OpenIDM 3.0.0 to 3.1.0, see link:../../../openidm/3.1/install-guide/#chap-upgrade[Migrating to OpenIDM 3.1.0, window=\_blank] in the __OpenIDM 3.1.0 Installation Guide__. - -* To migrate a deployment from OpenIDM 2.1.0 to 3.0.0, see link:../../../openidm/3/install-guide/#chap-upgrade[Migrating to OpenIDM 3.0.0, window=\_blank] in the __OpenIDM 3.0.0 Installation Guide__. - - [#update-process] === An Overview of the OpenIDM Update Process -This section provides background information on the OpenIDM update process. If you want to jump to the steps required to update OpenIDM from version 4.0 to 4.5, read xref:#migrate-idm-40-45["Updating From OpenIDM 4.0 to OpenIDM 4.5"]. +This section provides background information on the OpenIDM update process. OpenIDM must be running when you launch an update (using the UI or the CLI). This section details the capabilities of the OpenIDM update process, in the following sub-sections: @@ -211,7 +202,7 @@ The URL of the OpenIDM REST service. The default URL is `\http://localhost:8080/ The port number associated with the OpenIDM REST service. If specified, this option overrides any port number specified with the `--url` option. The default port is 8080. This option is used by all three subcommands. `--acceptLicense`:: -Automatically accept the license shown in `/path/to/openidm/legal-notices/Forgerock_License.txt`. If you omit this option, the update process prompts you to accept or decline the license. +Automatically accept the license shown in `/path/to/openidm/legal-notices/CDDLv1_0.txt`. If you omit this option, the update process prompts you to accept or decline the license. `--skipRepoUpdatePreview`:: Bypasses a preview of repository updates. Suitable if you have already downloaded and approved changes to your repository. @@ -403,7 +394,7 @@ Because of the transition between the OpenIDM 4.0 and OpenIDM 4.5 update service * Download the update binaries. + -To update from OpenIDM 4.0 to OpenIDM 4.5, navigate to ForgeRock's link:https://backstage.forgerock.com/[BackStage, window=\_blank] site and download the following binaries: +To update from OpenIDM 4.0 to OpenIDM 4.5, navigate to Open Identity Platform's link:https://github.com/OpenIdentityPlatform/OpenIDM/releases[BackStage, window=\_blank] repository and download the following binaries: + ** Update Patch 1 (`openidm-4.0.0-1.zip`) @@ -413,7 +404,6 @@ To update from OpenIDM 4.0 to OpenIDM 4.5, navigate to ForgeRock's link:https:// ** OpenIDM 4.5 (`openidm-4.5.0.zip`) + -Access to the update binaries is restricted to ForgeRock customers. * Before starting the update process, extract and apply the repository update scripts from the OpenIDM 4.5 binary. You may want to share them with your Database Administrator (DBA). For more information, see xref:#update-4045-repo["Updating OpenIDM 4.0, Repository Scripts"]. @@ -476,7 +466,7 @@ $ mysql -u root -p < /path/to/openidm/db/mysql/scripts/updates/v2_shorten_link_c ==== The OpenIDM repository update scripts address the differences between the OpenIDM 4.0 and OpenIDM 4.5 supported repositories. They may not address any custom schema, columns, or tables that you have implemented in production. -As OrientDB is not supported in production, ForgeRock does not support updates of deployments with that repository, and OpenIDM 4.5 does not include OrientDB update scripts. +As OrientDB is not supported in production, Open Identity Platform Community does not support updates of deployments with that repository, and OpenIDM 4.5 does not include OrientDB update scripts. ==== @@ -835,7 +825,8 @@ If you want to set up a script for this process, note the delay between the `Res . Log into the Admin UI at `\http://localhost:8080/admin`. -. +. {nbsp} ++ [WARNING] ====== Updating the repository is your responsibility. You should have already done so in xref:#update-4045-repo["Updating OpenIDM 4.0, Repository Scripts"]. Assuming that is true, confirm this when the Admin UI prompts you to download and acknowledge that you've run these scripts. diff --git a/openidm/modules/integrators-guide/pages/appendix-audit.adoc b/openidm/modules/integrators-guide/pages/appendix-audit.adoc index 8dedf19ed8..0bd4633557 100644 --- a/openidm/modules/integrators-guide/pages/appendix-audit.adoc +++ b/openidm/modules/integrators-guide/pages/appendix-audit.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -131,7 +131,7 @@ The following code is an excerpt from the `audit.json` file, with Elasticsearch ---- You should also set up configuration for the Elasticsearch event handler. The entries shown are defaults, and can be configured. In fact, if you have set up Elasticsearch Shield, with or without SSL/TLS, as described in xref:#elastic-install["Installing and Configuring Elasticsearch"], you should change some of these defaults. -[source, javascript] +[source, json] ---- "eventHandlers" : [ { @@ -169,7 +169,7 @@ If you set `useSSL` to true, add the following properties to the `connection` co [source, javascript] ---- "username" : "myUsername", - "password" : "myPassword", +"password" : "myPassword", ---- For more information on the other options shown in `audit.json`, see xref:#audit-event-prop["Common Audit Event Handler Property Configuration"]. @@ -633,7 +633,7 @@ Two properties shown only in the `audit.json` file for your project are: * The class name used to build the handler, which may shown as one of the `availableAuditEventHandlers`, as shown in this excerpt from the `audit.json` file: + -[source, javascript] +[source, json] ---- "availableAuditEventHandlers" : [ "org.forgerock.audit.handlers.elasticsearch.ElasticsearchAuditEventHandler", @@ -646,7 +646,7 @@ Two properties shown only in the `audit.json` file for your project are: * The audit event handler `config` property, which comes after a second instance of the class name of that audit event handler. For an example, see the following excerpt of an `audit.json` file: + -[source, javascript] +[source, json] ---- "eventHandlers" : [ { @@ -771,7 +771,7 @@ a|Buffering: avoids flushing after each event |=== Except for the common properties shown in xref:#audit-event-prop["Common Audit Event Handler Property Configuration"], the Repository and Router audit event handlers share one unique property: `resourcePath`: -[source, javascript] +[source, json] ---- { "class" : "org.forgerock.openidm.audit.impl.RouterAuditEventHandler", @@ -796,7 +796,7 @@ a|Path to the repository resource [NOTE] ==== -Take care when reading JMS properties in the `audit.json` file. They include the standard ForgeRock audit event topics, along with JMS-unique topics: +Take care when reading JMS properties in the `audit.json` file. They include the standard Open Identity Platform audit event topics, along with JMS-unique topics: ==== [#audit-config-prop-jms] diff --git a/openidm/modules/integrators-guide/pages/appendix-auth-modules.adoc b/openidm/modules/integrators-guide/pages/appendix-auth-modules.adoc index 1367bd6cbe..b6c609833f 100644 --- a/openidm/modules/integrators-guide/pages/appendix-auth-modules.adoc +++ b/openidm/modules/integrators-guide/pages/appendix-auth-modules.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -185,7 +185,7 @@ The options shown in the screen are subdivided into basic and advanced propertie image::ROOT:openam-auth-basic.png[] The following table describes the label that you see in the Admin UI, the default value (if any), a brief description, and the associated configuration file. If you need the property name, look at the configuration file. -The default values shown depict what you see if you use the `OPENAM_SESSION` module with the Full Stack Sample. For more information, see xref:samples-guide:chap-fullstack-sample.adoc#chap-fullstack-sample["Full Stack Sample - Using OpenIDM in the ForgeRock Identity Platform"] in the __Samples Guide__. +The default values shown depict what you see if you use the `OPENAM_SESSION` module with the Full Stack Sample. For more information, see xref:samples-guide:chap-fullstack-sample.adoc#chap-fullstack-sample["Full Stack Sample - Using OpenIDM in the Open Identity Platform"] in the __Samples Guide__. [#table-openam-basic] .OPENAM_SESSION Module Basic Properties diff --git a/openidm/modules/integrators-guide/pages/appendix-file-layout.adoc b/openidm/modules/integrators-guide/pages/appendix-file-layout.adoc index 688be73a10..d50ad0d154 100644 --- a/openidm/modules/integrators-guide/pages/appendix-file-layout.adoc +++ b/openidm/modules/integrators-guide/pages/appendix-file-layout.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -215,7 +215,7 @@ Bundle cache directory created when the Felix framework is started Startup scripts for the __Getting Started__ sample configuration. For more information, see xref:getting-started:index.adoc[Getting Started]. `openidm/legal-notices`:: -Licence files for ForgeRock and third-party components used by OpenIDM. +Licence files for Open Identity Platform and third-party components used by OpenIDM. `openidm/lib`:: Location in which third-party libraries (required, for example, by custom connectors) should be placed. @@ -276,7 +276,7 @@ Script to start OpenIDM services on Windows Script to start OpenIDM services on UNIX `openidm/tools`:: -Location of the custom scripted connector bundler, described in the link:http://openicf.forgerock.org/doc/bootstrap/dev-guide/index.html#chap-custom-bundler[OpenICF Developers Guide, window=\_blank]. +Location of the custom scripted connector bundler, described in the link:https://github.com/OpenIdentityPlatform/OpenICF/wiki/Developer-Guide[OpenICF Developers Guide, window=\_blank]. `openidm/ui/admin/*`:: Configuration files for the Admin UI. diff --git a/openidm/modules/integrators-guide/pages/appendix-jetty.adoc b/openidm/modules/integrators-guide/pages/appendix-jetty.adoc index c5d5dba556..9eb4f9cfed 100644 --- a/openidm/modules/integrators-guide/pages/appendix-jetty.adoc +++ b/openidm/modules/integrators-guide/pages/appendix-jetty.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -126,13 +126,13 @@ A sample servlet filter configuration is provided in the `servletfilter-cors.jso The sample servlet filter configuration file is shown below: -[source, javascript] +[source, json] ---- { "classPathURLs" : [ ], "systemProperties" : { }, "requestAttributes" : { }, - "scriptExtensions" : { }. + "scriptExtensions" : { }, "initParams" : { "allowedOrigins" : "https://localhost:8443", "allowedMethods" : "GET,POST,PUT,DELETE,PATCH", @@ -225,7 +225,7 @@ To exclude another protocol from the `Enabled` list, just add it to the `"Exclud ---- You can reverse the process by removing the protocol from the `"ExcludeProtocols"` block. -To see if certain protocols should be included in the `"ExcludeProtocols"` block, review the current list of link:https://forgerock.org/security-advisories/[ForgeRock Security Advisories, window=\_blank] +To see if certain protocols should be included in the `"ExcludeProtocols"` block. For more information on Jetty configuration see the following document from the developers of link:http://www.eclipse.org/jetty/documentation/current/[Jetty: The Definitive Reference, window=\_blank] diff --git a/openidm/modules/integrators-guide/pages/appendix-rest.adoc b/openidm/modules/integrators-guide/pages/appendix-rest.adoc index 44b939bf6c..aee3a3b60d 100644 --- a/openidm/modules/integrators-guide/pages/appendix-rest.adoc +++ b/openidm/modules/integrators-guide/pages/appendix-rest.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -27,7 +27,7 @@ Representational State Transfer (REST) is a software architecture style for exposing resources, using the technologies and protocols of the World Wide Web. REST describes how distributed data objects, or resources, can be defined and addressed. OpenIDM provides a RESTful API for accessing managed objects, system objects, workflows, and some elements of the system configuration. -The ForgeRock implementation of REST, known as commons REST (CREST), defines an API intended for common use across all ForgeRock products. CREST is a framework used to access various web resources, and for writing to RESTful resource providers (servers). +The Open Identity Platform implementation of REST, known as commons REST (CREST), defines an API intended for common use across all Open Identity Platform products. CREST is a framework used to access various web resources, and for writing to RESTful resource providers (servers). CREST is intended to support the following types of operations, described in detail in xref:#rest-supported-operations["Supported Operations"]: `Create`, `Read`, `Update`, `Delete`, `Action`, and `Query`. @@ -35,7 +35,7 @@ CREST is intended to support the following types of operations, described in det ==== The examples in this chapter show REST requests to OpenIDM over the regular (http) port. ==== -ForgeRock defines a JSON Resource core library, as a common framework to implement RESTful APIs. That core library includes two components: +Open Identity Platform Community defines a JSON Resource core library, as a common framework to implement RESTful APIs. That core library includes two components: -- `json-resource`:: @@ -48,7 +48,7 @@ Provides J2EE servlet integration. Defines a common HTTP-based REST API for inte [NOTE] ==== -You can examine the libraries associated with ForgeRock REST at http://commons.forgerock.org/forgerock-rest. +You can examine the libraries associated with Open Identity Platform REST at https://github.com/OpenIdentityPlatform/commons/tree/master/commons/rest. ==== [#rest-uri-scheme] @@ -727,13 +727,37 @@ This section describes the OpenIDM REST endpoints and provides a number of sampl [#rest-server-config] ==== Managing the Server Configuration Over REST -OpenIDM stores configuration objects in the repository, and exposes them under the context path `/openidm/config`. Single instance configuration objects are exposed under `/openidm/config/object-name`. +OpenIDM stores configuration objects in the repository, and exposes them under the context path `/openidm/config`. Single instance configuration objects are exposed under `/openidm/config/*_object-name_*`. -Multiple instance configuration objects are exposed under `/openidm/config/object-name/instance-name`. The following table outlines these configuration objects and how they can be accessed through the REST interface. +Multiple instance configuration objects are exposed under `/openidm/config/*_object-name_*/*_instance-name_*`. The following table outlines these configuration objects and how they can be accessed through the REST interface. -[cols="50%,10%,40%"] +[cols="50%,10%,40%",stripes=even] |=== -|URI |HTTP Operation |Description +|URI |HTTP Operation |Description +a| /openidm/config +a| GET +a| Returns a list of configuration objects + +a| /openidm/config/audit +a| GET +a| Returns the current logging configuration + +a| /openidm/config/provisioner.openicf/*_provisioner-name_* +a| GET +a| Returns the configuration of the specified connector + +a| /openidm/config/router +a| PUT +a| Changes the router configuration. Modifications are provided with the `--data` option, in JSON format. + +a| /openidm/config/*_object_* +a| PATCH +a| Changes one or more fields of the specified configuration object. Modifications are provided as a JSON array of patch operations. + +a| /openidm/config/*_object_* +a| DELETE +a| Deletes the specified configuration object. + |=== OpenIDM supports REST mappings for create, read, update, query, and delete of configuration objects. @@ -777,10 +801,51 @@ $ curl \ User objects are stored in the repository and are exposed under the context path `/managed/user`. Many examples of REST calls related to this context path exist throughout this document. The following table lists available functionality associated with the `/managed/user` context path. -[cols="50%,10%,40%"] +[cols="50%,10%,40%",stripes=even] |=== -|URI |HTTP Operation |Description +|URI |HTTP Operation |Description + +a|/openidm/managed/user?_queryId=query-all-ids +a|GET +a| List the IDs of all the managed users in the repository + +a|/openidm/managed/user?_queryId=query-all +a|GET +a|List all info for the managed users in the repository + +a|/openidm/managed/user?_queryFilter=*__filter__* +a|GET +a|Query the managed user object with the defined filter. + +a|/openidm/managed/user/*__id_* +a|GET +a|Retrieve the JSON representation of a specific user + +a|/openidm/managed/user/*__id_* +a|PUT +a|Create a new user + +a|/openidm/managed/user/*__id_* +a|PUT +a|Update a user entry (replaces the entire entry) + +a|/openidm/managed/user?_action=create +a|POST +a|Create a new user + +a|/openidm/managed/user?_action=patch&_queryId=for-userName&uid=*__userName__* +a|POST +a|Update a user (can be used to replace the value of one or more existing attributes) + +a|/openidm/managed/user/*__id_* +a|PATCH +a|Update specified fields of a user entry + +a|/openidm/managed/user/*__id_* +a|DELETE +a|Delete a user entry |=== + The following example retrieves the JSON representation of all users stored in the internal repository. [source, console] @@ -866,9 +931,62 @@ $ curl \ System objects, that is, objects that are stored in remote systems, are exposed under the `/openidm/system` context. OpenIDM provides access to system objects over REST, as listed in the following table. -[cols="50%,10%,40%"] +[cols="50%,10%,40%",stripes=even] |=== -|URI |HTTP Operation |Description +|URI |HTTP Operation |Description + +a|/openidm/system?_action=*__action-name__* +a|POST +a| +`_action=availableConnectors` returns a list of the connectors that are available in `openidm/connectors` or in `openidm/bundle`. + +`_action=createCoreConfig` takes the supplied connector reference (`connectorRef`) and adds the configuration properties required for that connector. This generates a core connector configuration that you can use to create a full configuration with the `createFullConfig` action. + +`_action=createFullConfig` generates a complete connector configuration, using the configuration properties from the `createCoreConfig` action, and retrieving the object types and operation options from the resource, to complete the configuration. + +`_action=test` returns a list of all remote systems, with their status, and supported object types. + +`_action=testConfig` validates the connector configuration provided in the POST body. + +`_action=liveSync` triggers a liveSync operation on the specified source object. + +`_action=authenticate` authenticates to the specified system with the credentials provided. + +a|/openidm/system/*_system-name_*?_action=*__action-name__* +a|POST +a|`_action=test` tests the status of the specified system. + +a|/openidm/system/*_system-name_*/*_system-object_*?_action=*__action-name__* +a|POST +a| +`_action=liveSync` triggers a liveSync operation on the specified system object. + +`_action=script` runs the specified script on the system object. + +`_action=authenticate` authenticates to the specified system object, with the provided credentials. + +`_action=create` creates a new system object. + +a|/openidm/system/*_system-name_*/*_system-object_*?_queryId=query-all-ids +a|GET +a|Lists all IDs related to the specified system object, such as users, and groups. + +a|/openidm/system/*_system-name_*/*_system-object_*?_queryFilter=*__filter__* +a|GET +a|Lists the item(s) associated with the query filter. + +a|/openidm/system/*_system-name_*/*_system-object_*/*_id_* +a|PUT +a|Creates a system object, or updates the system object, if it exists (replaces the entire object). + +a|/openidm/system/*_system-name_*/*_system-object_*/*_id_* +a|PATCH +a|Updates the specified fields of a system object + +a|/openidm/system/*_system-name_*/*_system-object_*/*_id_* +a|DELETE +a|Deletes a system object + |=== [NOTE] @@ -1118,9 +1236,58 @@ $ curl \ Workflow objects are exposed under the `/openidm/workflow` context. OpenIDM provides access to the workflow module over REST, as listed in the following table. -[cols="50%,10%,40%"] +[cols="50%,10%,40%",stripes=even] |=== -|URI |HTTP Operation |Description +|URI |HTTP Operation |Description + +a|/openidm/workflow/processdefinition?_queryId=*__id__* +a|GET +a|Lists workflow definitions based on filtering criteria + +a|/openidm/workflow/processdefinition/*__id__* +a|GET +a|Returns detailed information about the specified process definition + +a|/openidm/workflow/processinstance?_queryId=query-all-ids +a|GET +a|Lists the available running workflows, by their ID + +a|/openidm/workflow/processinstance/*__id__* +a|GET +a|Provides detailed information of a running process instance + +a|/openidm/workflow/processinstance/history?_queryId=query-all-ids +a|GET +a|Lists running and completed workflows, by their ID + +a|/openidm/workflow/processdefinition/*__id__*/taskdefinition +a|GET +a|Returns detailed information about the task definition, when you include an *__id__* or a query for all IDs, `?_queryId=query-all-ids` + +a|/openidm/workflow/taskinstance?_queryId=query-all-ids +a|GET +a|Lists all active tasks + +a|/openidm/workflow/taskinstance?_queryId=filteredQuery&filter +a|GET +a|Lists the tasks according to the specified filter + +a|/openidm/workflow/processinstance?_action=create +a|POST +a|Start a new workflow. Parameters are included in the request body. + +a|/openidm/workflow/taskinstance/*__id__* +a|PUT +a|Update task data + +a|/openidm/workflow/processinstance/*__id__* +a|DELETE +a|Stops a process instance + +a|/openidm/workflow/taskinstance/*__id__*?_action=claim +a|POST +a|Claim or complete a task. Parameters are included in the request body. Specifically for user tasks, a user can claim a specific task, which will then be assigned to that user. + |=== The following examples list the defined workflows. For a workflow to appear in this list, the corresponding workflow definition must be in the `openidm/workflow` directory. @@ -1173,9 +1340,26 @@ OpenIDM provides a task scanning mechanism that enables you to perform a batch s OpenIDM provides REST access to the task scanner, as listed in the following table. -[cols="50%,10%,40%"] +[cols="50%,10%,40%",stripes=even] |=== -|URI |HTTP Operation |Description +|URI |HTTP Operation |Description + +a|/openidm/taskscanner +a|GET +a|Lists the all scanning tasks, past and present. + +a|/openidm/taskscanner/*_id_* +a|GET +a|Lists details of the given task. + +a|/openidm/taskscanner?_action=execute&name=*_name_* +a|POST +a|Triggers the specified task scan run. + +a|/openidm/taskscanner/*_id_*?_action=cancel +a|POST +a|Cancels the specified task scan run. + |=== @@ -1184,20 +1368,113 @@ OpenIDM provides REST access to the task scanner, as listed in the following tab You can interact with the audit logs over REST, as shown in the following table. Queries on the audit endpoint must use `queryFilter` syntax. Predefined queries (invoked with the `_queryId` parameter) are not supported. -[cols="50%,10%,40%"] -|=== -|URI |HTTP Operation |Description +[cols="50%,10%,40%",stripes=even] |=== +|URI |HTTP Operation |Description + +a|/openidm/audit/recon?_queryFilter=true +a|GET +a|Displays the reconciliation audit log + +a|/openidm/audit/recon/*_id_* +a|GET +a|Reads a specific reconciliation audit log entry + +a|/openidm/audit/recon/*_id_* +a|PUT +a|Creates a reconciliation audit log entry + +a|/openidm/audit/recon?_queryFilter=/reconId+eq+"*_reconId_*" +a|GET +a|Queries the audit log for a particular reconciliation operation + +a|/openidm/audit/recon?_queryFilter=/reconId+eq+"*_reconId_*"+and+situation+eq+"*_situation_*" +a|GET +a|Queries the reconciliation audit log for a specific reconciliation situation + +a|/openidm/audit/sync?_queryFilter=true +a|GET +a|Displays the synchronization audit log + +a|/openidm/audit/sync/*_id_* +a|GET +a|Reads a specific synchronization audit log entry + +a|/openidm/audit/sync/*_id_* +a|PUT +a|Creates a synchronization audit log entry +a|/openidm/audit/activity?_queryFilter=true +a|GET +a|Displays the activity log + +a|/openidm/audit/activity/*_id_* +a|GET +a|Returns activity information for a specific action + +a|/openidm/audit/activity/*_id_* +a|PUT +a|Creates an activity audit log entry + +a|/openidm/audit/activity?_queryFilter=transactionId=*_id_* +a|GET +a|Queries the activity log for all actions resulting from a specific transaction + +a|/openidm/audit/access?_queryFilter=true +a|GET +a|Displays the full list of auditable actions. + +a|/openidm/audit/access/*_id_* +a|GET +a|Displays information on the specific audit item + +a|/openidm/audit/access/*_id_* +a|PUT +a|Creates an access audit log entry + +a|/openidm/audit/authentication?_queryFilter=true +a|GET +a|Displays a complete list of authentication attempts, successful and unsuccessful + +a|/openidm/audit/authentication?_queryFilter=/principal+eq+"*__principal__*" +a|GET +a|Displays the authentication attempts by a specified user + +a|/openidm/audit?_action=availableHandlers +a|POST +a|Returns a list of audit event handlers + +a|/openidm/audit/config?_queryFilter=true +a|GET +a|Lists changes made to the configuration + +|=== [#recon-over-REST] ==== Managing Reconciliation Operations Over REST You can interact with the reconciliation engine over REST, as shown in the following table. -[cols="50%,10%,40%"] +[cols="50%,10%,40%",stripes=even] |=== -|URI |HTTP Operation |Description +|URI |HTTP Operation |Description + +a|/openidm/recon +a|GET +a|Lists all completed reconciliation runs + +a|/openidm/recon?_action=recon&mapping=*__mapping-name__* +a|POST +a|Launches a reconciliation run with the specified mapping + +a|/openidm/recon/*_id_*?_action=cancel +a|POST +a|Cancels the specified reconciliation run + +a|/openidm/system/*_datastore_*/account?_action=liveSync +a|POST +a|Calls a LiveSync operation. + |=== The following example runs a reconciliation action, with the mapping `systemHrdb_managedUser`, defined in the `sync.json` file. @@ -1216,9 +1493,29 @@ $ curl \ You can interact with the security service over REST, as shown in the following table: -[cols="50%,10%,40%"] +[cols="50%,10%,40%",stripes=even] |=== -|URI |HTTP Operation |Description +|URI |HTTP Operation |Description +a|/openidm/security/keystore +a|GET +a|Lists the keys and certificate in the keystore + +a|/openidm/security/keystore/privatekey/*_alias_* +a|PUT +a|Imports a signed certificate into the keystore + +a|/openidm/security/keystore?_action=generateCert +a|POST +a|Generates a self-signed certificate and imports it into the keystore + +a|/openidm/security/keystore?_action=generateCSR +a|POST +a|Generates a certificate signing request, for submission to a certificate authority + +a|/openidm/security/truststore +a|GET +a|Lists the public keys and certificate in the truststore + |=== For sample REST commands, see xref:chap-security.adoc#security-management-service["Accessing the Security Management Service"]. @@ -1228,9 +1525,30 @@ For sample REST commands, see xref:chap-security.adoc#security-management-servic You can interact with the repository engine over REST, as shown in the following table. -[cols="50%,10%,40%"] +[cols="50%,10%,40%",stripes=even] |=== -|URI |HTTP Operation |Description +|URI |HTTP Operation |Description + +a|/openidm/repo/synchronisation/deadLetterQueue/*_resource_*?_queryId=query-all-ids +a|GET +a|Lists any failed synchronisation records for that resource, that have been placed in the dead letter queue. + +a|/openidm/repo/link?_queryId=query-all-ids +a|GET +a|Lists entries in the links table + +a|/openidm/repo/internal/user?_queryId=query-all-ids +a|GET +a|Lists the internal users + +a|/openidm/repo/internal/user/*_username_* +a|PUT +a|Enables you to change the username or password of an internal user + +a|/openidm/repo?_action=updateDbCredentials +a|POST +a|Enables you to change the database username and password, in the case of an OrientDB repository + |=== For examples of queries on the `repo/` endpoint, see xref:chap-repo.adoc#repo-over-rest["Interacting With the Repository Over REST"]. @@ -1240,14 +1558,79 @@ For examples of queries on the `repo/` endpoint, see xref:chap-repo.adoc#repo-ov You can interact with the updates engine over REST, as shown in the following table. -[cols="50%,10%,40%"] +[cols="50%,10%,40%",stripes=even] |=== -|URI |HTTP Operation |Description +|URI |HTTP Operation |Description + +a|/openidm/maintenance/update?_action=available +a|POST +a|Lists update archives in the `*_project-dir_*/openidm/bin/update/` directory + +a|/openidm/maintenance/update?_action=preview&archive=*__patch__*.zip +a|POST +a|Lists file states of the current installation, relative to the *_patch_*.zip archive, using checksums + +a|openidm/maintenance/update?_action=listMigrations&archive=*__patch__*.zip +a|POST +a|Gets a list of repository migrations for a given update type + +a|/openidm/maintenance/update?_action=getLicense&archive=*__patch__*.zip +a|POST +a|Retrieves the license from the *_patch_*.zip archive + +a|/openidm/maintenance/update?_action=listRepoUpdates&archive=*__patch__*.zip +a|POST +a|Get a list of repository update archives; use the _path_ in the output for the endpoint with repo files + +a|/openidm/maintenance/update/archives/*_patch_*.zip/*_path_*?_field=contents&_mimeType=text/plain +a|POST +a|Get files for the specific repository update, defined in the *_path_*. + +a|/openidm/maintenance?_action=enable +a|POST +a|Activates maintenance mode; you should first run the commands in xref:chap-scheduler-conf.adoc#schedules-pausing-current-tasks["Pausing Scheduled Tasks"]. + +a|/openidm/maintenance?_action=disable +a|POST +a|Disables maintenance mode; you can then re-enable scheduled tasks as noted in xref:chap-scheduler-conf.adoc#schedules-resuming-current-tasks["Resuming All Running Scheduled Tasks"]. + +a|/openidm/maintenance?_action=status +a|POST +a|Returns current maintenance mode information + +a|/openidm/maintenance/update?_action=update&archive=*__patch__*.zip +a|POST +a|Start an update with the *_patch_*.zip archive + +a|/openidm/maintenance/update?_action=installed +a|POST +a|Retrieve a summary of all installed updates + +a|/openidm/maintenance/update?_action=restart +a|POST +a|Restart OpenIDM + +a|/openidm/maintenance/update?_action=lastUpdateId +a|POST +a|Returns the `_id` value of the last successful update + +a|/openidm/maintenance/update?_action=markComplete&updateId=*__id_string__* +a|POST +a|For an update with `PENDING_REPO_UPDATES` for one or more repositories, mark as complete. Replace *_id_string_* with the value of `_id` for the update archive. + +a|/openidm/maintenance/update/log/_**_id**_ +a|GET +a|Get information about an update, by *__id_* (status, dates, file action taken) + +a|/openidm/maintenance/update/log/?_queryFilter=true +a|GET +a|Get information about all past updates, by repository + |=== [#update-file-during] .Update Status Message -[cols="40%,60%"] +[cols="40%,60%",stripes=even] |=== |Status |Description @@ -1271,9 +1654,55 @@ a|Update failed, not yet reverted The OpenIDM REST API returns the standard HTTP response codes, as described in the following table. -[cols="40%,60%"] +[cols="40%,60%",stripes=even] |=== -|HTTP Status |Description +|HTTP Status |Description + +a|200 OK +a|The request was successfully completed. If this request created a new resource that is addressable with a URI, and a response body is returned containing a representation of the new resource, a 200 status will be returned with a Location header containing the canonical URI for the newly created resource. + +a|201 Created +a|A request that created a new resource was completed. A representation of the new resource is returned. A Location header containing the canonical URI for the newly created resource should also be returned. + +a|202 Accepted +a|The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon. May happen with asynchronous communication. + +a|204 No Content +a|The server fulfilled the request, but does not need to return a response message body. + +a|400 Bad Request +a|The request could not be processed because it contains missing or invalid information. + +a|401 Unauthorized +a|The authentication credentials included with this request are missing or invalid. + +a|403 Forbidden +a|The server recognized your credentials, but you do not possess authorization to perform this request. + +a|404 Not Found +a|The request specified a URI of a resource that does not exist. + +a|405 Method Not Allowed +a|The HTTP verb specified in the request (DELETE, GET, POST, PUT) is not supported for this request URI. + +a|406 Not Acceptable +a|The resource identified by this request is not capable of generating a representation corresponding to one of the media types in the Accept header of the request. + +a|409 Conflict +a|A creation or update request could not be completed, because it would cause a conflict in the current state of the resources supported by the server (for example, an attempt to create a new resource with a unique identifier already assigned to some existing resource). + +a|412 Precondition Failed +a|The precondition given in the request header is false. + +a|500 Internal Server Error +a|The server encountered an unexpected condition which prevented it from fulfilling the request. + +a|501 Not Implemented +a|The server does not (currently) support the functionality required to fulfill the request. + +a|503 Service Unavailable +a|The server is currently unable to handle the request due to temporary overloading or maintenance of the server. + |=== diff --git a/openidm/modules/integrators-guide/pages/appendix-router.adoc b/openidm/modules/integrators-guide/pages/appendix-router.adoc index 886bece5b2..d22ad4dad5 100644 --- a/openidm/modules/integrators-guide/pages/appendix-router.adoc +++ b/openidm/modules/integrators-guide/pages/appendix-router.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -103,7 +103,7 @@ Pattern matching can minimize overhead in the router service. For example, the d Based on the following code snippet, the router service would trigger the `policyFilter.js` script for `CREATE` and `UPDATE` calls to managed, system, and internal repository objects. -[source, javascript] +[source, json] ---- { "pattern" : "^(managed|system|repo/internal)($|(/.+))", @@ -133,7 +133,7 @@ client <- filter 1 onResponse <- filter 2 onResponse <- resource ---- The following sample `router.json` file shows the order in which the scripts would be executed: -[source, javascript] +[source, json] ---- { "filters" : [ @@ -284,7 +284,7 @@ A detailed description of the exception, in structured JSON format, suitable for The following example executes a script after a managed user object is created or updated. -[source, javascript] +[source, json] ---- { "filters": [ diff --git a/openidm/modules/integrators-guide/pages/appendix-scripting.adoc b/openidm/modules/integrators-guide/pages/appendix-scripting.adoc index cc45cbc75c..3ffa679f9a 100644 --- a/openidm/modules/integrators-guide/pages/appendix-scripting.adoc +++ b/openidm/modules/integrators-guide/pages/appendix-scripting.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -444,7 +444,7 @@ The list of entries retrieved by the query. The result includes the revision (`" The following example shows the result of a custom query that requests the ID, user name, and email address of managed users in the repository. For an OrientDB repository, the query would be something like `select _openidm_id, userName, email from managed_user,`. + -[source, javascript] +[source, json] ---- { "conversion-time-ms": 0, diff --git a/openidm/modules/integrators-guide/pages/chap-advanced.adoc b/openidm/modules/integrators-guide/pages/chap-advanced.adoc index 293a6c2f5e..e209bb1103 100644 --- a/openidm/modules/integrators-guide/pages/chap-advanced.adoc +++ b/openidm/modules/integrators-guide/pages/chap-advanced.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -54,7 +54,7 @@ The customizable properties of the default startup configuration file are as fol * `"config.properties"` - takes either a path to a configuration file (relative to the project location) or a list of configuration properties and their values. The list must be in the format `"string":"string"`, for example: + -[source, javascript] +[source, json] ---- "config.properties" : { @@ -65,7 +65,7 @@ The customizable properties of the default startup configuration file are as fol * `"system.properties"` - takes either a path to a `system.properties` file (relative to the project location) or a list of system properties and their values. The list must be in the format `"string":"string"`, for example: + -[source, javascript] +[source, json] ---- "system.properties" : { @@ -76,7 +76,7 @@ The customizable properties of the default startup configuration file are as fol * `"boot.properties"` - takes either a path to a `boot.properties` file (relative to the project location) or a list of boot properties and their values.The list must be in the format `"string":object`, for example: + -[source, javascript] +[source, json] ---- "boot.properties" : { diff --git a/openidm/modules/integrators-guide/pages/chap-auditing.adoc b/openidm/modules/integrators-guide/pages/chap-auditing.adoc index 674e011e58..eb7fc713a7 100644 --- a/openidm/modules/integrators-guide/pages/chap-auditing.adoc +++ b/openidm/modules/integrators-guide/pages/chap-auditing.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -46,7 +46,7 @@ The following list includes major options that you can configure for the audit s * OpenIDM includes several configurable default __audit event handlers__, as described in xref:#configuring-topic-handlers["Configuring Audit Event Handlers"]. -* You can allow a common `transactionId` for audit data from all ForgeRock products. To do so, edit the `system.properties` file in your `project-dir/conf` directory and set: +* You can allow a common `transactionId` for audit data from all Open Identity Platform products. To do so, edit the `system.properties` file in your `project-dir/conf` directory and set: + [source, console] @@ -60,7 +60,7 @@ You can select one audit event handler to manage queries on the audit logs. The To specify which audit event handler should be used for queries, set the `handlerForQueries` property in the `audit.json` file, as follows: -[source, javascript] +[source, json] ---- { "auditServiceConfig" : { @@ -104,7 +104,7 @@ The following section illustrate how you can configure these properties for stan The CSV audit event handler logs events to a comma-separated value (CSV) file. The following code is an excerpt of the `audit.json` file, which depicts a sample CSV audit event handler configuration: -[source, javascript] +[source, json] ---- "eventHandlers" : [ { @@ -234,7 +234,7 @@ Tamper protection for OpenIDM audit files can ensure the integrity of OpenIDM au Once configured, the relevant code snippet in your `project-dir/conf/audit.conf` file should appear as follows: -[source, javascript] +[source, json] ---- { "class" : "org.forgerock.audit.handlers.csv.CsvAuditEventHandler", @@ -314,7 +314,7 @@ The router audit event handler logs events to any external or custom endpoint, s A sample configuration for a `"router"` event handler is provided in the `audit.json` file in the `openidm/samples/audit-sample/conf` directory, and described in xref:samples-guide:chap-audit-sample.adoc#audit-config-files["Audit Sample Configuration Files"] in the __Samples Guide__. This sample directs log output to a JDBC repository. The audit configuration file (`conf/audit.json`) for the sample shows the following event handler configuration: -[source, javascript] +[source, json] ---- { "class": "org.forgerock.openidm.audit.impl.RouterAuditEventHandler", @@ -327,7 +327,7 @@ A sample configuration for a `"router"` event handler is provided in the `audit. ---- The `"resourcePath"` property in the configuration indicates that logs should be directed to the `system/auditdb` endpoint. This endpoint, and the JDBC connection properties, are defined in the connector configuration file (`conf/provisioner.openicf-scriptedsql.json`), as follows: -[source, javascript] +[source, json] ---- { "name" : "auditdb", @@ -391,7 +391,7 @@ You can use the repository audit event handler to generate reports that combine You can find mappings for each of these JDBC tables in your `repo.jdbc.json` file. The following excerpt illustrates the mappings for the `auditauthentication` table: -[source, javascript] +[source, json] ---- "audit/authentication" : { "table" : "auditauthentication", @@ -411,7 +411,7 @@ You can find mappings for each of these JDBC tables in your `repo.jdbc.json` fil ---- Now return to the `audit.json` file. Examine the following sample audit repository log configuration: -[source, javascript] +[source, json] ---- { "class": "org.forgerock.openidm.audit.impl.RepositoryAuditEventHandler", @@ -426,7 +426,7 @@ Now return to the `audit.json` file. Examine the following sample audit reposito [#audit-jms-handler] ==== JMS Audit Event Handler -Starting with OpenIDM 4.5.0, you can configure a Java Message Service (JMS) Audit Event Handler. The Java Message Service (JMS) is a Java API for sending messages between clients. A JMS audit event handler can record messages between a JMS message broker and one or more clients. The default ForgeRock JMS message broker is link:http://activemq.apache.org/[Apache ActiveMQ, window=\_blank]. For a demonstration, see xref:samples-guide:chap-audit-sample.adoc#jms-audit-sample["Show Audit Events Published on a JMS Topic"] in the __Samples Guide__. +Starting with OpenIDM 4.5.0, you can configure a Java Message Service (JMS) Audit Event Handler. The Java Message Service (JMS) is a Java API for sending messages between clients. A JMS audit event handler can record messages between a JMS message broker and one or more clients. The default Open Identity Platform JMS message broker is link:http://activemq.apache.org/[Apache ActiveMQ, window=\_blank]. For a demonstration, see xref:samples-guide:chap-audit-sample.adoc#jms-audit-sample["Show Audit Events Published on a JMS Topic"] in the __Samples Guide__. Alternatively, you can use the link:https://tap.tibco.com/storefront/trialware/tibco-enterprise-message-service/prod15032.html[TIBCO Enterprise Message Service, window=\_blank], as described in this chapter. @@ -438,15 +438,15 @@ As with other audit event handlers, you can configure it directly through the `c ==== The JMS audit event handler does not support queries. If you enable JMS, you must also enable a second handler that supports queries. You'll see that handler in the `audit.json` file with the `handlerForQueries` property, or in the Admin UI with the `Use For Queries` option. ==== -The ForgeRock JMS audit event handler supports JMS communication, based on the following components: +The Open Identity Platform JMS audit event handler supports JMS communication, based on the following components: * A JMS message broker, which provides clients with connectivity, along with message storage and message delivery functionality. * JMS messages, which follow a specific format described in xref:#audit-jms-message["JMS Message Format"]. -* Destinations, maintained by the message broker, such as the ForgeRock audit service. They may be batched in queues, and can be acknowledged in one of three modes: automatically, by the client, or with direction to accept duplication. The acknowledgement mode is based on the JMS session. +* Destinations, maintained by the message broker, such as the Open Identity Platform audit service. They may be batched in queues, and can be acknowledged in one of three modes: automatically, by the client, or with direction to accept duplication. The acknowledgement mode is based on the JMS session. -* Topics: JMS topics differ from ForgeRock audit event topics. The ForgeRock implementation of JMS topics uses the link:http://docs.oracle.com/javaee/6/tutorial/doc/bncdx.html#bnced[publish/subscribe messaging domain, window=\_blank], which can direct messages to the JMS audit event handler. In contrast, ForgeRock audit event topics specify categories of events, including access, activity, authentication, configuration, reconciliation, and synchronization. +* Topics: JMS topics differ from Open Identity Platform audit event topics. The Open Identity Platform implementation of JMS topics uses the link:http://docs.oracle.com/javaee/6/tutorial/doc/bncdx.html#bnced[publish/subscribe messaging domain, window=\_blank], which can direct messages to the JMS audit event handler. In contrast, Open Identity Platform audit event topics specify categories of events, including access, activity, authentication, configuration, reconciliation, and synchronization. * JMS clients include both the producer and consumer of a JMS message. @@ -521,7 +521,7 @@ To configure JMS at the Admin UI, select Configure > System Preferences > Audit. You can configure JMS directly in the `conf/audit.json` file, or indirectly through the Admin UI. The following code is an excerpt of the audit.json file, which depicts a sample JMS audit event handler configuration: -[source, javascript] +[source, json] ---- { "class" : "org.forgerock.audit.handlers.jms.JmsAuditEventHandler", @@ -711,7 +711,7 @@ You can now start the ActiveMQ event broker, and start OpenIDM, as described in The following JMS message reflects the authentication of the `openidm-admin` user, logging into the Admin UI from a remote location, IP address 172.16.209.49. -[source, javascript] +[source, json] ---- { "event": { @@ -794,7 +794,7 @@ $ java \ ==== You also need to configure your project's `audit.conf` configuration file. The options are similar to those listed earlier in xref:#audit-jms-conf["JMS Configuration File"], except for the following `jndi` code block: -[source, javascript] +[source, json] ---- "jndi": { "contextProperties": { @@ -807,7 +807,7 @@ You also need to configure your project's `audit.conf` configuration file. The o ---- If your TIBCO server is on a remote system, substitute appropriately for `localhost`. If you're configuring a secure TIBCO installation, you'll want to configure a different code block: -[source, javascript] +[source, json] ---- "jndi": { "contextProperties": { @@ -931,7 +931,7 @@ The `filter` `actions` list enables you to specify the actions that are logged, The following configuration specifies certain action operations: (create, update, delete, patch, and action). The Audit Service may check filter actions, scripts, and more, when included in the `audit.json` file. -[source] +[source, json] ---- "eventTopics" : { ... @@ -1029,7 +1029,7 @@ a|No actions can be specified for the access log. You can add a list of `filter` `fields` to the audit configuration, that enables you to filter log entries by specific fields. For example, you might want to restrict the reconciliation or audit log so that only summary information is logged for each reconciliation operation. The following addition to the `audit.json` file specifies that entries are logged in the reconciliation log only if their `entryType` is `start` or `summary`. -[source, javascript] +[source, json] ---- "eventTopics" : { ... @@ -1065,7 +1065,7 @@ To use nested properties, specify the field name as a JSON pointer. For example, Apart from the audit filtering options described in the previous sections, you can use a JavaScript or Groovy script to specify what is logged in your audit logs. Audit filter scripts are referenced in the audit configuration file (`conf/audit.json`), and can be configured per event type. The following sample configuration references a script named `auditfilter.js`, which is used to limit what is logged in the reconciliation audit log: -[source, javascript] +[source, json] ---- { "eventTopics" : { @@ -1098,7 +1098,7 @@ The script must return `true` to include the log entry; `false` to exclude it. You can add a `filter` `triggers` list to the audit configuration, that specifies the actions that will be logged for a specific trigger. For example, the following addition to the `audit.json` file specifies that only `create` and `update` actions are logged for in the activity log, for an activity that was triggered by a `recon`. -[source, javascript] +[source, json] ---- "eventTopics" : { "activity" : { @@ -1150,7 +1150,7 @@ Also in the activity log, you can include a `passwordFields` parameter to specif By default, the `audit.json` file for OpenIDM includes the following code snippet for `filterPolicies`: -[source, javascript] +[source, json] ---- "filterPolicies" : { "value" : { @@ -1175,7 +1175,7 @@ The `includeIf` directive is available for custom audit event handlers, for item The OpenIDM Audit service includes an __exception formatter__, configured in the following snippet of the `audit.json` file: -[source, javascript] +[source, json] ---- "exceptionFormatter" : { "type" : "text/javascript", @@ -1208,7 +1208,7 @@ a| |=== The following sample code illustrates where you would configure these properties in the `audit.json` file. -[source, javascript] +[source, json] ---- ... "eventHandlers" : [ @@ -1240,7 +1240,7 @@ To purge reconciliation audit logs on a regular basis, you must set up a schedul The sample purge schedule file is as follows: -[source, console] +[source, json] ---- { "enabled" : false, @@ -1281,7 +1281,7 @@ Strings must contain the mapping(s) name and can use "%" as a wild card value th Objects provide the ability to specify mapping(s) to include/exclude and must be of the form: + -[source, console] +[source, json] ---- { "include" : "mapping1", @@ -1366,7 +1366,7 @@ $ curl \ ---- The following code extract shows the reconciliation audit log after the first reconciliation operation in Sample 1. -[source, javascript] +[source, json] ---- { "result" : [ { @@ -1529,7 +1529,7 @@ $ curl \ ---- The following sample output shows the results of a read operation on a specific reconciliation audit entry. The entry shows the creation of bjensen's account in the managed user repository, as the result of a reconciliation operation. -[source, javascript] +[source, json] ---- { "_id" : "414a4921-5d9d-4398-bf86-7d5312a9f5d1-146", @@ -1677,9 +1677,9 @@ $ curl \ ---- The following extract of the activity log shows one entry that created user bjensen. -[source, javascript] +[source, json] ---- -}, { +{ "_id" : "414a4921-5d9d-4398-bf86-7d5312a9f5d1-145", "_rev" : "1", "transactionId" : "414a4921-5d9d-4398-bf86-7d5312a9f5d1-135", @@ -1730,7 +1730,7 @@ $ curl \ ---- The following sample output shows the result of a query that created users scarter and bjensen. -[source, javascript] +[source, json] ---- { "result" : [ { diff --git a/openidm/modules/integrators-guide/pages/chap-auth.adoc b/openidm/modules/integrators-guide/pages/chap-auth.adoc index 31281bfad8..cb62399265 100644 --- a/openidm/modules/integrators-guide/pages/chap-auth.adoc +++ b/openidm/modules/integrators-guide/pages/chap-auth.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -192,7 +192,7 @@ OpenIDM provides RESTful access to managed users, at the context path `/openidm/ By default, the attribute names that are used to authenticate managed and internal users are `username` and `password`, respectively. However, you can explicitly define the properties that constitute usernames, passwords or roles with the `propertyMapping` object in the `conf/authentication.json` file. The following excerpt of the `authentication.json` file shows the default property mapping object: -[source, javascript] +[source, json] ---- ... "propertyMapping" : { @@ -229,7 +229,7 @@ This query uses the `username` attribute for login, for managed users. For examp -- The query that is used for a particular resource is specified by the `queryId` property in the `authentication.json` file. The following sample excerpt of that file shows that the `credential-query` is used when validating managed user credentials. -[source, javascript] +[source, json] ---- { "queryId" : "credential-query", @@ -255,7 +255,7 @@ image::ROOT:admin-ui-authentication.png[] At this time, OpenIDM includes one supported session module. The JSON Web Token session module configuration specifies keystore information, and details about the session lifespan. The default `JWT_SESSION` configuration is as follows: -[source, javascript] +[source, json] ---- "sessionModule" : { "name" : "JWT_SESSION", @@ -277,13 +277,13 @@ At this time, OpenIDM includes one supported session module. The JSON Web Token ==== If you're working with the link:../integrators-guide/index.html#openam-session-module[OPENAM_SESSION] module, change the token lifetime properties as shown here, to match the session token lifetime associated with OpenAM. -[source, javascript] +[source, json] ---- -"maxTokenLifeSeconds" : "5", + "maxTokenLifeSeconds" : "5", "tokenIdleTimeSeconds" : "5" ---- ==== -For more information about the `JWT_SESSION` module, see the following Javadoc page: link:http://commons.forgerock.org/forgerock-auth-filters/forgerock-authn-filter/forgerock-jaspi-modules/forgerock-jaspi-jwt-session-module/apidocs/org/forgerock/jaspi/modules/session/jwt/JwtSessionModule.html[Class JwtSessionModule, window=\_blank]. +For more information about the `JWT_SESSION` module, see the following Javadoc page: link:https://doc.openidentityplatform.org/commons/apidocs/org/forgerock/jaspi/modules/session/jwt/JwtSessionModule.html[Class JwtSessionModule, window=\_blank]. [#supported-auth-modules] @@ -329,7 +329,7 @@ Authenticating with the `STATIC_USER` module avoids the performance cost of read A sample `STATIC_USER` authentication configuration follows: + -[source] +[source, json] ---- { "name" : "STATIC_USER", @@ -351,7 +351,7 @@ TRUSTED_ATTRIBUTE:: The `TRUSTED_ATTRIBUTE` authentication module allows you to configure OpenIDM to trust the `HttpServletRequest` attribute of your choice. You can configure it by adding the `TRUSTED_ATTRIBUTE` module to your `authentication.json` file, as shown in the following code block: + -[source, javascript] +[source, json] ---- ... { @@ -383,7 +383,7 @@ MANAGED_USER:: `MANAGED_USER` authentication queries the repository, specifically the `managed/user` objects, and allows authentication if the credentials match. The default configuration uses the `username` and `password` of the managed user to authenticate, as shown in the following sample configuration: + -[source, javascript] +[source, json] ---- { "name" : "MANAGED_USER", @@ -405,7 +405,7 @@ INTERNAL_USER:: `INTERNAL_USER` authentication queries the repository, specifically the `repo/internal/user` objects, and allows authentication if the credentials match. The default configuration uses the `username` and `password` of the internal user to authenticate, as shown in the following sample configuration: + -[source, javascript] +[source, json] ---- { "name" : "INTERNAL_USER", @@ -430,7 +430,7 @@ The client certificate module, `CLIENT_CERT`, provides authentication by validat A sample `CLIENT_CERT` authentication configuration follows: + -[source] +[source, json] ---- { "name" : "CLIENT_CERT", @@ -458,7 +458,7 @@ PASSTHROUGH:: [#openam-session-module] OPENAM_SESSION:: -The `OPENAM_SESSION` module enables you to protect an OpenIDM deployment with ForgeRock's link:http://docs.forgerock.org/en/index.html?product=openam[OpenAM Access Management, window=\_blank] product. For an example of how you might use the `OPENAM_SESSION` module, see xref:samples-guide:chap-fullstack-sample.adoc#chap-fullstack-sample["Full Stack Sample - Using OpenIDM in the ForgeRock Identity Platform"] in the __Samples Guide__. +The `OPENAM_SESSION` module enables you to protect an OpenIDM deployment with Open Identity Platform's link:http://github.com/OpenIdentityPlatform/OpenAM[OpenAM, window=\_blank] product. For an example of how you might use the `OPENAM_SESSION` module, see xref:samples-guide:chap-fullstack-sample.adoc#chap-fullstack-sample["Full Stack Sample - Using OpenIDM in the Open Identity Platform"] in the __Samples Guide__. + For detailed options, see xref:appendix-auth-modules.adoc#openam-module-details["OPENAM_SESSION Module Configuration Options"]. @@ -482,7 +482,6 @@ The IWA module enables users to authenticate by using Integrated Windows Authent -- - [#passthrough-auth] ==== Configuring Pass-Through Authentication @@ -490,7 +489,7 @@ OpenIDM 4.5 supports a pass-through authentication mechanism. With pass-through The following excerpt of an `authentication.json` shows a pass-through authentication configuration for an LDAP system. -[source, javascript] +[source, json] ---- "authModules" : [ { @@ -678,7 +677,7 @@ This section assumes that the connection from OpenIDM to the Active Directory Se Add the IWA authentication module towards the end of your `conf/authentication.json` file. For example: -[source, javascript] +[source, json] ---- "authModules" : [ ... @@ -831,7 +830,7 @@ $ keytool \ . Open the `authentication.json` file in the `project-dir/conf` directory. Scroll to the code block with `CLIENT_CERT` and include the information from when you generated the self-signed certificate: + -[source, javascript] +[source, json] ---- ... { @@ -933,7 +932,7 @@ The roles calculated in sequence are cumulative. For users who have authenticated with mutual SSL authentication, the module is `CLIENT_CERT` and the default role for such users is `openidm-cert`. -[source, javascript] +[source, json] ---- { "name" : "CLIENT_CERT", "properties" : { @@ -1002,8 +1001,8 @@ This file provides the functions that enforce access rules. For example, the fol ---- ... function isAllowedToStartProcess() { -var processDefinitionId = request.content._processDefinitionId; -return isProcessOnUsersList(processDefinitionId); + var processDefinitionId = request.content._processDefinitionId; + return isProcessOnUsersList(processDefinitionId); } ... ---- diff --git a/openidm/modules/integrators-guide/pages/chap-cluster.adoc b/openidm/modules/integrators-guide/pages/chap-cluster.adoc index e0a5c372cc..d4aa088613 100644 --- a/openidm/modules/integrators-guide/pages/chap-cluster.adoc +++ b/openidm/modules/integrators-guide/pages/chap-cluster.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -184,13 +184,13 @@ openidm.config.crypto.alias=new-sym-key ---- and in the `conf/managed.json` file: -[source, javascript] +[source, json] ---- { "name" : "securityAnswer", "encryption" : { "key" : "new-sym-key" - } + }, "scope" : "private" }, { @@ -217,7 +217,7 @@ If you make changes to the keystore and truststore files in clustered environmen The cluster configuration file is `/path/to/openidm/conf/cluster.json`. The default version of this file accommodates a cluster, as shown with the value of the `enabled` property: -[source, javascript] +[source, json] ---- { "instanceId" : "&{openidm.node.id}", diff --git a/openidm/modules/integrators-guide/pages/chap-configuration.adoc b/openidm/modules/integrators-guide/pages/chap-configuration.adoc index 37efa4767b..0be595acc3 100644 --- a/openidm/modules/integrators-guide/pages/chap-configuration.adoc +++ b/openidm/modules/integrators-guide/pages/chap-configuration.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -162,7 +162,7 @@ If you've configured OpenIDM behind a proxy server, include JVM properties from [#jvm-proxy-properties] .JVM Proxy Properties -[cols="20%,40%,40%"] +[cols="26%,37%,37%"] |=== |JVM Property |Example Values |Description diff --git a/openidm/modules/integrators-guide/pages/chap-data.adoc b/openidm/modules/integrators-guide/pages/chap-data.adoc index 0b6ebde6a1..ebdbb273d9 100644 --- a/openidm/modules/integrators-guide/pages/chap-data.adoc +++ b/openidm/modules/integrators-guide/pages/chap-data.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -65,7 +65,7 @@ The `create()`, `delete()`, and `query()` functions work the same way. [#data-rest] === Accessing Data Objects By Using the REST API -OpenIDM provides RESTful access to data objects via ForgeRock's Common REST API. To access objects over REST, you can use a browser-based REST client, such as the Simple REST Client for Chrome, or RESTClient for Firefox. Alternatively you can use the link:http://curl.haxx.se/[curl, window=\_top] command-line utility. +OpenIDM provides RESTful access to data objects via Open Identity Platform's Common REST API. To access objects over REST, you can use a browser-based REST client, such as the Simple REST Client for Chrome, or RESTClient for Firefox. Alternatively you can use the link:http://curl.haxx.se/[curl, window=\_top] command-line utility. For a comprehensive overview of the REST API, see xref:appendix-rest.adoc#appendix-rest["REST API Reference"]. @@ -109,7 +109,7 @@ Each of these mechanisms is discussed in the following sections. [#query-filters] ==== Common Filter Expressions -The ForgeRock REST API defines common filter expressions that enable you to form arbitrary queries using a number of supported filter operations. This query capability is the standard way to query data if no predefined query exists, and is supported for all managed and system objects. +The Open Identity Platform REST API defines common filter expressions that enable you to form arbitrary queries using a number of supported filter operations. This query capability is the standard way to query data if no predefined query exists, and is supported for all managed and system objects. Common filter expressions are useful in that they do not require knowledge of how the object is stored and do not require additions to the repository configuration. diff --git a/openidm/modules/integrators-guide/pages/chap-logs.adoc b/openidm/modules/integrators-guide/pages/chap-logs.adoc index 4353723c98..f8c177113d 100644 --- a/openidm/modules/integrators-guide/pages/chap-logs.adoc +++ b/openidm/modules/integrators-guide/pages/chap-logs.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -105,7 +105,7 @@ Just set `java.util.logging.ConsoleHandler.level = OFF`, and comment out other r [source, ini] ---- -# ConsoleHandler: A simple handler for writing formatted records to System.err + # ConsoleHandler: A simple handler for writing formatted records to System.err #handlers=java.util.logging.FileHandler, java.util.logging.ConsoleHandler handlers=java.util.logging.FileHandler ... diff --git a/openidm/modules/integrators-guide/pages/chap-overview.adoc b/openidm/modules/integrators-guide/pages/chap-overview.adoc index 2cb47ab315..c66e3747bd 100644 --- a/openidm/modules/integrators-guide/pages/chap-overview.adoc +++ b/openidm/modules/integrators-guide/pages/chap-overview.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -177,7 +177,7 @@ For more information, see xref:chap-synchronization.adoc#chap-synchronization["S [#commons-rest-commands] === Secure Commons REST Commands -Representational State Transfer (REST) is a software architecture style for exposing resources, using the technologies and protocols of the World Wide Web. For more information on the ForgeRock REST API, see xref:appendix-rest.adoc#appendix-rest["REST API Reference"]. +Representational State Transfer (REST) is a software architecture style for exposing resources, using the technologies and protocols of the World Wide Web. For more information on the Open Identity Platform REST API, see xref:appendix-rest.adoc#appendix-rest["REST API Reference"]. REST interfaces are commonly tested with a `curl` command. Many of these commands are used in this document. They work with the standard ports associated with Java EE communications, 8080 and 8443. diff --git a/openidm/modules/integrators-guide/pages/chap-passwords.adoc b/openidm/modules/integrators-guide/pages/chap-passwords.adoc index 500b639264..91edbba877 100644 --- a/openidm/modules/integrators-guide/pages/chap-passwords.adoc +++ b/openidm/modules/integrators-guide/pages/chap-passwords.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -86,7 +86,7 @@ You also need to modify the following configuration files: * Modify the `sync.json` file to include connections to the custom `onCreate-onUpdate-sync.js` script: + -[source, javascript] +[source, json] ---- "onCreate" : { "type" : "text/javascript", @@ -103,7 +103,7 @@ If you have existing `onCreate` and `onUpdate` code blocks, you may need to cons * Modify the `router.json` file to include code blocks for the `managed/user` object and associated policy. These policies apply to the arbitrary `ldapPassword` parameter which you will also add to the `managed.json` file: + -[source, javascript] +[source, json] ---- { "pattern" : "managed/user.*", @@ -137,7 +137,7 @@ If you have existing `onCreate` and `onUpdate` code blocks, you may need to cons * In the `policy.json` file, include the `pwpolicy.js` file from your project's `script/` subdirectory, as `additionalFiles`: + -[source, javascript] +[source, json] ---- "type" : "text/javascript", "file" : "policy.js", @@ -151,7 +151,7 @@ If you have existing `onCreate` and `onUpdate` code blocks, you may need to cons You may vary the value of `historySize`, depending on the number of recent passwords you want to record in the history for each user. A `historySize` of 2 means that users who change their passwords can't use their previous two passwords. + -[source, javascript] +[source, json] ---- "name" : "user", "onValidate" : { @@ -182,7 +182,7 @@ You may vary the value of `historySize`, depending on the number of recent passw ** In same file under `properties`, add the following code block for `ldapPassword` + -[source, javascript] +[source, json] ---- "ldapPassword" : { "title" : "Password", @@ -241,7 +241,7 @@ You may vary the value of `historySize`, depending on the number of recent passw ** Add the following `fieldHistory` code block, which maps field names to a list of historical values for the field. + -[source, javascript] +[source, json] ---- "fieldHistory" : { "title" : "Field History", @@ -268,7 +268,7 @@ To store multiple passwords, you must extend the managed user schema to include The following addition to a sample `managed.json` configuration shows an `ldapPassword` property that has been added to managed user objects. This property will be mapped to the password property on an LDAP system: -[source, javascript] +[source, json] ---- "ldapPassword" : { "title" : "Password", @@ -374,11 +374,6 @@ To be able to synchronize passwords, both password synchronization plugins requi The following sections describe how to use the password synchronization plugin for OpenDJ, and the corresponding plugin for Active Directory. -[NOTE] -==== -These plugins are available only with a subscription, from the ForgeRock link:https://backstage.forgerock.com/[BackStage, window=\_blank] site. -==== - [#pwd-sync-opendj] ==== Synchronizing Passwords With OpenDJ @@ -542,7 +537,7 @@ The following steps install the password synchronization plugin on an OpenDJ dir [#install-opendj-password-sync-plugin] ==== -. Download the OpenDJ password synchronization plugin from the ForgeRock link:https://backstage.forgerock.com/[BackStage, window=\_blank] site. You must use the plugin version that corresponds to your OpenDJ version. +. Download the OpenDJ password synchronization plugin from the link:https://repo1.maven.org/maven2/org/openidentityplatform/opendj/opendj-openidm-account-change-notification-handler[Maven Repository, window=\_blank]. You must use the plugin version that corresponds to your OpenDJ version. . Extract the contents of the `opendj-accountchange-handler-version.zip` file to the directory where OpenDJ is installed: + @@ -574,18 +569,16 @@ Stopping Server... . Configure the password synchronization plugin, if required. + +-- The password plugin configuration is specified in one of the following files: -+ * Plugin versions 1.0.3 and 1.1.1 - in `openidm-pwsync-plugin-config.ldif` * Plugin version 3.5.0 - in `openidm-accountchange-plugin-sample-config` -+ Depending on your plugin version, one of these configuration files should have been extracted to `path/to/opendj/config` when you extracted the plugin. -+ + Use a text editor to update the configuration, for example: -+ [source, console] ---- @@ -598,10 +591,8 @@ objectClass: ds-cfg-openidm-account-status-notification-handler cn: OpenIDM Notification Handler ... ---- -+ + You can configure the following elements of the plugin. Depending on your plugin version, the property names might differ. Applicable version numbers are provided in the following list: -+ --- `ds-cfg-enabled`:: Specifies whether the plugin is enabled. @@ -686,7 +677,6 @@ Default value: `openidm-admin` This property is commented out in version of 3.5.0 of the plugin configuration, and must be uncommented if you use HTTP or SSL authentication. + This property does not exist in version 1.0.3 of the plugin, as the plugin supports mutual SSL authentication only. - -- . When you have updated the plugin configuration to fit your deployment, add the configuration to OpenDJ's configuration: @@ -789,7 +779,7 @@ To support password synchronization with Active Directory, you must make the fol The following excerpt shows the required addition to the `managed.json` file: + -[source, javascript] +[source, json] ---- { "objects" : [ @@ -843,7 +833,7 @@ The following excerpt shows the required addition to the `managed.json` file: The excerpt shows the required addition to the `managed.json` file: + -[source, javascript] +[source, json] ---- { "objects" : [ @@ -868,14 +858,14 @@ The following steps install the password synchronization on an Active directory ==== -. Download the Active Directory password synchronization plugin from the ForgeRock link:https://backstage.forgerock.com/#!/downloads/OpenIDM/Password%20Sync%20Plugins/1.1.0/Active%20Directory%20Password%20Sync%20Plugin#list[BackStage, window=\_blank] site. +. Download the Active Directory password synchronization plugin from the link:https://github.com/WrenSecurity/wrenidm-ad-passwordchange-handler/releases/[GitHub, window=\_blank]. . Install the plugin using one of the following methods: + * Double-click the setup file to launch the installation wizard. -* Alternatively, from a command line, start the installation wizard with the `idm-setup.exe` command. If you want to save the settings in a configuration file, you can use the /saveinf switch as follows. +* Alternatively, from a command line, start the installation wizard with the `idmsync-setup.exe` command. If you want to save the settings in a configuration file, you can use the /saveinf switch as follows. + [source, console] @@ -913,7 +903,7 @@ https://localhost:8444/openidm/managed/user?_action=patch&_queryId=for-userName& If the `password` attribute does not exist in the `managed/user` object on OpenIDM, the password sync service will return an error when it attempts to replay a password update that has been made in Active Directory. If your managed user objects do not include passwords, you can add an `onCreate` script to the Active Directory > Managed Users mapping that sets an empty password when managed user accounts are created. The following excerpt of a `sync.json` file shows such a script in the mapping: + -[source, javascript] +[source, json] ---- "mappings" : [ { diff --git a/openidm/modules/integrators-guide/pages/chap-policies.adoc b/openidm/modules/integrators-guide/pages/chap-policies.adoc index edc02e825e..b84f5ca73d 100644 --- a/openidm/modules/integrators-guide/pages/chap-policies.adoc +++ b/openidm/modules/integrators-guide/pages/chap-policies.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -247,7 +247,7 @@ From OpenIDM 4.5 onwards, the `type` property is subject to policy validation wh OpenIDM supports multiple valid property types. For example, you might have a scenario where a managed user can have more than one telephone number, or an __empty__ telephone number (when the user entry is first created and the telephone number is not yet known). In such a case, you could specify the accepted property type as follows in your `managed.json` file: -[source, javascript] +[source, json] ---- "telephoneNumber" : { "type" : [ "array", "null" ], @@ -307,7 +307,7 @@ function notNull(fullObject, value, params, property) { ---- The `mypolicy.js` policy is referenced in the `policy.json` configuration file as follows: -[source, javascript] +[source, json] ---- { "type" : "text/javascript", @@ -326,7 +326,7 @@ You can extend the policy service to support policies that are applied only unde The following excerpt of a `managed.json` file shows a sample conditional policy configuration for the `"password"` property of managed user objects. The policy indicates that sys-admin users have a more lenient password policy than regular employees: -[source, javascript] +[source, json] ---- { "objects" : [ diff --git a/openidm/modules/integrators-guide/pages/chap-resource-conf.adoc b/openidm/modules/integrators-guide/pages/chap-resource-conf.adoc index 2932b17214..25f9f1cbce 100644 --- a/openidm/modules/integrators-guide/pages/chap-resource-conf.adoc +++ b/openidm/modules/integrators-guide/pages/chap-resource-conf.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -26,7 +26,7 @@ This chapter describes how to connect to external resources such as LDAP, Active Directory, flat files, and others. Configurations shown here are simplified to show essential aspects. Not all resources support all OpenIDM operations; however, the resources shown here support most of the CRUD operations, and also reconciliation and LiveSync. -In OpenIDM, __resources__ are external systems, databases, directory servers, and other sources of identity data that are managed and audited by the identity management system. To connect to resources, OpenIDM loads the Identity Connector Framework, link:https://forgerock.org/openicf/[OpenICF, window=\_blank]. OpenICF aims to avoid the need to install agents to access resources, instead using the resources' native protocols. For example, OpenICF connects to database resources using the database's Java connection libraries or JDBC driver. It connects to directory servers over LDAP. It connects to UNIX systems by using `ssh`. +In OpenIDM, __resources__ are external systems, databases, directory servers, and other sources of identity data that are managed and audited by the identity management system. To connect to resources, OpenIDM loads the Identity Connector Framework, link:https://github.com/OpenIdentityPlatform/OpenICF[OpenICF, window=\_blank]. OpenICF aims to avoid the need to install agents to access resources, instead using the resources' native protocols. For example, OpenICF connects to database resources using the database's Java connection libraries or JDBC driver. It connects to directory servers over LDAP. It connects to UNIX systems by using `ssh`. [#openidm-openicf] === About OpenIDM and OpenICF @@ -59,7 +59,7 @@ When you configure a remote connector, you use the __connector info provider ser The sample connector info provider configuration is as follows: -[source, javascript] +[source, json] ---- { "remoteConnectorServers" : @@ -248,7 +248,7 @@ The sample connector configuration file. The following example indicates that the Java connector server is running on the host `remote-host`, listening on the default port, and configured with a secret key of `Passw0rd`: + -[source] +[source, json] ---- { "remoteConnectorServers" : [ @@ -367,7 +367,7 @@ Starting with OpenIDM 4.5.0 you can specify a list of remote connector servers t The following sample configuration defines two remote connector servers, on hosts `remote-host-1` and `remote-host-2`. These servers are listed, by their `name` property in a group, specified in the `remoteConnectorServersGroups` property. You can configure multiple servers per group, and multiple groups in a single remote connector server configuration file. -[source, javascript] +[source, json] ---- { "connectorsLocation" : "connectors", @@ -407,7 +407,7 @@ The `algorithm` can be either `failover` or `roundrobin`. If the algorithm is `f Your connector configuration file (`provisioner.openicf-connector-name.json`) references the remote connector server group, rather than a single remote connector server. For example, the following excerpt of a PowerShell connector configuration file references the `dotnet-ha` connector server group from the previous configuration: -[source, javascript] +[source, json] ---- { "connectorRef" : { @@ -509,7 +509,7 @@ string, optional If the connector runs remotely, the value of this field must match the `name` field of the `RemoteConnectorServers` object in the connector server configuration file (`provisioner.openicf.connectorinfoprovider.json`). For example: + -[source] +[source, json] ---- ... "remoteConnectorServers" : @@ -536,7 +536,7 @@ The `poolConfigOption` specifies the pool configuration for poolable connectors The following example shows a pool configuration option object for a poolable connector: -[source, javascript] +[source, json] ---- { "maxObjects" : 10, @@ -571,7 +571,7 @@ The minimum number of idle instances of the connector. The operation timeout property enables you to configure timeout values per operation type. By default, no timeout is configured for any operation type. A sample configuration follows: -[source, javascript] +[source, json] ---- { "CREATE" : -1, @@ -606,7 +606,7 @@ The `configurationProperties` object specifies the configuration for the connect The following example shows a configuration properties object for the default XML sample resource connector: -[source, javascript] +[source, json] ---- "configurationProperties" : { "xsdIcfFilePath" : "&{launcher.project.location}/data/resource-schema-1.xsd", @@ -627,7 +627,7 @@ Individual properties depend on the type of connector. The `syncFailureHandler` object specifies what should happen if a LiveSync operation reports a failure for an operation. The following example shows a synchronization failure configuration: -[source, javascript] +[source, json] ---- { "maxRetries" : 5, @@ -664,11 +664,11 @@ For more information, see xref:chap-synchronization.adoc#livesync-retry-strategy [#results-handler-config] ==== Configuring How Results Are Handled -The `resultsHandlerConfig` object specifies how OpenICF returns results. These configuration properties depend on the connector type and on the interfaces that are implemented by that connector type. For information the interfaces that each connector supports, see the link:http://openicf.forgerock.org/doc/config-reference[OpenICF Connector Configuration Reference, window=\_blank]. +The `resultsHandlerConfig` object specifies how OpenICF returns results. These configuration properties depend on the connector type and on the interfaces that are implemented by that connector type. For information the interfaces that each connector supports, see the link:https://github.com/OpenIdentityPlatform/OpenICF/wiki/Connectors-Guide[OpenICF Connector Configuration Reference, window=\_blank]. The following example shows a results handler configuration object: -[source, javascript] +[source, json] ---- { "enableNormalizingResultsHandler" : true, @@ -725,7 +725,7 @@ The OpenICF `__UID__` is a special case. The `__UID__` __must not__ be included The following excerpt shows the configuration of an `account` object type: -[source, javascript] +[source, json] ---- { "account" : @@ -779,7 +779,7 @@ For example, imagine a deployment synchronizing two external systems. On system The `__ALL__` object type is assumed by default - you do not need to declare it in your provisioner configuration file. If it is not declared, the object type is named `__ALL__`. If you want to map a different name for this object type, declare it in your provisioner configuration. The following excerpt from a sample provisioner configuration uses the name `allobjects`: -[source, javascript] +[source, json] ---- "objectTypes": { "allobjects": { @@ -896,7 +896,7 @@ The native OpenICF attribute flags. OpenICF supports the following attribute fla If the attribute type is `array`, an additional `items` field specifies the supported type for the objects in the array. For example: + -[source, javascript] +[source, json] ---- "groups" : { @@ -940,7 +940,7 @@ The `operationOptions` object enables you to deny specific operations on a resou The following example defines the options for the `"SYNC"` operation: -[source, javascript] +[source, json] ---- "operationOptions" : { { @@ -981,31 +981,31 @@ The following example defines the options for the `"SYNC"` operation: ---- The OpenICF Framework supports the following operations: -* `AUTHENTICATE`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/AuthenticationApiOp.html[AuthenticationApiOp, window=\_blank] +* `AUTHENTICATE`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/AuthenticationApiOp.html[AuthenticationApiOp, window=\_blank] -* `CREATE`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/CreateApiOp.html[CreateApiOp, window=\_blank] +* `CREATE`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/CreateApiOp.html[CreateApiOp, window=\_blank] -* `DELETE`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/DeleteApiOp.html[DeleteApiOp, window=\_blank] +* `DELETE`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/DeleteApiOp.html[DeleteApiOp, window=\_blank] -* `GET`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/GetApiOp.html[GetApiOp, window=\_blank] +* `GET`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/GetApiOp.html[GetApiOp, window=\_blank] -* `RESOLVEUSERNAME`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/ResolveUsernameApiOp.html[ResolveUsernameApiOp, window=\_blank] +* `RESOLVEUSERNAME`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/ResolveUsernameApiOp.html[ResolveUsernameApiOp, window=\_blank] -* `SCHEMA`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/SchemaApiOp.html[SchemaApiOp, window=\_blank] +* `SCHEMA`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/SchemaApiOp.html[SchemaApiOp, window=\_blank] -* `SCRIPT_ON_CONNECTOR`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/ScriptOnConnectorApiOp.html[ScriptOnConnectorApiOp, window=\_blank] +* `SCRIPT_ON_CONNECTOR`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/ScriptOnConnectorApiOp.html[ScriptOnConnectorApiOp, window=\_blank] -* `SCRIPT_ON_RESOURCE`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/ScriptOnResourceApiOp.html[ScriptOnResourceApiOp, window=\_blank] +* `SCRIPT_ON_RESOURCE`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/ScriptOnResourceApiOp.html[ScriptOnResourceApiOp, window=\_blank] -* `SEARCH`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/SearchApiOp.html[SearchApiOp, window=\_blank] +* `SEARCH`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/SearchApiOp.html[SearchApiOp, window=\_blank] -* `SYNC`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/SyncApiOp.html[SyncApiOp, window=\_blank] +* `SYNC`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/SyncApiOp.html[SyncApiOp, window=\_blank] -* `TEST`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/TestApiOp.html[TestApiOp, window=\_blank] +* `TEST`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/TestApiOp.html[TestApiOp, window=\_blank] -* `UPDATE`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/UpdateApiOp.html[UpdateApiOp, window=\_blank] +* `UPDATE`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/UpdateApiOp.html[UpdateApiOp, window=\_blank] -* `VALIDATE`: link:http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/operations/ValidateApiOp.html[ValidateApiOp, window=\_blank] +* `VALIDATE`: link:https://doc.openidentityplatform.org/openicf/apidocs/org/identityconnectors/framework/api/operations/ValidateApiOp.html[ValidateApiOp, window=\_blank] -- The `operationOptions` object has the following configurable properties: @@ -1560,7 +1560,7 @@ Log files are available in the `\path\to\openicf\logs` directory. [#connectors-with-openidm] === Connectors Supported With OpenIDM 4.5 -OpenIDM 4.5 provides several connectors by default, in the `path/to/openidm/connectors` directory. The supported connectors that are not bundled with OpenIDM, and a number of additional connectors, can be downloaded from the link:http://openicf.forgerock.org/connectors/[OpenICF community site, window=\_blank]. +OpenIDM 4.5 provides several connectors by default, in the `path/to/openidm/connectors` directory. The supported connectors that are not bundled with OpenIDM, and a number of additional connectors, can be downloaded from the link:https://github.com/OpenIdentityPlatform/OpenICF/[OpenICF community site, window=\_blank]. For details about the connectors that are supported for use with OpenIDM 4.5, see xref:connectors-guide:index.adoc[Connectors Guide]. @@ -2085,7 +2085,7 @@ You can add the attributes of your choice to a connector configuration file. Spe You can configure connectors to enable provisioning of arbitrary property level extensions (such as image files) to system resources. For example, if you want to set up image files such as account avatars, open the appropriate provisioner file. Look for an `account` section similar to: -[source, javascript] +[source, json] ---- "account" : { "$schema" : "http://json-schema.org/draft-03/schema", @@ -2096,7 +2096,7 @@ You can configure connectors to enable provisioning of arbitrary property level ---- Under `properties`, add one of the following code blocks. The first block works for a single photo encoded as a base64 string. The second block would address multiple photos encoded in the same way: -[source, javascript] +[source, json] ---- "attributeByteArray" : { "type" : "string", @@ -2105,7 +2105,7 @@ Under `properties`, add one of the following code blocks. The first block works }, ---- -[source, javascript] +[source, json] ---- "attributeByteArrayMultivalue": { "type": "array", diff --git a/openidm/modules/integrators-guide/pages/chap-scheduler-conf.adoc b/openidm/modules/integrators-guide/pages/chap-scheduler-conf.adoc index de974484b6..0ea8251871 100644 --- a/openidm/modules/integrators-guide/pages/chap-scheduler-conf.adoc +++ b/openidm/modules/integrators-guide/pages/chap-scheduler-conf.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -57,7 +57,7 @@ openidm.scheduler.execute.persistent.schedules=true ---- The scheduler service configuration file (`project-dir/conf/scheduler.json`) governs the configuration for a specific scheduler instance, and has the following format: -[source, javascript] +[source, json] ---- { "threadPool" : { @@ -87,7 +87,7 @@ For details of all the configurable properties for the Quartz Scheduler, see the Each schedule configuration file (`project-dir/conf/schedule-schedule-name.json`) has the following format: -[source, javascript] +[source, json] ---- { "enabled" : true, @@ -169,7 +169,7 @@ Specifies contextual information, depending on the type of scheduled event (the The following example invokes reconciliation: + -[source, javascript] +[source, json] ---- { "invokeService": "sync", @@ -190,7 +190,7 @@ For a scheduled reconciliation task, you can define the mapping in one of two wa The following example invokes a LiveSync operation: + -[source, javascript] +[source, json] ---- { "invokeService": "provisioner", @@ -207,7 +207,7 @@ For scheduled LiveSync tasks, the `source` property follows OpenIDM's convention The following example invokes a script, which prints the string `Hello World` to the OpenIDM log (`/openidm/logs/openidm0.log.X`). + -[source, javascript] +[source, json] ---- { "invokeService": "script", @@ -280,7 +280,7 @@ If OpenIDM is down when a scheduled task was set to occur, one or more runs of t The following example shows a schedule for reconciliation that is not enabled. When the schedule is enabled (`"enabled" : true,`), reconciliation runs every 30 minutes, starting on the hour: -[source, javascript] +[source, json] ---- { "enabled": false, @@ -296,7 +296,7 @@ The following example shows a schedule for reconciliation that is not enabled. W ---- The following example shows a schedule for LiveSync enabled to run every 15 seconds, starting at the beginning of the minute. The schedule is persisted, that is, stored in the internal repository rather than in memory. If one or more LiveSync runs are missed, as a result of OpenIDM being unavailable, the first run of the LiveSync operation is implemented when the server is back online. Subsequent runs are discarded. After this, the normal schedule is resumed: -[source, javascript] +[source, json] ---- { "enabled": true, @@ -631,7 +631,7 @@ The task scanner is essentially a scheduled task that queries a set of managed u The following example defines a scheduled scanning task that triggers a sunset script. The schedule configuration file is provided in `openidm/samples/taskscanner/conf/schedule-taskscan_sunset.json`. To use this sample file, copy it to the `openidm/conf` directory. -[source, javascript] +[source, json] ---- { "enabled" : true, @@ -729,7 +729,7 @@ In the previous example, the scanner scans for users whose `sunset/date` is prio You can use these fields to define any condition. For example, if you wanted to limit the scanned objects to a specified location, say, London, you could formulate a query to compare against object locations and then set the condition to be: + -[source, javascript] +[source, json] ---- "condition" : { "location" : "London" diff --git a/openidm/modules/integrators-guide/pages/chap-scripting.adoc b/openidm/modules/integrators-guide/pages/chap-scripting.adoc index 1e45ff0f1b..f6aff985d9 100644 --- a/openidm/modules/integrators-guide/pages/chap-scripting.adoc +++ b/openidm/modules/integrators-guide/pages/chap-scripting.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -144,7 +144,7 @@ Endpoint configuration files and scripts are discussed further in the following An endpoint configuration file includes the following elements: -[source, javascript] +[source, json] ---- { "context" : "endpoint/linkedView/*", diff --git a/openidm/modules/integrators-guide/pages/chap-security.adoc b/openidm/modules/integrators-guide/pages/chap-security.adoc index 000b80e6de..9372db3633 100644 --- a/openidm/modules/integrators-guide/pages/chap-security.adoc +++ b/openidm/modules/integrators-guide/pages/chap-security.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -189,7 +189,7 @@ By default, OpenIDM uses the certificate with the alias `openidm-localhost` to s If you do not have an existing signed certificate, you can generate a certificate signing request (CSR) over REST, as described in this section. The details of the CSR are specified in JSON format, for example: -[source, javascript] +[source, json] ---- { "CN" : "www.example.com", @@ -894,7 +894,7 @@ Use a strong password for the JDBC connection and change at least the password o For example, the following excerpt of a MySQL connection configuration file indicates the required change when the database user password has been changed to `myPassw0rd`. -[source, javascript] +[source, json] ---- { "driverClass" : "com.mysql.jdbc.Driver", @@ -914,7 +914,7 @@ Use a case sensitive database, particularly if you work with systems with differ [#remove-orientdb] ==== Remove OrientDB Studio -OpenIDM ships with the OrientDB Studio web application. ForgeRock strongly recommends that you remove the web application before deploying in a production environment. To remove OrientDB studio, delete the following directory: +OpenIDM ships with the OrientDB Studio web application. Open Identity Platform Community strongly recommends that you remove the web application before deploying in a production environment. To remove OrientDB studio, delete the following directory: [source, console] ---- diff --git a/openidm/modules/integrators-guide/pages/chap-services.adoc b/openidm/modules/integrators-guide/pages/chap-services.adoc index 613e0d85b7..306f94da4f 100644 --- a/openidm/modules/integrators-guide/pages/chap-services.adoc +++ b/openidm/modules/integrators-guide/pages/chap-services.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -111,7 +111,7 @@ If you do not provide an absolute path, the project location path is relative to [NOTE] ==== -When we refer to "your project" in ForgeRock's OpenIDM documentation, we're referring to the value of `launcher.project.location`. +When we refer to "your project" in Open Identity Platform's OpenIDM documentation, we're referring to the value of `launcher.project.location`. ==== * `--working-location` or `-w` `/path/to/working/directory` @@ -521,7 +521,7 @@ OpenIDM checks all required modules. Examples of those modules are shown here: [source, console] ---- -"org.forgerock.openicf.framework.connector-framework" + "org.forgerock.openicf.framework.connector-framework" "org.forgerock.openicf.framework.connector-framework-internal" "org.forgerock.openicf.framework.connector-framework-osgi" "org.forgerock.openidm.audit" @@ -556,7 +556,7 @@ OpenIDM checks all required services. Examples of those services are shown here: [source, console] ---- -"org.forgerock.openidm.config" + "org.forgerock.openidm.config" "org.forgerock.openidm.provisioner" "org.forgerock.openidm.provisioner.openicf.connectorinfoprovider" "org.forgerock.openidm.external.rest" @@ -738,7 +738,7 @@ The relevant JPDA options are outlined in the startup script (`startup.sh`). [CAUTION] ==== -This interface is internal and subject to change. If you depend on this interface, contact ForgeRock support. +This interface is internal and subject to change. If you depend on this interface, contact Open Identity Platform Approved Vendors support. ==== diff --git a/openidm/modules/integrators-guide/pages/chap-synchronization.adoc b/openidm/modules/integrators-guide/pages/chap-synchronization.adoc index 06c9293833..e3a3de23dd 100644 --- a/openidm/modules/integrators-guide/pages/chap-synchronization.adoc +++ b/openidm/modules/integrators-guide/pages/chap-synchronization.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -95,7 +95,7 @@ OpenIDM leaves the data model choice up to you. You determine the right trade of You can, for example, choose to follow the data model defined in the Simple Cloud Identity Management (link:http://www.simplecloud.info/specs/draft-scim-core-schema-00.html[SCIM, window=\_blank]) specification. The following object represents a SCIM user: -[source, javascript] +[source, json] ---- { "userName": "james1", @@ -170,7 +170,7 @@ A number of sample provisioner files are provided in `path/to/openidm/samples/pr The following excerpt of an example LDAP connector configuration shows the name for the connector and two attributes of an account object type. In the attribute mapping definitions, the attribute name is mapped from the `nativeName` (the attribute name used on the external resource) to the attribute name that is used in OpenIDM. The `sn` attribute in LDAP is mapped to `lastName` in OpenIDM. The `homePhone` attribute is defined as an array, because it can have multiple values: -[source, javascript] +[source, json] ---- { "name": "MyLDAP", @@ -230,7 +230,7 @@ Objects in external resources are specified in a mapping as `system/name/object- External resources, and OpenIDM managed objects, can be the __source__ or the __target__ in a mapping. By convention, the mapping name is a string of the form `source_target`, as shown in the following example: -[source, javascript] +[source, json] ---- { "mappings": [ @@ -304,7 +304,7 @@ To set up attributes with default values in the Admin UI: Use a mapping to define attribute transformations during synchronization. In the following sample mapping excerpt, the value of the `displayName` attribute on the target is set using a combination of the `lastName` and `firstName` attribute values from the source: -[source, javascript] +[source, json] ---- { "source": "", @@ -355,7 +355,7 @@ Scriptable conditions create mapping logic, based on the result of the condition In the following excerpt, the value of the target `mail` attribute is set to the value of the source `email` attribute __only if__ the source attribute is not empty: -[source, javascript] +[source, json] ---- { "target": "mail", @@ -391,7 +391,7 @@ Link qualifiers are defined as part of the mapping (in your project's `conf/sync Link qualifiers can be defined as a static list, or dynamically, using a script. The following excerpt from a sample mapping shows the two static link qualifiers, `employee` and `customer`, described in the previous example: -[source, javascript] +[source, json] ---- { "mappings": [ @@ -413,7 +413,7 @@ If your source resource includes a large number of records, you should use a dyn You can include a dynamic link qualifier script inline (using the `source` property), or by referencing a JavaScript or Groovy script file (using the `file` property). The following link qualifier script sets up the dynamic link qualifier lists described in the previous example: -[source, javascript] +[source, json] ---- { "mappings": [ @@ -431,7 +431,7 @@ You can include a dynamic link qualifier script inline (using the `source` prope ---- To reference an external link qualifier script, provide a link to the file in the `file` property: -[source, javascript] +[source, json] ---- { "mappings": [ @@ -454,21 +454,21 @@ On their own, link qualifiers have no functionality. However, they can be refere The following excerpt of a sample mapping defines a transformation script that generates the value of the `dn` attribute on an LDAP system. If the link qualifier is `employee`, the value of the target `dn` is set to `"uid=userName,ou=employees,dc=example,dc=com"`. If the link qualifier is `customer`, the value of the target `dn` is set to `"uid=userName,ou=customers,dc=example,dc=com"`. The reconciliation operation iterates through the link qualifiers for each source record. In this case, two LDAP objects, with different `dn`s would created for each managed user object. + -[source, javascript] +[source, json] ---- { - "target" : "dn", - "transform" : { - "type" : "text/javascript", - "globals" : { }, - "source" : "if (linkQualifier === 'employee') - { 'uid=' + source.userName + ',ou=employees,dc=example,dc=com'; } - else - if (linkQualifier === 'customer') - { 'uid=' + source.userName + ',ou=customers,dc=example,dc=com'; }" - }, - "source" : "" - } + "target" : "dn", + "transform" : { + "type" : "text/javascript", + "globals" : { }, + "source" : "if (linkQualifier === 'employee') + { 'uid=' + source.userName + ',ou=employees,dc=example,dc=com'; } + else + if (linkQualifier === 'customer') + { 'uid=' + source.userName + ',ou=customers,dc=example,dc=com'; }" + }, + "source" : "" +} ---- * Use link qualifiers in conjunction with a __correlation query__ that assigns a link qualifier based on the values of an existing target object. @@ -478,21 +478,21 @@ During the source synchronization, OpenIDM queries the target system for every s The following excerpt of a sample mapping shows the two link qualifiers described previously (`employee` and `customer`). The correlation query first searches the target system for the `employee` link qualifier. If a target object matches the query, based on the value of its `dn` attribute, OpenIDM creates a link between the source object and that target object and assigns the `employee` link qualifier to that link. This process is repeated for all source records. Then, the correlation query searches the target system for the `customer` link qualifier. If a target object matches that query, OpenIDM creates a link between the source object and that target object and assigns the `customer` link qualifier to that link. + -[source, javascript] +[source, json] ---- -"linkQualifiers" : ["employee", "customer"], - "correlationQuery" : [ -   { + "linkQualifiers" : ["employee", "customer"], + "correlationQuery" : [ + { "linkQualifier" : "employee", -      "type" : "text/javascript", -      "source" : "var query = {'_queryFilter': 'dn co \"' + uid=source.userName + 'ou=employees\"'}; query;" -    }, -    { + "type" : "text/javascript", + "source" : "var query = {'_queryFilter': 'dn co \"' + uid=source.userName + 'ou=employees\"'}; query;" + }, + { "linkQualifier" : "customer", -      "type" : "text/javascript", -      "source" : "var query = {'_queryFilter': 'dn co \"' + uid=source.userName + 'ou=customers\"'}; query;" -    } -  ] + "type" : "text/javascript", + "source" : "var query = {'_queryFilter': 'dn co \"' + uid=source.userName + 'ou=customers\"'}; query;" + } + ] ... ---- + @@ -503,7 +503,7 @@ For more information about correlation queries, see xref:#correlation["Correlati The following excerpt of a sample `sync.json` file shows two link qualifiers, `user` and `test`. Depending on the link qualifier, different actions are taken when the target record is ABSENT: + -[source, javascript] +[source, json] ---- { "mappings" : [ @@ -524,8 +524,8 @@ The following excerpt of a sample `sync.json` file shows two link qualifiers, `u }, { "situation" : "FOUND", - "action" : "UPDATE - } + "action" : "UPDATE" + }, { "condition" : "/linkQualifier eq \"user\"", "situation" : "ABSENT", @@ -613,7 +613,7 @@ Using a query expression in this way is not recommended as it exposes your syste [#correlation-filtered-queries] -======= Using Filtered Queries to Correlate Objects +====== Using Filtered Queries to Correlate Objects For filtered queries, the script that is defined or referenced in the `correlationQuery` property must return an object with the following elements: @@ -624,7 +624,7 @@ The element on the target object is not necessarily a single attribute. Your que If the target object is a system object, this attribute must be referred to by its OpenIDM name rather than its OpenICF `nativeName`. For example, given the following provisioner configuration excerpt, the attribute to use in the correlation query would be `uid` and not `__NAME__`: + -[source, javascript] +[source, json] ---- "uid" : { "type" : "string", @@ -643,7 +643,7 @@ You might use a transformation of a source object property, such as `toUpperCase The following correlation query matches source and target objects if the value of the `uid` attribute on the target is the same as the `userName` attribute on the source: -[source, javascript] +[source, json] ---- "correlationQuery" : { "type" : "text/javascript", @@ -654,13 +654,13 @@ The query can return zero or more objects. The situation that OpenIDM assigns to [#correlation-predefined-queries] -======= Using Predefined Queries to Correlate Objects +====== Using Predefined Queries to Correlate Objects For correlation queries on __managed objects__, you can use a query that has been predefined in the database table configuration file for the repository, either `conf/repo.jdbc.json` or `conf/repo.orientdb.json`. You reference the query ID in your project's `conf/sync.json` file. The following example shows a query defined in the OrientDB repository configuration (`conf/repo.orientdb.json`) that can be used as the basis for a correlation query: -[source, javascript] +[source, json] ---- "for-userName" : "SELECT * FROM ${unquoted:_resource} WHERE userName = ${uid} SKIP ${unquoted:_pagedResultsOffset} LIMIT ${unquoted:_pageSize}" @@ -669,7 +669,7 @@ By default, a `${value}` token replacement is assumed to be a quoted string. If You would call this query in the mapping (`sync.json`) file as follows: -[source, javascript] +[source, json] ---- { "correlationQuery": { @@ -683,7 +683,7 @@ In this correlation query, the `_queryId` property value (`for-userName`) matche [#correlation-expression-builder] -======= Using the Expression Builder to Create Correlation Queries +====== Using the Expression Builder to Create Correlation Queries OpenIDM provides a declarative correlation option, the expression builder, that makes it easier to configure correlation queries. @@ -710,7 +710,7 @@ image::ROOT:expression-builder.png[] The correlation query created in the previous steps displays as follows in the mapping configuration (`sync.json`): -[source, javascript] +[source, json] ---- "correlationQuery" : [ { @@ -791,9 +791,6 @@ To create a correlation script, use the details from the source object to find t . Click Save to save the script as part of the mapping. - - - [#filtering-source-and-target] ==== Filtering Synchronized Objects @@ -804,7 +801,7 @@ By default, OpenIDM synchronizes all objects that match those defined in the con A script that determines if a source object is valid to be mapped. The script yields a boolean value: `true` indicates that the source object is valid; `false` can be used to defer mapping until some condition is met. In the root scope, the source object is provided in the `"source"` property. If the script is not specified, then all source objects are considered valid: + -[source, javascript] +[source, json] ---- { "validSource": { @@ -818,7 +815,7 @@ A script that determines if a source object is valid to be mapped. The script yi A script used during the second phase of reconciliation that determines if a target object is valid to be mapped. The script yields a boolean value: `true` indicates that the target object is valid; `false` indicates that the target object should not be included in reconciliation. In the root scope, the source object is provided in the `"target"` property. If the script is not specified, then all target objects are considered valid for mapping: + -[source, javascript] +[source, json] ---- { "validTarget": { @@ -838,7 +835,7 @@ This condition works like a `validSource` script. Its value can be either a `que The following `sourceCondition` restricts synchronization to those user objects whose account status is `active`: + -[source, javascript] +[source, json] ---- { "mappings": [ @@ -855,7 +852,7 @@ The following `sourceCondition` restricts synchronization to those user objects -- During synchronization, your scripts and filters have access to a `source` object and a `target` object. Examples already shown in this section use `source.attributeName` to retrieve attributes from the source objects. Your scripts can also write to target attributes using `target.attributeName` syntax: -[source, javascript] +[source, json] ---- { "onUpdate": { @@ -885,7 +882,7 @@ This behavior prevents reconciliation operations from accidentally deleting ever When you __do__ want reconciliations of an empty source resource to proceed, override the default behavior by setting the `"allowEmptySourceSet"` property to `true` in the mapping. For example: -[source] +[source, json] ---- { "mappings" : [ @@ -916,7 +913,7 @@ If, subsequent to the `onUpdate` script running, the synchronization process det ==== The following sample extract of a `sync.json` file derives a DN for an LDAP entry when the entry is created in the internal repository: -[source, javascript] +[source, json] ---- { "onCreate": { @@ -933,7 +930,7 @@ The following sample extract of a `sync.json` file derives a DN for an LDAP entr xref:#constructing-attributes["Constructing and Manipulating Attributes With Scripts"] shows how to manipulate attributes with scripts when objects are created and updated. You might want to trigger scripts in response to other synchronization actions. For example, you might not want OpenIDM to delete a managed user directly when an external account record is deleted, but instead unlink the objects and deactivate the user in another resource. (Alternatively, you might delete the object in OpenIDM but nevertheless execute a script.) The following example shows a more advanced mapping configuration that exposes the script hooks available during synchronization. -[source, javascript] +[source, json] ---- { "mappings": [ @@ -1097,7 +1094,7 @@ When two mappings synchronize the same objects bidirectionally, use the `links` The following excerpt shows two mappings, one from MyLDAP accounts to managed users, and another from managed users to MyLDAP accounts. In the second mapping, the `link` property tells OpenIDM to reuse the links created in the first mapping, rather than create new links: -[source, javascript] +[source, json] ---- { "mappings": [ @@ -1456,7 +1453,7 @@ $ curl \ A successful liveSync operation returns the following response: -[source, console] +[source, json] ---- { "_rev": "4", @@ -1499,7 +1496,7 @@ You can restrict reconciliation to specific entries by defining explicit source To restrict reconciliation to only those records whose `employeeType` on the source resource is `Permanent`, you might specify a source query as follows: -[source, javascript] +[source, json] ---- "mappings" : [ { @@ -1528,7 +1525,7 @@ For queries on system objects: The source and target queries send the query to the resource that is defined for that source or target, by default. You can override the resource the query is to sent by specifying a `resourceName` in the query. For example, to query a specific endpoint instead of the source resource, you might modify the preceding source query as follows: -[source, javascript] +[source, json] ---- "mappings" : [ { @@ -1603,7 +1600,7 @@ Generally, a scheduled reconciliation operation will eventually force consistenc The liveSync retry policy is configured in the connector configuration file (`provisioner.openicf-*.json`). The sample connector configuration files have a retry policy defined as follows: -[source, javascript] +[source, json] ---- "syncFailureHandler" : { "maxRetries" : 5, @@ -1630,7 +1627,7 @@ In addition to the regular objects described in xref:appendix-scripting.adoc#app Provides details about the failed record. The structure of the `syncFailure` object is as follows: + -[source, javascript] +[source, json] ---- "syncFailure" : { @@ -1672,7 +1669,7 @@ Two sample scripts are provided in `path/to/openidm/samples/syncfailure/script`, The following sample provisioner configuration file extract shows a liveSync retry policy that specifies a maximum of four retries before the failed modification is sent to the dead letter queue: -[source, javascript] +[source, json] ---- ... "connectorName" : "org.identityconnectors.ldap.LdapConnector" @@ -1759,7 +1756,7 @@ By default, all mappings are automatically synchronized. A change to a managed o To prevent automatic synchronization for a specific mapping, set the `enableSync` property of that mapping to false. In the following example, implicit synchronization is disabled. This means that changes to objects in the internal repository are not automatically propagated to the LDAP directory. To propagate changes to the LDAP directory, reconciliation must be launched manually: -[source, javascript] +[source, json] ---- { "mappings" : [ @@ -1785,7 +1782,7 @@ You can configure implicit synchronization to revert a reconciliation operation Failure compensation works by using the optional `onSync` hook, which can be specified in the `conf/managed.json` file. The `onSync` hook can be used to provide failure compensation as follows: -[source, javascript] +[source, json] ---- ... "onDelete" : { @@ -1833,7 +1830,7 @@ OpenIDM then takes a specific action, depending on the situation. You can define actions for particular situations in the `policies` section of a synchronization mapping, as shown in the following excerpt from the `sync.json` file of Sample 2b: -[source, javascript] +[source, json] ---- { "policies": [ @@ -2416,7 +2413,7 @@ In addition to the static synchronization actions described in the previous sect The following excerpt of a sample `sync.json` file specifies that an inline script should be invoked when a synchronization operation assesses an entry as `ABSENT` in the target system. The script checks whether the `employeeType` property of the corresponding source entry is `contractor`. If so, the entry is ignored. Otherwise, the entry is created on the target system: -[source, javascript] +[source, json] ---- { "situation" : "ABSENT", @@ -2453,7 +2450,7 @@ The parameters for the workflow are passed as properties of the `action` paramet The following extract of a sample `sync.json` file specifies that, when a synchronization operation assesses an entry as `ABSENT`, the workflow named `managedUserApproval` is invoked: -[source, javascript] +[source, json] ---- { "situation" : "ABSENT", @@ -2496,7 +2493,7 @@ Configuring asynchronous reconciliation using a workflow involves the following For example, the following `sync.json` extract calls the `managedUserApproval` workflow if the situation is assessed as `ABSENT`: + -[source, javascript] +[source, json] ---- { "situation" : "ABSENT", @@ -2557,22 +2554,22 @@ For such data stores, you can configure OpenIDM to ignore case during reconcilia To specify case-insensitive data stores, set the `sourceIdsCaseSensitive` or `targetIdsCaseSensitive` property to `false` in the mapping for those links. For example, if the LDAP data store is case-insensitive, set the mapping from the LDAP store to the managed user repository as follows: -[source, javascript] +[source, json] ---- "mappings" : [ -{ -"name" : "systemLdapAccounts_managedUser", -"source" : "system/ldap/account", -"sourceIdsCaseSensitive" : false, -"target" : "managed/user", -"properties" : [ + { + "name" : "systemLdapAccounts_managedUser", + "source" : "system/ldap/account", + "sourceIdsCaseSensitive" : false, + "target" : "managed/user", + "properties" : [ ... ---- If a mapping inherits links by using the `links` property, you do not need to set case-sensitivity, because the mapping uses the setting of the referred links. Be aware that, even if you configure OpenIDM to be case-insensitive when comparing links, the OpenICF provisioner is not necessarily case-insensitive when it requests data. For example, if a user entry is stored with the ID `testuser` and you make a request for `\https://localhost:8443/openidm/managed/TESTuser`, most provisioners will filter out the match because of the difference in case, and will indicate that the record is not found. To prevent the provisioner from performing this secondary filtering, set the `enableFilteredResultsHandler` property to `false` in the provisioner configuration. For example: -[source, console] +[source, json] ---- "resultsHandlerConfig" : { @@ -2596,7 +2593,7 @@ By default, reconciliation is configured to function optimally, with regard to p To optimize performance, reconciliation does not correlate source objects to target objects if the set of target objects is empty when the correlation is started. This considerably speeds up the process the first time reconciliation is run. You can change this behavior for a specific mapping by adding the `correlateEmptyTargetSet` property to the mapping definition and setting it to `true`. For example: -[source, javascript] +[source, json] ---- { "mappings": [ @@ -2617,14 +2614,14 @@ Be aware that this setting will have a performance impact on the reconciliation All links are queried at the start of reconciliation and the results of that query are used. You can disable the link prefetching so that the reconciliation process looks up each link in the database as it processes each source or target object. You can disable the prefetching of links by adding the `prefetchLinks` property to the mapping, and setting it to `false`, for example: -[source, javascript] +[source, json] ---- { "mappings": [ { "name": "systemMyLDAPAccounts_managedUser", "source": "system/MyLDAP/account", - "target": "managed/user" + "target": "managed/user", "prefetchLinks" : false } ] @@ -2644,7 +2641,7 @@ By default, reconciliation is multithreaded; numerous threads are dedicated to t To change the number of threads, set the `taskThreads` property in the `conf/sync.json` file, for example: -[source, javascript] +[source, json] ---- "mappings" : [ { @@ -2671,7 +2668,7 @@ The optimization works by defining a `sourceQuery` or `targetQuery` in the synch The following example query loads the full result set into memory during the source phase of the reconciliation. The example uses a common filter expression, called with the `_queryFilter` keyword. The query returns the complete object: -[source, javascript] +[source, json] ---- "mappings" : [ { @@ -2693,7 +2690,7 @@ Setting these properties to `true` indicates that the complete object is returne The following excerpt indicates that the full objects are returned and that OpenIDM should not autodetect the result set: -[source, javascript] +[source, json] ---- "mappings" : [ { @@ -2710,7 +2707,7 @@ By default, all the attributes that are defined in the connector configuration f The following excerpt loads only a subset of attributes into memory, for all users in an LDAP directory. -[source, javascript] +[source, json] ---- "mappings" : [ { @@ -2746,7 +2743,7 @@ To alleviate this constraint, OpenIDM supports reconciliation paging, which brea Reconciliation paging is disabled by default, and can be enabled per mapping (in the `sync.json` file). To configure reconciliation paging, set the `reconSourceQueryPaging` property to `true` and set the `reconSourceQueryPageSize` in the synchronization mapping, for example: -[source, javascript] +[source, json] ---- { "mappings" : [ @@ -2777,7 +2774,7 @@ Each scheduled reconciliation and liveSync task requires a schedule configuratio Schedule configuration files have the following format: -[source, javascript] +[source, json] ---- { "enabled" : true, @@ -2798,7 +2795,7 @@ To schedule a reconciliation or liveSync task, set the `invokeService` property The value of the `invokeContext` property depends on the type of scheduled event. For reconciliation, the properties are set as follows: -[source, javascript] +[source, json] ---- { "invokeService": "sync", @@ -2812,7 +2809,7 @@ The `mapping` is either referenced by its name in the `conf/sync.json` file, or For liveSync, the properties are set as follows: -[source, javascript] +[source, json] ---- { "invokeService": "provisioner", @@ -2837,7 +2834,7 @@ Daylight Savings Time (DST) can cause problems for scheduled liveSync operations Mappings for synchronization operations are usually stored in your project's `sync.json` file. You can, however, provide the mapping for scheduled synchronization operation by including it as part of the `invokeContext` of the schedule configuration, as shown in the following example: -[source, javascript] +[source, json] ---- { "enabled": true, diff --git a/openidm/modules/integrators-guide/pages/chap-troubleshooting.adoc b/openidm/modules/integrators-guide/pages/chap-troubleshooting.adoc index ddf1c40bb2..146a0573c8 100644 --- a/openidm/modules/integrators-guide/pages/chap-troubleshooting.adoc +++ b/openidm/modules/integrators-guide/pages/chap-troubleshooting.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -107,7 +107,7 @@ After fixing your configuration, change to the `/path/to/openidm/` directory, an OpenIDM throws the following error as a result of a reconciliation where the source systems configuration can not be found. -[source, javascript] +[source, json] ---- { "error": "Conflict", diff --git a/openidm/modules/integrators-guide/pages/chap-ui.adoc b/openidm/modules/integrators-guide/pages/chap-ui.adoc index b17472e52a..6f8162817b 100644 --- a/openidm/modules/integrators-guide/pages/chap-ui.adoc +++ b/openidm/modules/integrators-guide/pages/chap-ui.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -1146,7 +1146,7 @@ You can find these `stylesheets` in the `/css` subdirectory. * `bootstrap-3.3.5-custom.css`: Includes custom settings that you can get from various Bootstrap configuration sites, such as the Bootstrap link:http://getbootstrap.com/customize/[Customize and Download, window=\_blank] website. + -You may find the ForgeRock version of this in the `config.json` file in the `ui/selfservice/default/css/common/structure/` directory. +You may find the version of this in the `config.json` file in the `ui/selfservice/default/css/common/structure/` directory. * `structure.css`: Supports configuration of structural elements of the UI. diff --git a/openidm/modules/integrators-guide/pages/chap-users-groups-roles.adoc b/openidm/modules/integrators-guide/pages/chap-users-groups-roles.adoc index cf1c74c692..263bf2973c 100644 --- a/openidm/modules/integrators-guide/pages/chap-users-groups-roles.adoc +++ b/openidm/modules/integrators-guide/pages/chap-users-groups-roles.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -1001,7 +1001,6 @@ The easiest way to create an assignment is by using the Admin UI, as follows: + Select the unassignment operation from the dropdown list. You can set the unassignment operation to one of the following: -+ * `Remove From Target` - the attribute value is removed from the system object when the user is no longer a member of the role, or when the assignment itself is removed from the role definition. (Property: `removeFromTarget`.) diff --git a/openidm/modules/integrators-guide/pages/chap-workflow.adoc b/openidm/modules/integrators-guide/pages/chap-workflow.adoc index 2b1fbc969e..6c328ee63a 100644 --- a/openidm/modules/integrators-guide/pages/chap-workflow.adoc +++ b/openidm/modules/integrators-guide/pages/chap-workflow.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -171,7 +171,7 @@ script task using expression resolver: [ The OpenIDM Activiti module is configured in a file named `conf/workflow.json`. To disable workflows, do not include this file in your project's `conf/` subdirectory. In the default OpenIDM installation, the `workflow.json` file is shown here: -[source, javascript] +[source, json] ---- { "useDataSource" : "default", @@ -191,7 +191,7 @@ There are several additional configuration properties for the Activiti module. A The sample `workflow.json` file contains the following configuration: -[source, javascript] +[source, json] ---- { "location" : "remote", @@ -345,7 +345,7 @@ If there is more than one workflow definition with the same `_key` parameter, th To obtain the `processDefinitionId`, query the available workflows, for example: + -[source, javascript] +[source, json] ---- { "result": [ @@ -437,7 +437,8 @@ This method is not ideal, because the HTML code must be escaped, and is difficul === Managing Workflows Over the REST Interface In addition to the queries described previously, the following examples show the context paths that are exposed for managing workflows over the REST interface. The example output is based on the sample workflow that is provided in `openidm/samples/sample9`. -====openidm/workflow/processdefinition + +==== openidm/workflow/processdefinition * List the available workflow definitions: @@ -513,7 +514,7 @@ $ curl \ } ---- -====openidm/workflow/processdefinition/{id} +==== openidm/workflow/processdefinition/{id} * Obtain detailed information for a process definition, based on the ID. You can determine the ID by querying all the available process definitions, as described in the first example in this section. @@ -642,7 +643,7 @@ $ curl \ + The delete request returns the contents of the deleted workflow definition. -====openidm/workflow/processinstance +==== openidm/workflow/processinstance * Start a workflow process instance. For example: @@ -716,7 +717,7 @@ $ curl \ "https://localhost:8443/openidm/workflow/processinstance?_queryId=filtered-query&businessKey=myBusinessKey" ---- -====openidm/workflow/processinstance/{id} +==== openidm/workflow/processinstance/{id} * Obtain the details of the specified process instance. For example: @@ -781,7 +782,7 @@ $ curl \ + The delete request returns the contents of the deleted process instance. -====openidm/workflow/processinstance/history +==== openidm/workflow/processinstance/history * List the running and completed workflows (process instances). @@ -964,7 +965,7 @@ $ curl \ The Activiti engine treats certain property values as __strings__, regardless of their actual data type. This might result in results being returned in an order that is different to what you might expect. For example, if you wanted to sort the following results by their `_id` field, `"88", "45", "101"`, you would expect them to be returned in the order `"45", "88", "101"`. Because Activiti treats IDs as strings, rather than numbers, they would be returned in the order `"101", "45", "88"`. ==== -====openidm/workflow/processdefinition/{id}/taskdefinition +==== openidm/workflow/processdefinition/{id}/taskdefinition * Query the list of tasks defined for a specific process definition. For example: @@ -1105,7 +1106,7 @@ $ curl \ } ---- -====openidm/workflow/taskinstance +==== openidm/workflow/taskinstance * Query all running task instances. For example: @@ -1184,7 +1185,7 @@ $ curl \ + Note that you can include both users and groups in the same query. -====openidm/workflow/taskinstance/{id} +==== openidm/workflow/taskinstance/{id} * Obtain detailed information for a running task, based on the task ID. For example: diff --git a/openidm/modules/samples-guide/pages/chap-audit-sample.adoc b/openidm/modules/samples-guide/pages/chap-audit-sample.adoc index db9459dcf7..4afac24234 100644 --- a/openidm/modules/samples-guide/pages/chap-audit-sample.adoc +++ b/openidm/modules/samples-guide/pages/chap-audit-sample.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -162,7 +162,7 @@ Starting with OpenIDM 4.5.0, you can configure a Java Message Service (JMS) Audi [WARNING] ==== -JMS topics are not related to ForgeRock audit event topics. The ForgeRock implementation of JMS topics use the link:http://docs.oracle.com/javaee/6/tutorial/doc/bncdx.html#bnced[publish/subscribe messaging domain, window=\_blank], and may direct messages to the JMS audit event handler. In contrast, ForgeRock audit event topics specify categories of events. +JMS topics are not related to Open Identity Platform audit event topics. The Open Identity Platform implementation of JMS topics use the link:http://docs.oracle.com/javaee/6/tutorial/doc/bncdx.html#bnced[publish/subscribe messaging domain, window=\_blank], and may direct messages to the JMS audit event handler. In contrast, Open Identity Platform audit event topics specify categories of events. ==== In this sample, we demonstrate the use of the JMS audit event handler. This sample is based on xref:chap-xml-samples.adoc#more-sample-1["First OpenIDM Sample - Reconciling an XML File Resource"]. You will set up communications between OpenIDM and an external JMS Message Broker, as well as link:http://activemq.apache.org/[Apache Active MQ, window=\_blank] as the JMS provider and message broker. diff --git a/openidm/modules/samples-guide/pages/chap-fullstack-sample.adoc b/openidm/modules/samples-guide/pages/chap-fullstack-sample.adoc index 584f631ee6..11d7e3207b 100644 --- a/openidm/modules/samples-guide/pages/chap-fullstack-sample.adoc +++ b/openidm/modules/samples-guide/pages/chap-fullstack-sample.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -22,9 +22,9 @@ [#chap-fullstack-sample] -== Full Stack Sample - Using OpenIDM in the ForgeRock Identity Platform +== Full Stack Sample - Using OpenIDM in the Open Identity Platform -This sample demonstrates the integration of three ForgeRock products: OpenIDM, OpenDJ, and OpenAM. With this sample, you can see how you can use OpenAM for authentication, for users maintained with OpenIDM, based on a data store of users in OpenDJ. +This sample demonstrates the integration of three Open Identity Platform products: OpenIDM, OpenDJ, and OpenAM. With this sample, you can see how you can use OpenAM for authentication, for users maintained with OpenIDM, based on a data store of users in OpenDJ. It may take some time to set up this sample. The instructions that follow describe how you set up OpenDJ with a custom data store, sync that to OpenIDM. You will also configure OpenAM to use that same instance of OpenDJ. When you finish this sample, you will know how make OpenIDM, OpenDJ, and OpenAM work together. When your setup is complete, OpenIDM will authorize, and OpenAM will protect your users. diff --git a/openidm/modules/samples-guide/pages/chap-google-sample.adoc b/openidm/modules/samples-guide/pages/chap-google-sample.adoc index a9cd5fc369..443425902a 100644 --- a/openidm/modules/samples-guide/pages/chap-google-sample.adoc +++ b/openidm/modules/samples-guide/pages/chap-google-sample.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -28,7 +28,7 @@ OpenICF provides a Google Apps Connector that enables you to interact with Googl [NOTE] ==== -The Google Apps Connector, and this corresponding sample, are provided only with the OpenIDM Enterprise build, available on the link:https://backstage.forgerock.com[ForgeRock Backstage, window=\_blank] site. +The Google Apps Connector, and this corresponding sample, are provided only with the OpenIDM Enterprise build, available on the link:https://github.com/OpenIdentityPlatform/OpenICF/releases[GitHub, window=\_blank]. ==== This sample demonstrates the creation of users and groups on an external Google system, using OpenIDM's REST interface. The sample requires that you have a Google Apps account. Obtaining a Google Apps account is described in the link:https://support.google.com/a/answer/53926?hl=en[Google documentation, window=\_blank]. diff --git a/openidm/modules/samples-guide/pages/chap-groovy-samples.adoc b/openidm/modules/samples-guide/pages/chap-groovy-samples.adoc index ff6dd7fb8c..9be2bc173b 100644 --- a/openidm/modules/samples-guide/pages/chap-groovy-samples.adoc +++ b/openidm/modules/samples-guide/pages/chap-groovy-samples.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -28,7 +28,7 @@ OpenIDM 4.5 includes a generic Groovy Connector Toolkit that enables you to run The Groovy Connector Toolkit is not a complete connector, in the traditional sense. Rather, it is a framework within which you must write your own Groovy scripts to address the requirements of your implementation. Specific scripts are provided within these samples, which demonstrate how the Groovy Connector Toolkit can be used. These scripts cannot be used "as is" in your deployment, but are a good starting point on which to base your customization. -To facilitate creating your own scripted connectors with the Groovy Connector Toolkit, OpenIDM provides a scripted connector __bundler__. The first sample in this chapter uses the connector bundler to create a new connector, and its configuration. The connector bundler is described in detail in the link:http://openicf.forgerock.org/doc/bootstrap/dev-guide/index.html#chap-custom-bundler[OpenICF Developers Guide, window=\_blank]. +To facilitate creating your own scripted connectors with the Groovy Connector Toolkit, OpenIDM provides a scripted connector __bundler__. The first sample in this chapter uses the connector bundler to create a new connector, and its configuration. The connector bundler is described in detail in the link:https://github.com/OpenIdentityPlatform/OpenICF/wiki/Developer-Guide[OpenICF Developers Guide, window=\_blank]. [#more-sample3] === Sample 3 - Using the Custom Scripted Connector Bundler to Build a ScriptedSQL Connector @@ -159,7 +159,7 @@ This step generates a Maven project (`pom.xml` file) and a `src` directory that $ cp ../tools/* src/main/resources/script/hrdb/ ---- + -You can customize these scripts before you bundle them, to suit the requirements of your deployment. For more information about writing Groovy scripts to interact with a resource, see the link:http://openicf.forgerock.org/doc/bootstrap/dev-guide/index.html#chap-groovy-connectors[OpenICF Developer's Guide, window=\_blank]. +You can customize these scripts before you bundle them, to suit the requirements of your deployment. For more information about writing Groovy scripts to interact with a resource, see the link:https://github.com/OpenIdentityPlatform/OpenICF/wiki/Developer-Guide[OpenICF Developer's Guide, window=\_blank]. . Use the Maven build tool to build the custom connector, with the configuration and scripts that you provided in the previous steps. + diff --git a/openidm/modules/samples-guide/pages/chap-ldap-samples.adoc b/openidm/modules/samples-guide/pages/chap-ldap-samples.adoc index 2d28691b3c..d22858866e 100644 --- a/openidm/modules/samples-guide/pages/chap-ldap-samples.adoc +++ b/openidm/modules/samples-guide/pages/chap-ldap-samples.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -29,7 +29,7 @@ This chapter walks you through the LDAP samples (those samples labeled 2, 2b, 2c [#more-sample-2] === Sample 2 - LDAP One Way -Sample 2 resembles xref:chap-xml-samples.adoc#more-sample-1["First OpenIDM Sample - Reconciling an XML File Resource"], but in sample 2 OpenIDM is connected to a local LDAP server. The sample has been tested with link:http://www.forgerock.org/opendj.html[OpenDJ, window=\_blank], but should work with any LDAPv3-compliant server. +Sample 2 resembles xref:chap-xml-samples.adoc#more-sample-1["First OpenIDM Sample - Reconciling an XML File Resource"], but in sample 2 OpenIDM is connected to a local LDAP server. The sample has been tested with link:https://github.com/OpenIdentityPlatform/OpenDJ[OpenDJ, window=\_blank], but should work with any LDAPv3-compliant server. Sample 2 demonstrates how OpenIDM can pick up new or changed objects from an external resource. The sample contains only one mapping, from the external LDAP server resource to the OpenIDM repository. The sample therefore does not push any changes made to OpenIDM managed user objects out to the LDAP server. @@ -94,7 +94,7 @@ The following steps provide setup instructions for an OpenDJ server. Adjust thes ==== -. Download OpenDJ from ForgeRock's link:https://forgerock.org/downloads/[download site, window=\_top] and extract the zip archive. +. Download OpenDJ from the link:https://github.com/OpenIdentityPlatform/OpenDJ/releases[GitHub, window=\_top] and extract the zip archive. + The LDIF data for this sample is provided in the file `openidm/samples/sample2/data/Example.ldif`. You will need to import this data during your OpenDJ setup. @@ -1577,7 +1577,7 @@ Although there is only one LDAP server in this example, you must enable __replic ==== -. Download OpenDJ from ForgeRock's link:https://forgerock.org/downloads/[download site, window=\_top] and extract the zip archive. +. Download OpenDJ from the link:https://github.com/OpenIdentityPlatform/OpenDJ/releases[GitHub, window=\_top] and extract the zip archive. . Install OpenDJ, using either the UI or the command-line setup. + @@ -2106,7 +2106,7 @@ The LDIF data for this sample is provided in the file `openidm/samples/multiplep ==== -. Download OpenDJ from ForgeRock's link:https://forgerock.org/downloads/[download site, window=\_top] and extract the zip archive. +. Download OpenDJ from the link:https://github.com/OpenIdentityPlatform/OpenDJ/releases[GitHub, window=\_top] and extract the zip archive. . Install OpenDJ, using either the UI or the command-line setup. + diff --git a/openidm/modules/samples-guide/pages/chap-overview.adoc b/openidm/modules/samples-guide/pages/chap-overview.adoc index f47d41a5ca..9cba91af8d 100644 --- a/openidm/modules/samples-guide/pages/chap-overview.adoc +++ b/openidm/modules/samples-guide/pages/chap-overview.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -104,7 +104,7 @@ This sample uses the Groovy Connector Toolkit to implement a ScriptedREST connec * xref:chap-groovy-samples.adoc#sample-scripted-crest["Using the Groovy Connector Toolkit to Connect to OpenDJ With ScriptedCREST"] + -This sample uses the Groovy Connector Toolkit to create a ScriptedCREST connector, which connects to an OpenDJ instance. The main difference between a CREST-based API and a generic REST API is that the CREST API is inherently recognizable by all ForgeRock products. As such, the sample can leverage CREST resources in the groovy scripts, to create CREST requests. +This sample uses the Groovy Connector Toolkit to create a ScriptedCREST connector, which connects to an OpenDJ instance. The main difference between a CREST-based API and a generic REST API is that the CREST API is inherently recognizable by all Open Identity Platform products. As such, the sample can leverage CREST resources in the groovy scripts, to create CREST requests. xref:chap-powershell-samples.adoc#chap-powershell-samples["Samples That Use the PowerShell Connector Toolkit to Create Scripted Connectors"]:: @@ -125,8 +125,8 @@ This sample illustrates how OpenIDM addresses links from multiple accounts to on xref:chap-trustedfilter-sample.adoc#chap-trustedfilter-sample["The Trusted Servlet Filter Sample"]:: This sample demonstrates how to use a custom servlet filter and the Trusted Request Attribute Authentication Module in OpenIDM. Once configured, OpenIDM can use the servlet filter to authenticate through another service. -xref:chap-fullstack-sample.adoc#chap-fullstack-sample["Full Stack Sample - Using OpenIDM in the ForgeRock Identity Platform"]:: -This sample demonstrates the integration of three ForgeRock products: OpenIDM, OpenDJ, and OpenAM. With this sample, you can see how you can use OpenAM for authentication, for user identities that are maintained with OpenIDM, based on a data store of users in OpenDJ. +xref:chap-fullstack-sample.adoc#chap-fullstack-sample["Full Stack Sample - Using OpenIDM in the Open Identity Platform"]:: +This sample demonstrates the integration of three Open Identity Platform products: OpenIDM, OpenDJ, and OpenAM. With this sample, you can see how you can use OpenAM for authentication, for user identities that are maintained with OpenIDM, based on a data store of users in OpenDJ. xref:chap-workflow-samples.adoc#chap-workflow-samples["Workflow Samples"]:: The workflow sample and use cases demonstrate how OpenIDM uses workflows to provision user accounts. The samples demonstrate the use of the Self-Service UI to enable user self-registration, diff --git a/openidm/modules/samples-guide/pages/chap-salesforce-sample.adoc b/openidm/modules/samples-guide/pages/chap-salesforce-sample.adoc index 5530baf0a7..2ae7f090fd 100644 --- a/openidm/modules/samples-guide/pages/chap-salesforce-sample.adoc +++ b/openidm/modules/samples-guide/pages/chap-salesforce-sample.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -24,11 +24,11 @@ [#chap-salesforce-sample] == Salesforce Sample - Salesforce With the Salesforce Connector -OpenIDM 4.5 provides a Salesforce Connector that enables provisioning, reconciliation, and synchronization with a Salesforce organization. The Salesforce Connector is not an OpenICF connector, but a separate OpenIDM module, based on the ForgeRock Common Resource API. +OpenIDM 4.5 provides a Salesforce Connector that enables provisioning, reconciliation, and synchronization with a Salesforce organization. The Salesforce Connector is not an OpenICF connector, but a separate OpenIDM module, based on the Open Identity Platform Common Resource API. [NOTE] ==== -The Salesforce Connector, and this corresponding sample, are provided only with the OpenIDM Enterprise build, available on the link:https://backstage.forgerock.com[ForgeRock Backstage, window=\_blank] site. +The Salesforce Connector, and this corresponding sample, are provided only with the OpenIDM Enterprise build, available on the link:https://github.com/OpenIdentityPlatform/OpenICF/releases/[GitHub, window=\_blank]. ==== This sample demonstrates the creation and update of users from OpenIDM to Salesforce, and from Salesforce to OpenIDM. You can use either the Admin UI, or the command line to run this sample. Both methods are outlined in the sections that follow. diff --git a/openidm/modules/samples-guide/pages/chap-trustedfilter-sample.adoc b/openidm/modules/samples-guide/pages/chap-trustedfilter-sample.adoc index 80b05fd8e4..5b8d404559 100644 --- a/openidm/modules/samples-guide/pages/chap-trustedfilter-sample.adoc +++ b/openidm/modules/samples-guide/pages/chap-trustedfilter-sample.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -26,7 +26,7 @@ This sample demonstrates how to use a custom servlet filter and the "Trusted Request Attribute Authentication Module" in OpenIDM. Once configured, OpenIDM can use the servlet filter to authenticate through another service. -If you want to set up authentication through OpenAM, refer to xref:chap-fullstack-sample.adoc#chap-fullstack-sample["Full Stack Sample - Using OpenIDM in the ForgeRock Identity Platform"]. +If you want to set up authentication through OpenAM, refer to xref:chap-fullstack-sample.adoc#chap-fullstack-sample["Full Stack Sample - Using OpenIDM in the Open Identity Platform"]. [#trustedfilter-before-you-start] === Before You Start diff --git a/openidm/modules/samples-guide/pages/chap-xml-samples.adoc b/openidm/modules/samples-guide/pages/chap-xml-samples.adoc index d19447a2ae..aba3e56bd7 100644 --- a/openidm/modules/samples-guide/pages/chap-xml-samples.adoc +++ b/openidm/modules/samples-guide/pages/chap-xml-samples.adoc @@ -12,7 +12,7 @@ information: "Portions copyright [year] [name of copyright owner]". Copyright 2017 ForgeRock AS. - Portions Copyright 2024 3A Systems LLC. + Portions Copyright 2024-2025 3A Systems LLC. //// :figure-caption!: @@ -34,7 +34,7 @@ This chapter provides an overview of the first sample and how it is configured. [#about-the-sample] ==== About the XML Sample -OpenIDM connects data objects held between resources by mapping one object to another. To connect to external resources, OpenIDM uses link:http://openicf.forgerock.org[OpenICF, window=\_top] connectors, configured for use with each external resource. +OpenIDM connects data objects held between resources by mapping one object to another. To connect to external resources, OpenIDM uses https://github.com/OpenIdentityPlatform/OpenICF[OpenICF, window=\_top] connectors, configured for use with each external resource. When objects in one external resource change, OpenIDM determines how the changes affect other objects, and can make the changes as necessary. This sample demonstrates how OpenIDM does this by using __reconciliation__. OpenIDM reconciliation compares the objects in one object set to mapped objects in another object set. For a complete explanation of reconciliation and synchronization, see xref:integrators-guide:chap-synchronization.adoc#sync-types["Types of Synchronization"] in the __Integrator's Guide__.