Crossdomain Policy File in SAP Web Application Server

Consuming web services in flex from a SAP system can lead to flash player security sandbox violations. Most of the time you have the flex application on one domain and the
R/3 system on another. This results in the following error being thrown: Request for resource at * by requestor from * file is denied due to lack of policy file
permissions.

Starting with flash 7, direct cross-domain data loading was possible, but only authorized by policy files – crossdomain.xml files. With each flash player version, the default policy rules became more and more restrictive ending in current flash player version 10 that has a default meta-policy of master-only. This means that even with loadPolicyFile (allowing you to load a crossdomain.xml from any location) you still need to have a master policy file located directly under root /crossdomain.xml in the domain you’re trying to access data from. So no matter the scenario a root /crossdomain.xml is required.

Enabling /crossdomain.xml in an R/3 system.
There are two possible approaches to this:

  1. Via transaction SICF change the default host’s default service to point to a BSP application in which you’ve added the crossdomain.xml file as a mime service
  2. Configure ICM (Internet Communication Manager) to handle it since it sits between the outside world making HTTP, HTTPS, SMTP requests and the SAP System

Method 1 – BSP Application.
I’ve found this method described in a few places, including the sap sdn forums. In my opinion, it has a major drawback as it overrides some settings with new ones (changing default service part).
Nevertheless, here it goes:
1) In transaction SE80 Object Navigator, select a package you own (like the default $TMP_BCUSER one), right click -> create -> BSP Library -> BSP Application
2) Select the BSP Application, right click -> create -> MIME Object -> Import -> select the crossdomain.xml file. activate the application.
3) Execute transaction SIC with default settings, double click the default_host, go to the Default Service tab, and the select the newly created application from default_host/sap/bc/bsp/sap/.  Save changes.
4) Go back and reactivate default_host.

Method 2 – File Access Handler.
I find this method a lot less invasive, but nobody seems to mention it. It makes use of ICM  responsible for processing HTTP requests. One of the ICM http handlers is the file access handler. This one is responsible for returning files from the file system following the rules from parameter icm/HTTP/file_access_xx. In a way think of this as configuring httpd.conf from an apache web server via the RewriteRule.

An example of such a rule can be:
icm/HTTP/file_access_0 = PREFIX=/crossdomain.xml, DOCROOT=C:\usr\sap\NSP\DVEBMGS00\data\icmanroot\crossdomain.xml
PREFIX indicates for what path under the current host and port the handler should trigger. DOCROOT indicates what file(s) should be returned. Usually both PREFIX and DOCROOT contain directory values but in our situation we need to explicitly define PREFIX as /crossdomain.xml. If we define it as / means all requests to current host and port will be handled by the file access handler and we certainly don’t want that, the web services we’re trying to load in the first place will not work. Instead of being handled by the SAP system (default action for every request), the web services will be handled by a http handler resulting in an error.

Detailed steps to achieve this:
1) In transaction SMICM, Goto -> Parameters -> Display. Look for any file_access_ references you may have so that we don’t override existing entries. If you have file_access_0, the new entry will be file_access_1 and so on. If you don’t have such an entry, the new entry will be file_access_0.
2) Select transaction RZ10, select the instance profile from the available dropdown menu. If you don’t have any entries in the dropdown Utilities ->Import profiles -> Of active servers. Select “Extended Maintenance” under Edit Profile and click change.
3) Click create new parameter and add the new file_access_xx entry. Example: parameter name is file_access_0, parameter value is PREFIX=/crossdomain.xml, DOCROOT=C:\usr\sap\NSP\DVEBMGS00\data\icmanroot\crossdomain.xml
4) Save the current profile and click yes when asked if you want it activated as well.
5) Restart the SAP instance.

2 thoughts on “Crossdomain Policy File in SAP Web Application Server”

  1. Hey there,
    thank you for this helpful post! I have a question concerning the second method, the file access handler: As I add the xml file from my local harddrive, will everybody who triggers the cross-client data load make use of it, so that the problem does not occur anymore; or will only I myself use it?
    Thank you!

  2. Great post! It’s a shame that SAP doesn’t provide an easy way to achieve this, since they acquired BO that uses Adobe Flex.

    I think method 2 is the best solution, fortunately ICM accepts a file as a prefix. Deploy a file, maintain RZ10, restart (exit soft) ICM using SMICM. It’s quick, Basis friendly and almost transparent to the users.

    I found a caveat: the default value for is/HTTP/default_root_hdl is j2ee:

    “is/HTTP/default_root_hdl – This parameter determines the processor of an HTTP request with a URL that points to the root directory (this is a URL without path details, for example, “/” or “/index.html”). You can specify AS ABAP or AS Java as the processors for HTTP requests. Permitted values are abap and j2ee”

    For the solution 2 work, I needed to change it to abap.

Leave a Reply

Your email address will not be published. Required fields are marked *