Documente Academic
Documente Profesional
Documente Cultură
Enhanced security is a feature introduced with Acrobats new security model in 9.x. It is also available in the 8.1.7 update. Adobe recommends that you enable enhanced security to prevent unrestricted cross domain access and other behavior and that workflows and client configurations be designed to operate in that context. The following workflows and features interact with enhanced security:
Internet access: Enhanced security prevents unrestricted cross domain access. Such access rights can be granted for trusted content only as described in Specifying privileged locations on page 9 or overridden with Specify trusted URLs via Trust Manager on page 9 Import and export of data and file via FDF: FDF behavior is fundamentally altered when this feature is on. For details, see Consequences for FDF file handling on page 10. Certified document workflows: If a certified document is signed with a certificate thats trusted for an action that enhanced security would normally prevent, that action will be allowed.
These interactions can be complex, so if security is important to you, take time to understand these features and how they interact. Tip: The feature can be configured through the UI, but Administrators have more control and can even lock down the feature via the registry. For an overview, see the Enhanced security quick key on page 13.
Pre-deployment configuration
3. Specify privileged locations for content and domains you trust as described in Specifying privileged locations. 4. Choose OK.
Pre-deployment configuration
Preconfiguration of clients involves customizing the product installer with the Adobe Customization Wizard so that clients behave consistently and adhere to the same policies across the organization. Application level preferences (registry settings and plist preferences) are available for controlling many aspects of the product. For details, see http://www.adobe.com/go/enterprise_deployment. You can use the wizard to customize product installers in the following ways:
Modify application registry and installer tables for any security feature, including enhanced security, digital signatures, and document security. Lock settings so they cannot be altered by users. Install files such as templates, trusted identity lists, and so on.
Figure 2 Customization wizard
Post-deployment configuration
Post deployment methods of configuration include the following:
Pushing registry level changes out using any applicable scripting mechanism. End user/administrator configuration on a per-client basis through the user interface.
Client controls:
Specifying privileged locations Specify trusted URLs via Trust Manager Trusting certificates for privileged network operations Managing cross domain access at the server Enabling cross domain access for specific PDFs
Server controls:
Client controls
Specifying privileged locations
Enhanced security provides a method for specifying locations for trusted content. Privileged locations can be a single file, a directory, or a host. The application maintains two privileged location lists: an administrator list (in HKLM) and a user list (in HKCU). The user list is for the current user only and can be edited via the user interface. The default installation does not specify any privileged locations. The administrator list is created manually or by tuning the installer with the Acrobat Customization Wizard before deployment. This method of trusting content is beneficial for administrators that control clients in closed workflows, that dont own a web service and so cant manage a cross domain policy, who need to grant rights such as silent printing, and who trust the location. For more details, see Enhanced Security in Acrobat and Adobe Reader 9.x. To specify a privileged location through the user interface: 1. Navigate to the enhanced security panel (Figure 1). 2. Set a privileged location by selecting one of the following buttons:
Add File: A file is defined by a path, so its security settings will be invalid if that file is moved. Add Folder Path: Excludes subfolders, but recursivity may be configured via the registry. Add Host: Enter the complete name of the root URL only with no wildcards. For example, www. adobe.com but not www.adobe.com/lc. To specify HTTPS, select Secure Connections Only.
3. Choose OK. Tip: You can make a folder privileged location recursive by configuring the registry as described in Enhanced security on page 2.
Server controls
The document is certified; that is, the first signature in the document is a certification signature. The certification signature is valid. The document recipient has specifically trusted the signers certificate for privileged operations.
Post-deployment, administrators can use an FDF file or an acrobatsecuritysettings file to configure the Trusted Identity Manager for multiple clients. Pre-deployment, an administrator would tune the installer with the Acrobat Customization Wizard. For details about certificates, see Digital Signatures and Rights Management in Acrobat and Adobe Reader. To manually set a certificate's trust level on a client-by-client basis: 1. Choose Advanced (Acrobat) or Document (Adobe Reader) > Manage Trusted Identities. 2. Choose Certificates in the Display drop down list. 3. Select the certificate. 4. Choose Edit Trust. 5. Choose OK twice and close the dialog.
Figure 3 Setting certificate trust
Server controls
Enhanced securitys cross domain restrictions can also be bypassed and managed at the server.
To allow a domain-less, local PDF to access a server, it must be signed either with a certification signature or a reader enabled signature (the hidden signature applied during Reader enablement) and registered in a cross domain policy file. Again, the signature can be one of two types:
A certification signature in a certified document: Best for certified document workflows and when high privileged JavaScript should be permitted. A Reader enabled signature applied by a LiveCycle ES server: PDFs that are granted additional usage rights are signed by the server. Using this fingerprint allows customers with many Reader extended documents to continue accessing the server after enhanced security is enabled without having to change their forms.
The fingerprint for the certificate that was used for the signing is registered in the cross domain file on the server. In effect, the cross domain file on the server is saying files signed with this certificate may access this server. To register the fingerprint, an administrator extracts the SHA-1 hash of the public key from the signing certificate and places it in the cross domain policy file. For more information, see Cross-domain Access and Configuration.
Action
Opening a target PDF Opening a target PDF Opening a target PDF Opening a target PDF Data injection
8.x behavior
PDF opens. No authentication required. PDF opens PDF opens. No authentication required. Blocked Allowed
9.x behavior
No change. Allow via dialog or enable enhanced security and set privileged location. No change. Http hosted FDFs cannot open local files. Allowed if:
Data retuned via a form submit with url#FDF. FDF has no /F or /UF key. cross-domain policy permits it.
Data injection
server
browser
Allowed
Allowed if:
Link to PDF contains #FDF=url. FDF has no /F or UF key. cross domain policy permits it.
Action
Data injection
8.x behavior
Allowed
9.x behavior
Allowed if:
PDF makes EFS POST/GET and FDF sends data in https response to same PDF. cross domain policy permits it.
Varied Any
Varied Any
Allowed Allowed
Allow via dialog or enable enhanced security and set privileged location. Blocked if enhanced security is on and FDF is not in a privileged location.
If the PDF opens in the browser, and the URL to the PDF contains a #FDF=url, then the FDF data specified by that url may be injected into the open PDF if the FDF has no /F key and if the PDF may receive data from the FDF based on the cross domain policy. If the PDF opens in the Acrobat/Reader standalone application and the FDF data comes back in the https response to a POST/GET initiated by the PDF, then the FDF data may be injected into the open PDF if the PDF specified in the FDF is the PDF that made the POST/GET and if the PDF may receive data from the FDF based on the cross domain policy (i.e. * in crossdomain.xml).
You submit data from a PDF in the browser and the URL has #FDF at the end. The FDF that comes back has an /F key pointing to a different PDF which needs to get loaded (everything is happening in the browser). The FDF data gets injected into the second PDF. Same as above, except it all happens in the Acrobat rather than in the browser. In this case, the #FDF at the end of the URL is not needed. The spontaneous FDF case: In the browser, an unsolicited FDF arrives (via a link from an HTML page before and Acrobat is not running yet), and the FDF has an /F key for a PDF that it needs to open and populate. Opening a link of the form http://A.com/file.pdf#FDF=http://B.com/getFDF.
XFDF does not support script injection. XDP is only affected by these rules if the PDF is externally referenced (not embedded).