FAQ: General AM

Last updated Jan 16, 2023

The purpose of this FAQ is to provide answers to commonly asked general questions regarding AM.

1 reader recommends this article

Frequently asked questions

Q. How does AM protect from Clickjacking?
Q. How do I set Content-Security-Policy headers in AM?
Q. Can I remove the YUI 2.3.0 library (/am/assets/lib/yui)?
Q. Does AM support syslog for audit logging?
Q. Why are the timestamps displayed in the audit logs and debug logs different?
Q. Can I change the delimiter used in the log files?
Q. Can I rotate the debug log files?
Q. Can I rotate the audit log files?
Q. Is Elasticsearch 6 supported for audit logging?
Q. Do translation memory files exist for AM locales?

Q. How does AM protect from Clickjacking?

A. AM protects your deployments from clickjacking as follows:

The X-Frame-Options header is set to SAMEORIGIN to prevent the page from being framed by a malicious site. Per RFC 7034, "A browser receiving content with this header field MUST NOT display this content in any frame from a page of different origin than the content itself."
A /* url-pattern is included in the list of protected resources.

The relevant snippets in the web.xml file (located in the /path/to/tomcat/webapps/am/WEB-INF directory) are:

<filter> <filter-name>SecurityHeaders</filter-name> <filter-class>org.forgerock.openam.headers.SetHeadersFilter</filter-class> <init-param> <param-name>X-Frame-Options</param-name> <param-value>SAMEORIGIN</param-value> </init-param> </filter> .... <filter-mapping> <filter-name>SecurityHeaders</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

Q. How do I set Content-Security-Policy (CSP) headers in AM?

A. You can define Content-Security-Policy headers in AM by updating the web.xml file (located in the /path/to/tomcat/webapps/am/WEB-INF directory). Content-Security-Policy headers can be used to reduce XSS risks.

For example, you could add something similar to this to the web.xml file:

<filter> <filter-name>ContentSecurityPolicyFilter</filter-name> <filter-class>org.forgerock.openam.headers.SetHeadersFilter</filter-class> <init-param> <param-name>Content-Security-Policy</param-name> <param-value>frame-ancestors https://frame-parent.example.org</param-value> </init-param> <init-param> <param-name>excludes</param-name> <param-value>/connect/checkSession</param-value> </init-param> </filter>

See Content Security Policy Reference for further information and examples.

Q. Can I remove the YUI 2.3.0 library (/am/assets/lib/yui)?

A. Yes you can. This library is only used by the configurator during the installation; you can remove it post-install as it is not used.

You may see this being used in URLs such as:

https://am.example.com:8443/am/assets/lib/yui/animation/animation-min.js https://am.example.com:8443/am/assets/lib/yui/button/button-beta-min.js ...

Q. Does AM support syslog for audit logging?

A. Yes syslog for audit logs is supported. See Configure Syslog audit event handlers for further information.

The audit logs (CAUD) are compliant with RFC 5424; you should ensure syslog is configured to log using this format (STRUCTURED-DATA). For example, if you are using Rsyslog, you would need to add the following to your template:

RSYSLOG_SyslogProtocol23Format

See RSYSLOG - RFC5424 and OPENAM-8436 (Syslog handler always sends useless information during XUI operations) for further information.

Q. Why are the timestamps displayed in the audit logs and debug logs different?

A. The timestamps used in the logs are different as the logs serve different purposes:

Audit logs use timestamps in UTC format (for example, 2022-03-09T08:48:00.160Z); UTC is a unified standard that is not affected by daylight saving time changes. The format used in audit logs is not configurable since UTC provides the consistency needed for auditing when AM servers are deployed globally across different timezones.
Debug logs use the system time since they are primarily used for diagnosing issues where local timestamps are needed in troubleshooting analysis. This does mean that timestamps will be different if your system uses a format other than UTC.

As of AM 7.1.2, the timezone is indicated in the debug logs to make it clearer when there are multiple timezones involved. You will either see timestamps in UTC format if applicable (for example, 2022-03-09T08:48:00.160Z) or shown as the number of hours offset from UTC (for example, 2022-03-09T04:48:00.160-04:00 for EST).

Q. Can I change the delimiter used in the log files?

A. No, AM uses a tab space as the delimiter in log files and there is no way of changing this.

You could log to a database as this provides greater flexibility or you could use a custom formatter to customize the output of the log files. The ELF formatter is currently used and its source can be found here to give you some background on what it does.

Q. Can I rotate the debug log files?

A. Yes, you can rotate the debug log files (typically located in the /path/to/am/var/debug directory (AM 7 and later) or the /path/to/am/debug directory (AM 6.x)) as detailed in Rotate debug logs (AM 7 and later) or How do I rotate AM (All versions) debug logs?

You can also clear these files if required: How do I clear debug logs in AM (All versions)?

Q. Can I rotate the audit log files?

A. Audit log files (typically located in the /path/to/am/var/audit directory (AM 7 and later) or the /path/to/am/log directory (AM 6.x)) can be rotated.

Audit Logging Service

The following JSON files are generated by the Audit Logging Service (by default this is the Global JSON Handler):

config.audit.json
activity.audit.json
authentication.audit.json
access.audit.json

Configuration for this handler can be found in: Configure > Global Services > Audit Logging > Secondary Configurations > Edit the Global JSON Handler. See Configure JSON audit event handlers for further information on configuring the handler, including file rotation, logs files etc.

See How do I configure audit logging via ssoadm in AM (All versions)? for further information on configuring these services using ssoadm.

Q. Is Elasticsearch 6 supported for audit logging?

A. No, Elasticsearch 6.x is not supported for audit logging because 6.0 introduced a breaking change regarding how indices are handled (you can now only have one _type per index).

Per the Elasticsearch documentation (Removal of mapping types):

Indices created in Elasticsearch 6.0.0 or later may only contain a single mapping type. Indices created in 5.x with multiple mapping types will continue to function as before in Elasticsearch 6.x. Mapping types will be completely removed in Elasticsearch 7.0.0.

A possible workaround is to create the index in Elasticsearch 5 and then upgrade to Elasticsearch 6.

The Elasticsearch audit handler is deprecated in AM 7.1.

Q. Do translation memory files exist for AM locales?

A. No, we do not have any translation files for AM.

Related Training

ForgeRock Access Management Deep Dive (AM-410)