Configuring User Management

Overview

You can use various settings to customize User Management. Some of these settings are available in administration console and others can be changed only by editing a configuration file.

Enabling single sign-on in AEM forms

AEM forms provides two ways to enable single sign-on (SSO) – HTTP headers and SPNEGO.

When SSO is implemented, the AEM forms user login pages are not required and do not appear if the user is already authenticated through their company portal.

If AEM forms cannot authenticate a user by using either of these methods, the user is redirected to a login page.

Enable SSO using HTTP headers

You can use the Portal Configuration page to enable single sign-on (SSO) between applications and any application that supports conveying the identity over HTTP header. When SSO is implemented, the AEM forms user login pages are not required and do not appear if the user is already authenticated through their company portal.

You can also enable SSO by using SPNEGO. (See Enable SSO using SPNEGO .)

  1. In administration console, click Settings > User Management > Configuration > Configure Portal Attributes.

  2. Select Yes to enable SSO. If you select No, the remaining settings on the page are unavailable.

  3. Set the remaining options on the page as required and click OK:

    • SSO type: (Mandatory) Select HTTP Header to enable SSO using HTTP headers.

    • HTTP header for user’s identifier: (Mandatory) Name of the header whose value contains the logged-in user’s unique identifier. User Management uses this value to find the user in the User Management database. The value obtained from this header should match the unique identifier of the user who is synchronized from the LDAP directory. (See User settings .)

    • Identifier value maps to user’s User ID instead of user’s unique identifier: Maps the user’s unique identifier value to the User ID. Select this option if the user’s unique identifier is a binary value that cannot be easily propagated through HTTP headers (for example, objectGUID if you are synchronizing users from Active Directory).

    • HTTP header for domain: (Not mandatory) Name of the header whose value contains the domain name. Use this setting only if no single HTTP header uniquely identifies the user. Use this setting for cases where multiple domains exist and the unique identifier is unique only within a domain. In this case, specify the header name in this text box and specify domain mapping for the multiple domains in the Domain mapping box. (See Editing and converting existing domains .)

    • Domain mapping: (Mandatory) Specifies mapping for multiple domains in the format header value=domain name .

      For example, consider a situation where the HTTP header for a domain is domainName, and it can have values of domain1, domain2, or domain3. In this case, use domain mapping to map the domainName values to User Management domain names. Each mapping must be on a different line:

      domain1=UMdomain1

      domain2=UMdomain2

      domain3=UMdomain3

Configure allowed referers

For the steps to configure allowed referers, see Configure allowed referers .

Enable SSO using SPNEGO

You can use Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) to enable single sign-on (SSO) when using Active Directory as your LDAP server in a Windows environment. When SSO is enabled, the AEM forms user login pages are not required and do not appear.

You can also enable SSO by using HTTP headers. (See Enable SSO using HTTP headers .)

  1. Decide which domain to use to enable SSO. The AEM forms server and the users must be part of the same Windows domain or trusted domain.

  2. In Active Directory, create a user who represents the AEM forms server. (See Create a user account .) If you are configuring more than one domain to use SPNEGO, ensure that the passwords for each of these users is different. If the passwords are not different, SPNEGO SSO does not work.

  3. Map the service principal name. (See Map a Service Principal Name (SPN) .)

  4. Configure the domain controller. (See Prevent Kerberos integrity-check failures .)

  5. Add or edit an enterprise domain as described in Adding domains or Editing and converting existing domains . When you create or edit the enterprise domain, perform these tasks:

    • Add or edit a directory that contains your Active Directory information.

    • Add LDAP as an authentication provider.

    • Add Kerberos as an authentication provider. Provide the following information on the New or Edit Authentication page for Kerberos:

      • Authentication Provider: Kerberos

      • DNS IP: The DNS IP address of the server where AEM forms is running. You can determine this IP address by running ipconfig/all on the command line.

      • KDC Host: Fully qualified host name or IP address of the Active Directory server used for authentication

      • Service User: The service principal name (SPN) passed to the KtPass tool. In the example used earlier, the service user is HTTP/lcserver.um.lc.com .

      • Service Realm: Domain name for Active Directory. In the example used earlier, the Domain name is UM.LC.COM.

      • Service Password: Service user’s password. In the example used earlier, the service password is password .

      • Enable SPNEGO: Enables the use of SPNEGO for single sign-on (SSO). Select this option.

  6. Configure SPNEGO client browser settings. (See Configuring SPNEGO client browser settings .)

Create a user account

  1. In SPNEGO, register a service as a user in Active Directory on the domain controller to represent AEM forms. On the domain controller, go to Start Menu > Administrative Tools > Active Directory Users And Computers. If Administrative Tools is not in the Start menu, use the Control Panel.

  2. Click the Users folder to display a list of users.

  3. Right-click the user folder and select New > User.

  4. Type the First Name/Last Name and User Logon Name and then click Next. For example, set the following values:

    • First Name : umspnego

    • User Logon Name : spnegodemo

  5. Type a password. For example, set it to password . Ensure that Password Never Expires is selected and no other options are selected.

  6. Click Next and then click Finish.

Map a Service Principal Name (SPN)

  1. Obtain the KtPass utility. This utility is used to map an SPN to a REALM. You can obtain the KtPass utility as part of Windows Server Tool pack or Resource Kit. (See Windows Server 2003 Service Pack 1 Support Tools .)

  2. In a command prompt, run ktpass using the following arguments:

    ktpass -princ HTTP/ host @ REALM -mapuser user

    For example, type the following text:

    ktpass -princ HTTP/lcserver.um.lc.com@UM.LC.COM -mapuser spnegodemo

    The values that you must provide are described as follows:

    host: Fully qualified name of the forms server or any unique URL. In this example, it is set to lcserver.um.lc.com.

    REALM: The Active Directory realm for the domain controller. In this example, it is set to UM.LC.COM. Ensure that you enter the realm in uppercase characters. To determine the realm for Windows 2003, complete the following steps:
    • Right-click My Computer and select Properties

    • Click the Computer Name tab. The Domain Name value is the realm name.

    user: The login name of the user account you created in the previous task. In this example, it is set to spnegodemo.

If you encounter this error:

DsCrackNames returned 0x2 in the name entry for spnegodemo.  
ktpass:failed getting target domain for specified user. 

try specifying the user as spnegodemo@um.lc.com:

ktpass -princ HTTP/lcserver.um.lc.com@UM.LC.COM -mapuser spnegodemo

Prevent Kerberos integrity-check failures

  1. On the domain controller, go to Start Menu > Administrative Tools > Active Directory Users And Computers. If Administrative Tools is not in the Start menu, use the Control Panel.

  2. Click the Users folder to display a list of users.

  3. Right-click the user account that you created in a previous task. In this example, the user account is spnegodemo .

  4. Click Reset Password.

  5. Type and confirm the same password that you typed previously. In this example, it is set to password .

  6. Deselect Change Password At Next Logon and then click OK.

Configuring SPNEGO client browser settings

For SPNEGO-based authentication to work, the client computer must be part of the domain the user account is created in. You must also configure the client browser to allow SPNEGO-based authentication. As well, the site that requires SPNEGO- based authentication must be a trusted site.

If the server is accessed by using the computer name, such as http://lcserver:8080 , no settings are required for Internet Explorer. If you enter a URL that does not contain any dots ("."), Internet Explorer treats the site as a local intranet site. If you are using a fully qualified name for the site, the site must be added as a trusted site.

Configure Internet Explorer 6.x

  1. Go to Tools > Internet Options and click the Security tab.

  2. Click the Local Intranet icon and then click Sites.

  3. Click Advanced and, in the Add This Web Site To The Zone box, type the URL of your forms server. For example, type http://lcserver.um.lc.com

  4. Click OK until all dialog boxes are closed.

  5. Test the configuration by accessing the URL of your AEM forms server. For example, in the browser URL box, type http://lcserver.um.lc.com:8080/um/login?um_no_redirect=true

Configure Mozilla Firefox

  1. In the browser URL box, type about:config

    The about:config - Mozilla Firefox dialog box appears.

  2. In the Filter box, type negotiate

  3. In the list shown, click network.negotiate-auth.trusted-uri and type one of the following commands as appropriate for your environment:

    .um.lc.com - Configures Firefox to allow SPNEGO for any URL that ends with um.lc.com. Ensure that you include the dot (".") at the beginning.

    lcserver.um.lc.com - Configures Firefox to allow SPNEGO for your specific server only. Do not start this value with a dot (".").

  4. Test the configuration by accessing the application. The welcome page for the target application should appear.

Configuring certificate-based authentication

User Management usually performs authentication by using a user name and password. User Management also supports certificate-based authentication, which you can use to authenticate users through Acrobat or to authenticate users programmatically. For details about authenticating users programmatically, see Programming with AEM forms .

To use certificate-based authentication, import a Certificate Authority (CA) certificate that you trust into the Trust Store and then create a certificate mapping.

Import the CA certificate

When importing the certificate, select the Trust for Certificate Authentication and Trust for Identity options, and any other options that you require. For details about importing certificates, see Managing certificates .

Configuring certificate mapping

To enable certificate-based authentication for users, create a certificate mapping. A certificate mapping defines a map between a certificate’s attributes and the attributes of users in a domain. You can map more than one certificate to the same domain.

When you test a certificate, User Management uploads the certificate checks to ensure that it meets the following requirements:

  • The certificate is valid.

  • The Issuer you specified can verify the certificate.

  • The certificate contains the attribute required for mapping.

  • The mapping you specified maps the certificate to only one user in the AEM forms database. Both current and obsolete (deleted) users are checked to determine whether they match the mapping criteria. Therefore, the certificate test fails if more than one user, including obsolete users, has the attribute value being considered.

Note: You cannot edit an existing certificate mapping.

Add a certificate mapping

  1. In administration console, click Settings > User Management > Configuration > Certificate Mapping.

  2. Click New Certificate Mapping and, in the For Issuer list, select the certificate alias as configured in Trust Store Management.

  3. Map one of the certificate’s attributes to a user’s attribute. For example, you can map the certificate’s common name to the user’s login ID.

    If the content of the attribute in the certificate is different from the content in the user’s attribute in the User Management database, you can use a Java Regular Expression (regex) to match the two attributes. For example, if the common names of the certificates are names like Alex Pink (Authentication) and Alex Pink (Signing) and the common name in the User Management database is Alex Pink , you use a regex to extract the required part of the certificate attribute (in this example, Alex Pink .) The regular expression you specify must conform to the Java regex specification.

    You can transform the expression by specifying the order of the groups in the Custom Order box. The custom order is used with the java.util.regex.Matcher.replaceAll() method. The behavior that is seen will correspond to that method's behavior, and the input string (the custom order) must be specified accordingly.

    To test the regex, enter a value in the Test Parameter box and click Test.

    You can use the following characters in the regex:

    • . (any character)

    • * (0 or more occurrences)

    • () (specify the group in brackets)

    • \ (used to escape a regex character to a regular character)

    • $n (used to refer to the nth group)

    Examples of regular expressions:

    • To extract "Alex Pink" from "Alex Pink (Authentication)"

      Regex: (.*) \(Authentication\)

    • To extract "Alex Pink" from "Alex (Authentication) Pink"

      Regex: (.*)\(Authentication\) (.*)

    • To extract "Pink Alex" from "Alex (Authentication) Pink"

      Regex: (.*)\(Authentication\) (.*)

      Custom Order: $2 $1 (return second group, concatenated to first group, captured by whitespace character)

    • To extract "apink@sampleorg.com" from "smtp:apink@sampleorg.com"

      Regex: smtp:(.*)

    For details on using regular expressions, see Java tutorial about regular expressions .

  4. In the For Domain list, select the user’s domain.

  5. To test this configuration, click Browse to upload a sample user certificate, click Test Certificate and, if the configuration is correct, click OK.

Edit an existing certificate mapping

  1. In Administration Console, click Settings > User Management > Configuration.

  2. Click Certificate Mapping.

  3. Select the certificate mapping to edit and edit its configuration. You can update the regular expression and custom order.

  4. To test your changes, click Browse to upload a sample certificate, click Test Certificate, and then click OK.

Delete a certificate mapping

  1. In administration console, click Settings > User Management > Configuration > Certificate Mapping.

  2. Select the check box for the certificate mapping to delete, click Delete, and then click OK.

Configure User Management for an SSL-enabled LDAP server

For synchronization to work properly over LDAPS, the LDAP certificates that the certificate authority (CA) issued must be present in the application server’s Java runtime environment (JRE). Import the certificate into the application server’s JRE cacerts file, which is usually in the [JAVA_HOME] /jre/lib/security/cacerts directory.

  1. Enable SSL on the directory server. For details, see the documentation provided by your directory vendor.

  2. Export a client certificate from the directory server.

  3. Use the keytool program to import the client certificate file into the default Java virtual machine (JVM™) certificate store of the AEM forms application server . The procedure for this task varies, depending on your JVM and client installation paths. For example, if you use BEA WebLogic Server with JDK 1.5, from a command prompt, type this text:

    keytool -import -alias alias -file certificatename -keystore C:\bea\jdk15_04\jre\lib\security\cacerts

  4. When prompted, type the password. (For Java, the default password is changeit .) A message appears stating that the certificate is imported successfully.

  5. When prompted, type Yes to trust the certificate.

  6. Enable SSL in User Management and, when configuring the directory settings, select Yes for the SSL option and change the port setting accordingly. The default port number is 636.

Note: If you experience any problems using SSL, use an LDAP browser to check whether it can access the LDAP system when using SSL. If the LDAP browser cannot get access, your certificate or application server is not configured properly. If the LDAP browser works correctly and you are still experiencing problems, User Management is not configured properly.

Configure advanced system attributes

Use the Configure Advanced System Attributes page to modify certain settings in the configuration file without the need to export, edit, and import the file. (See Importing and exporting the configuration file .)

  1. In administration console, click Settings > User Management > Configuration > Configure Advanced System Attributes.

  2. (Optional) Change any of the following session attributes:

    Session Timeout Limit (Minutes): The amount of time, in minutes, before a user is automatically logged out of the system. By default, AEM forms components such as Workbench time out after two hours, regardless of activity or inactivity, and the user must log in again. Valid values are 1 to 1440 . The default value is 120 (2 hours). This setting updates the SAML/Producer/assertionValidityInMinutes entry key in the configuration file.

    You should not set Session Timeout Limit below 10 minutes as the system may not behave correctly. The recommended value is 10–120 (minutes).

    Assertion Threshold (Seconds): A buffer time to offset delays due to system time differences between AEM forms application server s in a cluster. AEM forms backdates a user's login time by the amount of time (in seconds) specified in this property. Valid values are 0 to 3600 . The default value is 60 . This setting updates the SAML/Producer/assertionThresholdInSeconds entry key in the configuration file.

    Maximum Allowed Renewals of an Assertion: The maximum number of times a user's session can be transparently renewed without requiring a login. Valid values are 0 to 9999 . A value of 0 means that assertions are not renewed. The default value is 10. This setting updates the SAML/Producer/maxAssertionRenewalCount entry key in the configuration file.

  3. (Optional) Change any of the following directory synchronization attributes:

    Synch Statistics Logging: Specifies whether User Management logs detailed statistics during the synchronization process. (See Enable or disable detailed logging during synchronization .)

    Synch Finisher Cron Expression: The interval at which User Management retries failed synchronizations. (See Configure the directory synchronization retry option .)

    Cluster Job Lock Timeout In Minutes: Used in clustered environments. If the synchronization on one node fails and the cluster lock is not released, this value specifies the number of minutes that another node waits before forcibly acquiring the lock. The default value is 15 minutes. Valid values are 1 to 1440 minutes.

  4. (Optional) Change the following attributes and then click OK:

    User Manager Event Auditing: Select this option to enable auditing of directory synchronization events and of authentication events such as success, failure, and lockout. By default, this option is not selected unless you installed a component that requires auditing, such as Rights Management. This setting updates the APSAuditService entry key in the configuration file.

    Auto Creation of Dynamic Group: Enables the automatic creation of dynamic groups based on email domains. (See Create a dynamic group .)

You can also revert to the original User Management settings by clicking Reload.

Configure SAML service provider settings

Security Assertion Markup Language (SAML) is one of the options that you can select when configuring authorization for an enterprise or hybrid domain. SAML is primarily used to support SSO across multiple domains. When SAML is configured as your authentication provider, users log in and authenticate to AEM forms via a specified third-party identity provider (IDP).

For an explanation of SAML, see Security Assertion Markup Language (SAML) V2.0 Technical Overview .

  1. In administration console, click Settings > User Management > Configuration > SAML Service Provider Settings.

  2. In the Service Provider Entity ID box, type a unique ID to use as an identifier for the AEM forms service provider implementation. You also specify this unique ID when configuring your IDP (for example, um.lc.com .) You can also use the URL that is used to access AEM forms (for example, http://AEMformsserver ).

  3. In the Service Provider Base URL box, type the base URL for your forms server (for example, http://AEMformsserver:8080 ).

  4. (Optional) To enable AEM forms to send signed authentication requests to the IDP, perform the following tasks:

    • Use Trust Manager to import a credential in PKCS #12 format with Document Signing Credential selected as the Trust Store Type. (See Managing local credentials .)

    • In the Service Provider Credential Key Alias list, select the alias you assigned to the credential in Trust Store.

    • Click Export to save the URL contents to a file and then import that file into your IDP.

  5. (Optional) In the Service Provider Name ID Policy list, select the name format that the IDP uses to identify the user in a SAML assertion. The options are Unspecified, Email, X509 Subject Name, Kerberos Principal, Entity, Persistent, Transient, or Windows Domain Qualified Name.

    Note: Name formats are not case-sensitive.
  6. (Optional) Select Enable Authentication Prompt For Local Users. When this option is selected, users will see two links:

    • a link to the login page of the third-party SAML identity provider, where users who belong to an Enterprise domain can authenticate.

    • a link to the AEM forms login page, where users who belong to a Local domain can authenticate.

    When this option is not selected, users will be taken directly to the login page of the third-party SAML identity provider, where users who belong to an Enterprise domain can authenticate.

  7. (Optional) Select Enable Artifact Binding to enable artifact binding support. By default, POST binding is used with SAML. But if you have configured Artifact Binding, select this option. When this option is selected, the actual user assertion is not passed through the Browser request. Instead, a pointer to the assertion is passed and the assertion is retrieved using a backend web service call.

  8. (Optional) Select Enable Re-Direct Binding to support SAML bindings that use redirects.

  9. (Optional) In Custom Properties, specify additional properties. The additional properties are name=value pairs separated by new lines.

    • You can configure AEM forms to issue a SAML assertion for a validity period that matches the validity period of a third-party assertion. To honor the third-party SAML assertion timeout, add the following line in Custom Properties:

      saml.sp.honour.idp.assertion.expiry=true
    • Add the following custom property for using RelayState to determine the URL where the user will be redirected after successful authentication.

      saml.sp.use.relaystate=true
    • Add the following custom property to configure the URL for the custom Java Server Pages (JSP), which will be used to render the registered list of identity providers. If you have not deployed a custom web application, it will use the default User Management page to render the list.
      saml.sp.discovery.url=/custom/custom.jsp
  10. Click Save.

Importing and exporting the configuration file

Use the Manual Configuration page to download a copy of the configuration settings in XML format. The settings in this file control all server preferences. You can then edit the file and upload it back to the server. You can also use the file to configure another AEM forms product instance.

To avoid security risks, the bind password value for the directory server is not included in an exported configuration file. Update the password in the XML file before you import the file to a new system.

Important: Importing the configuration file reconfigures AEM forms based on the information in the file. Only a system administrator or a professional services consultant who is familiar with the AEM forms product and XML should consider modifying the configuration file. They may need to edit the configuration file, for example, to reconfigure a corrupted setting.

Export the configuration information

  1. In Administration Console, click Settings > User Management > Configuration > Import And Export Configuration Files.

  2. Click Export. If you are using Microsoft Internet Explorer, you are prompted to specify a location to save the file. If you are using Firefox, the file is saved on your desktop.

Import the configuration information

  1. In Administration Console, click Settings > User Management > Configuration > Import And Export Configuration Files.

  2. Click Browse to find the configuration file, click Import, and then click OK.

Configure the LDAP bind password

To avoid security risks, the bind password field in the exported configuration file (config.xml) is not configured. Before you import the configuration file into another system, ensure that you configure this password. This password overrides an existing password that is stored in the database. A null password does not override an existing non-null password value.

  1. In administration console, click Settings > User Management > Configuration > Import And Export Configuration Files.

  2. To export the current configuration setting to a file, click Export and save the configuration file in another location.

  3. In the file, locate the Domains > [Your domain name] > DirectoryConfigs > LDAPGroupConfig node. Here is an example:

    <node name="LDAPGroupConfig"> 
        <map> 
            <entry key="bindanonymously" value="false" />  
            <entry key="basedn" value="dc=corp,dc=adobe,dc=com" />  
            <entry key="batchSize" value="200" />  
            <entry key="binduser" value="cn=Directory Manager" />  
            <entry key="bindpassword" value="" /> 
        </map>

    Type a value for bindpassword and save your changes.

  4. In the file, locate the Domains > [Your domain name] > DirectoryConfigs > LDAPGroupConfig > LDAPUserConfig node. Here is an example:

    <node name="LDAPUserConfig"> 
        <map> 
            <entry key="bindanonymously" value="false" />  
            <entry key="batchSize" value="200" />  
            <entry key="basedn" value="dc=corp,dc=adobe,dc=com" />  
            <entry key="bindpassword" value="" /> 
            <entry key="binduser" value="cn=Directory Manager" />  
        </map>

    Type a value for bindpassword and save your changes.

  5. To import the updated file, in User Management, click Configuration > Import And Export Configuration Files.

  6. Click Browse to find the file, click Import, and then click OK.

Change the order of evaluation for authentication

If you configured multiple authentication providers, you can change the order in which AEM forms evaluates them for authentication. The order of the authentication providers that are listed in the config.xml file determines the order of evaluation for authentication.

  1. In administration console, click Settings > User Management > Configuration > Import And Export Configuration Files.

  2. To export the current configuration setting to a file, click Export and save the configuration file in another location.

  3. Find the following node in the file:

    <node name="AuthSchemes"> 
        <map />  
            <node name="CertificateAuth"> 
                <map> 
                    <entry key="order" value="3" />  
                    <entry key="name" value="edc.server.auth.scheme.certificate" />  
                </map> 
        </node> 
        <node name="Kerberos"> 
            <map> 
                <entry key="kerberosSPN" value="defaultSPN" />  
                <entry key="order" value="1" />  
                <entry key="name" value="edc.server.auth.scheme.kerberos" />  
            </map> 
    </node>

    In <entry key="order" value="3" /> , edit the value for each node to set the order of the authentication evaluation.

  4. To import the updated file, in User Management, click Configuration > Import And Export Configuration Files.

  5. Click Browse to find the file, click Import, and then click OK.

Configure AEM forms to prefetch domain information

Users may experience a slower response time if they belong to many groups (for example, 500 or more) or if the groups are nested deeply (for example, 30 levels). If you are experiencing this problem, you can configure AEM forms to prefetch information from certain domains.

  1. In administration console, click Settings > User Management > Configuration > Import And Export Configuration Files.

  2. To export the current configuration setting to a file, click Export and save the configuration file in another location.

  3. Add the following node (marked in bold):

    <node name="UM"> 
    <map/>  
    <node name="PrincipalCache"> 
        <map> 
            <entry key="principalCacheSize" value="1000"/> 
            <entry key="principalCacheBatchFetchSize" value="10"/> 
            <entry key="rebuildCacheAfterSync" value="true /> 
            <entry key="enableFullPrefetch" value="false"/> 
            <entry key="principalCacheDomains" value="Domain_Name1/Domain_Name2/Domain_Name3"/> 
        <map> 
    </node> 
    <node name="APSAuditService">

    In this example, multiple domains are configured for prefetch. The domain names are separated by a "/". This is shown in the example above with Domain_Name1 , Domain_Name2 , and Domain_Name3 .

  4. To import the updated file, in User Management, click Configuration > Import And Export Configuration Files.

  5. Click Browse to find the file, click Import, and then click OK.

Preventing CSRF attacks

How CSRF attacks work

Cross-site request forgery (CSRF) is a web site vulnerability where a valid user’s browser is used to send a malicious request, possibly via an iFrame. Because the browser sends cookies on a domain basis, if the user is currently logged in to an application, the user’s data may be compromised.

For example, consider a scenario where you are logged in to administration console in a browser. You receive an email message containing a link. You click the link, which opens a new tab in your browser. The page that you opened contains a hidden iFrame that makes a malicious request to the forms server using the cookie from your authenticated AEM forms session. Because User Management receives a valid cookie, it passes the request.

CSRF-related terms

Referer:
The address of the source page from which a request is coming. For example, a web page on site1.com contains a link to site2.com. Clicking the link posts a request to site2.com. The referer of this request is site1.com because the request is made from a page whose source is site1.com.

Whitelisted URIs:
URIs identify resources on the forms server that are being requested, for example, /adminui or /contentspace. Some resources may allow a request to enter the application from external sites. These resources are considered whitelisted URIs. The forms server never performs a referer check from whitelisted URIs.

Null referer:
When you open a new browser window or tab, then type an address and press Enter, the referer is null. The request is entirely new and not originating from a parent web page; therefore, there is no referer for the request. The forms server can receive a null referer from:
  • requests made on SOAP or REST endpoints from Acrobat

  • any desktop client making an HTTP request on a AEM forms SOAP or REST endpoint

  • when a new browser window is opened and the URL for any AEM forms web application login page is entered

Allow a null referer on SOAP and REST endpoints. Also allow a null referer on all URI login pages such as /adminui and /contentspace and their corresponding mapped resources. For example, the mapped servlet for /contentspace is /contentspace/faces/jsp/login.jsp, which should be a null referer exception. This exception is required only if you enable GET filtering for your web application. Your applications can specify whether to allow null referers. (See “Protecting from Cross-Site Request Forgery attacks” in Hardening and Security for AEM forms .)

Allowed Referer Exception:
Allowed Referer Exception is a sublist of the list of allowed referers, from which requests are blocked. Allowed Refer Exceptions are particular to a web application. If a subset of the Allowed Referers should not be allowed to invoke a particular web application, you can blacklist the referers via Allowed Referer Exceptions. Allowed Referer Exceptions are specified in the web.xml file for your application. (See “Protecting from Cross-Site Request Forgery attacks” in Hardening and Security for AEM forms .)

How allowed referers work

AEM forms provides referer filtering, which can help prevent CSRF attacks. Here is how referer filtering works:
  1. The forms server checks the HTTP method used for invocation:
    • If it is POST, the forms server performs the referer header check.

    • If it is GET, the forms server bypasses the referer check, unless CSRF_CHECK_GETS is set to true, in which case it performs the referer header check. CSRF_CHECK_GETS is specified in the web.xml file for your application. (See “Protecting from Cross-Site Request Forgery attacks” in Hardening and Security for AEM forms .)

  2. The forms server checks whether the requested URI is whitelisted:

    • If the URI is whitelisted, the server passes the request.

    • If the requested URI is not whitelisted, the server retrieves the referer of the request.

  3. If there is a referer in the request, the server checks whether it is an allowed referer. If it is allowed, the server checks for a referer exception:
    • If it is an exception, the request is blocked.

    • If it is not an exception, the request is passed.

  4. If there is no referer in the request, the server checks whether a null referer is allowed.

    • If a null referer is allowed, the request is passed.

    • If a null referer is not allowed, the server checks whether the requested URI is an exception for null referer and handles the request accordingly.

Configure allowed referers

When you run Configuration Manager, the default host and IP address or the forms server are added to the Allowed Referer list. You can edit this list in administration console.

  1. In administration console, click Settings > User Management > Configuration > Configure Allowed Referer URL’s. The Allowed Referer list appears at the bottom of the page.

  2. To add an allowed referer:

    • Type a host name or IP address in the Allowed Referers box. To add more than one allowed referer at a time, type each host name or IP address on a new line.

    • In the HTTP Port and HTTPS Ports boxes, specify which ports to allow for HTTP, HTTPS, or both. If you leave those boxes empty, the default ports (port 80 for HTTP and port 443 for HTTPS) are used. If you enter 0 (zero) in the boxes, all ports on that server are enabled. You can also enter a specific port number to enable only that port.

    • Click Add.

  3. To remove entry from the Allowed Referer list, select the item from the list and click Delete.

    If the Allowed Referer List is empty, the CSRF feature stops working and the system becomes insecure.

  4. After changing the Allowed Referer list, restart the AEM forms server.

// Ethnio survey code removed