Admin Console Settings

When you install Community Manager, some additional settings become available in the Configuration section of Policy Manager. This document provides information you can use to customize these settings for your installation.

Note that although the configuration settings in Community Manager apply to the developer portal, the Admin Console settings apply only to the container, not the entire deployment. In some cases, configuration settings might need to be set differently in specific containers based on factors such as the Community Manager features installed in the container and the container's network access.

The Site Admin for the developer portal might not have access to the Admin Console for the container; if you do not have access, work with the deployment operator and/or Administrator to change the configuration properties as needed.

For general information regarding the SOA Software Administration Console, please refer to the applicable online help.

For information about the configuration settings defined by the Community Manager Site Admin within the developer portal, refer to the Site Admin help, Config section.

Table of Contents

  1. How do I get to the Community Manager Configuration Settings in the SOA Software Administration Console?
  2. What are the Community Manager Configuration Settings in the SOA Software Administration Console?

How do I get to the Community Manager Configuration Settings in the SOA Software Administration Console?

To modify the Community Manager settings in the Admin Console, you must be a Policy Manager Site Admin.

To navigate to the CM configuration settings:
  1. Log in to the SOA Software Administration Console.
  2. Click the Configuration tab.
  3. On the left, under Configuration Categories, scroll down to find the applicable category.
  4. Change the values as needed, and then click Apply Changes.

Back to top

What are the Community Manager Configuration Settings in the SOA Software Administration Console?

The configuration settings allow you to set values for the specific container. They are in these categories:

Some of the settings are explained below.

When the request comes in, the API Security Policy validates whether the request has the correct security values. To do that, it must retrieve the app's shared secret or certificate. This policy caches the app's shared secret, app certificate, or both; these configuration properties manage the caching of these values.
Indicates how long an app's shared secret, certificate, or both are stored in the cache, once they are retrieved, if they are not used again. When the expiration time has passed, if the values were not used again, they are removed from the local cache.
Default: 86400000 milliseconds (1 day)
Indicates how long an app's shared secret, certificate, or both are stored in the cache without checking whether the cached data is out of date.
If values are used, they are kept in the cache, but the refresh time governs how often the platform checks to make sure the cached values are still current.
Default: 900000 milliseconds (15 minutes)


Because the AtmoAuthToken cookie includes a lot of information about the user, in some cases the auth token is long, and could potentially cause requests to fail if the server has a limitation on HTTP header length. For this reason, container configuration properties include Auth Token Max Length. When the auth token would be greater than the max length, the platform creates a mini auth token, and saves the full auth token in the database.
This causes a slight additional overhead on performance, therefore it is configurable.
Default: 512k
Allows security configuration changes to be implemented immediately.
Note: The configuration only works when there is no load balancing set up, since the in-memory configuration update is limited to the container instance, not all the instances in the cluster.
Default: false
Allows you to specify values for the user-agent request header that will be allowed to use POST, PUT, and DELETE operations without providing the custom X-Csrf-Token_fedmemberID header. If one of the specified values is in the user-agent request header, Community Manager does not check for the custom header. Separate multiple values with commas; use wildcard if needed. Example: Mozilla* allows all Mozilla Firefox versions.
Default: No default.
Indicates whether it is an enterprise install (true) or a multi-tenant install (false).
In an enterprise install, the user identity and the user profile name are the same; for example, johnsmith.
In a multi-tenant install, the user identity name is formatted as tenantid-username, for example, acmepaymentscorp-johnsmith.
This helps ensure that if the same user has an account on two different tenants there is no conflict and each account is treated separately.
Allows you to set up one or more roles that cannot use this implementation. For example, you might want to dedicate a special container for administrator use only.
Use comma separators as needed. For example:
Site Administrator,Business Administrator,ApiAdmin, BusinessAdmin,SiteAdmin
For more information, see How do I exclude specific roles from platform access? (Site Admin help for managing users).
Used in scenarios where there is a federation with a proxy in front of Community Manager. This setting is valid for legacy purposes only.


Allows you to use the X-Frame-Options HTTP response header to indicate whether the browser is allowed to render the Community Manager developer portal URL in a <frame> or <iframe> which could be embedded in another site.
If this entry is set to Deny, prevention is turned on.
This preventive measure helps protect the platform against a clickjacking attack where the content would be embedded in another site.
Default: No value set.


Allows you to specify one or more hosts that are allowed for forward proxy. Any other hosts are rejected as unauthorized, with a message that the host is not allowed. To allow all, use the asterisk wildcard (*). To allow multiple hosts, use a comma separator; for example, host1,host2,host3.
Note: This setting applies only to the current container. If you want to set the same value for all containers that are running Community Manager, there is a database script you can run to change the setting in the database. For help, contact Technical Support.
Default value: * (allow all).


Indicates settings applicable when the platform is used as an OAuth Resource Server.

Note: These caching properties are node-specific. In a load balancing environment, the properties must be applied individually to each container. Each Network Director has a local cache, and the cache settings apply to that container property only. You must change the property on each Network Director container. The same property is applicable to all containers but must be manually applied on each container.

Maximum cache size for OAuth Resource Server grants. See note above re cache settings.
Expiration period for OAuth Resource Server grants.
Refresh time for OAuth Resource Server grants: the length of time for which a refresh token is valid.


Indicates the allowable clock skew value, in seconds, for JSON web key tokens.
When asymmetric signature keys are used to sign ID tokens, the keys are rolled over by periodically adding new keys to the JWK Set. By default, All JSON Web Keys that the developer portal's OpenID Connect provider create will have a validity of 24 hours (86400 seconds). This setting allows you to modify the validity period.
Indicates the maximum allowable length of a redirect URL when the platform is used as an OAuth Resource Server.
Indicates the RSA JSON Web Key size when the platform is used as an OAuth Resource Server.

Back to top