Update documentation & fix issues (#831)

Author: maximthomas

openam-documentation/openam-doc-source/src/main/asciidoc/admin-guide/chap-agents.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!:
@@ -30,7 +30,7 @@ Policy agents can have local configurations where they are installed. Typically,
 [#gateway-or-policy-agent]
 === OpenIG or Policy Agent?
 
-OpenAM supports both link:http://openig.forgerock.org/[OpenIG, window=\_blank] and also a variety of policy agents. OpenIG and the policy agents can both enforce policy, redirecting users to authenticate when necessary, and controlling access to protected resources. OpenIG runs as a self-contained reverse proxy located between the users and the protected applications. Policy agents are installed into the servers where applications run, intercepting requests in that context.
+OpenAM supports both link:https://github.com/OpenIdentityPlatform/OpenIG[OpenIG, window=\_blank] and also a variety of policy agents. OpenIG and the policy agents can both enforce policy, redirecting users to authenticate when necessary, and controlling access to protected resources. OpenIG runs as a self-contained reverse proxy located between the users and the protected applications. Policy agents are installed into the servers where applications run, intercepting requests in that context.
 
 Use OpenIG to protect access to applications not suited for a policy agent. Not all web servers and Java EE applications have policy agents. Not all operating systems work with policy agents.
 
@@ -1612,7 +1612,7 @@ This section covers version 2.2 policy agent properties. Version 2.2 agents stor
 
 [WARNING]
 ====
-ForgeRock no longer supports 2.2 policy agents. Documentation exists only for legacy systems. Do not use 2.2 policy agents for new deployments.
+Open Identity Platform Community no longer supports 2.2 policy agents. Documentation exists only for legacy systems. Do not use 2.2 policy agents for new deployments.
 ====
 After creating the agent profile, you access agent properties in the OpenAM console under Realms > __Realm Name__ > Agents > 2.2 Agents > __Agent Name__. Properties include:
 --

openam-documentation/openam-doc-source/src/main/asciidoc/admin-guide/chap-audit-logging.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 @@ Audit logs gather operational information about events occurring within an OpenA
 
 This chapter describes the new, common REST-based Audit Logging Service available in OpenAM 13.5.2-15. OpenAM 13.5.2-15 also supports a legacy Logging Service, based on a Java SDK and available in OpenAM versions prior to OpenAM 13.5.2-15. The legacy Logging Service will be deprecated in a future release of OpenAM.
 
-The Audit Logging Service uses a structured message format that adheres to a consistent and documented log structure common across the ForgeRock stack, including OpenAM, OpenIDM, OpenDJ, and OpenIG.
+The Audit Logging Service uses a structured message format that adheres to a consistent and documented log structure common across the Open Identity Platform stack, including OpenAM, OpenIDM, OpenDJ, and OpenIG.
 
 [IMPORTANT]
 ====
@@ -39,7 +39,7 @@ By default, OpenDJ 3.0 does not have audit logging enabled; thus, administrators
 [#about-audit-logs]
 === About the Audit Logging Service
 
-OpenAM writes log messages generated from audit events triggered by its instances, policy agents, the `ssoadm` tool, and connected ForgeRock stack implementations.
+OpenAM writes log messages generated from audit events triggered by its instances, policy agents, the `ssoadm` tool, and connected Open Identity Platform stack implementations.
 
 OpenAM's Audit Logging Service provides a versatile and rich feature set as follows:
 
@@ -483,7 +483,7 @@ Default: 1800 (seconds)
 
 OpenAM supports audit logging to Elasticsearch 5.0. When you store OpenAM's audit logs in an Elasticsearch data store, you can use Kibana to perform data discovery and visualization on your logs.
 
-You can experiment with an Elasticsearch audit handler without enabling any Elasticsearch security features. However, for a more secure deployment, ForgeRock recommends that you use Elasticsearch Shield to require authentication to Elasticshield. Depending on your network topology, you might also want to configure SSL for Elasticsearch Shield.
+You can experiment with an Elasticsearch audit handler without enabling any Elasticsearch security features. However, for a more secure deployment, Open Identity Platform Community recommends that you use Elasticsearch Shield to require authentication to Elasticshield. Depending on your network topology, you might also want to configure SSL for Elasticsearch Shield.
 
 Before configuring the Elasticsearch audit event handler, you must configure an Elasticsearch index with OpenAM's audit schema:
 
@@ -797,7 +797,7 @@ The purpose of this feature is to allow customers to perform two kinds of filter
 [#configuring-trusttransactionheader-system-property]
 === Configuring the Trust Transaction Header System Property
 
-OpenAM supports the propagation of the transaction ID across the ForgeRock platform, such as from OpenDJ or OpenIDM to OpenAM, using the HTTP header `X-ForgeRock-TransactionId`. The `X-ForgeRock-TransactionId` header is automatically set in all outgoing HTTP calls from one ForgeRock product to another. Customers can also set this header themselves from their own applications or scripts calling into the ForgeRock platform.
+OpenAM supports the propagation of the transaction ID across the Open Identity Platform, such as from OpenDJ or OpenIDM to OpenAM, using the HTTP header `X-ForgeRock-TransactionId`. The `X-ForgeRock-TransactionId` header is automatically set in all outgoing HTTP calls from one ForgeRock product to another. Customers can also set this header themselves from their own applications or scripts calling into the ForgeRock platform.
 
 You can set a new property `org.forgerock.http.TrustTransactionHeader` to `true`, which will trust any incoming `X-ForgeRock-TransactionId` headers. By default, the `org.forgerock.http.TrustTransactionHeader` is set to `false`, so that a malicious actor cannot flood the system with requests using the same transaction ID header to hide their tracks.