Fully Qualified Domain Names (FQDN) 

In Web Dynpro ABAP it is imperative that a client browser with a fully qualified domain name (FQDN) has access to the AS-ABAP. For this reason the full URL must be assigned to a Web Dynpro ABAP application when it is called. The URL must not be shortened (for instance, no domain specification).

The domain used must also satisfy the requirements of the cookie specification (see http://wp.netscape.com/newsref/std/cookie_spec.html).

To check the FQDN, in the Web Dynpro explorer in the ABAP development environment (SE80), choose the relevant Web Dynpro application from the navigation tree for your Web Dynpro component/interface, and check the URL in the administration data. Check whether the path details in the URL field also contain the full domain and host name.

Note that neither IP addresses nor underscore characters are allowed in host names (see below).

More information: SAP Note 654982.

Purpose

FQDNs are necessary for the following reasons:

●      One domain is required with which cookies can be set domain-wide, for instance, SSO2 cookies.

●      Domain relaxation code is required for cross-frame JavaScript.
This is particularly important for portal integration (see below).

●      In an HTTPS environment, client and server names must correspond to each other for certificates and for the SSL protocol.

Note that the domain in which the AS ABAP is run is not necessarily the FQDN used to access the AS ABAP from the browser. A typical example is an AS ABAP that runs both in the Intranet and in the Internet. In a case like this, the FQDN is determined by the position of the browser relative to the AS ABAP and not by the AS ABAP itself.

Configuration of Fully Qualified Domain Names

If the host name simply specifies the host and port but not the domain (including the extension), the shortened URL of a Web application looks like:

<schema>://<host name>:<port>/sap/...

Example:

http://pwdf0487:1080/sap/bc/webdynpro/sap/wdr_test_events

Whereas the full URL should look like:

<schema>://<host name>.<domain> <extension>:<port>/sap/...

Example:

http://pwdf0487.wdf.sap-ag.de:1080/sap/bc/webdynpro/sap/wdr_test_events

IP Addresses Not Supported

URLs that contain IP addresses are not supported.

<schema>://<IP address>:<port>/sap/...

Example:

http://10.21.81.0:1080/sap/bc/webdynpro/sap/xyz

The following notation is required:

<schema>://<host name>.<domain> <extension>:<port>/sap/...

Example:

http://hs0059i.wdf.sap.corp:1080/sap/bc/webdynpro/sap/xyz

To map IP addresses correctly, the following is required:

●      A minimal form of DNS at the customer location with the name of the AS-ABAP and a mapping to an IP address.

●      Alternatively, a pseudo AS-ABAP name can be used, and the HTTP proxy configured at the firewall in such a way that this URL is sent to the correct IP address.

●      For smaller installations you can use the following quick solution:

Update the hosts file on each workstation. Insert the line 10.17.73.210  hostname.domain.ext into file \WINNT\system32\drivers\etc\hosts.

No Support for '_' in Host Names

The browser does not accept cookies if a host name contains the underscore character '_'.

Since Microsoft Internet Explorer 6.0 and MS Internet Explorer 5.5 including security patch MS01-055 cannot accept any domain names with underscore characters, session cookies cannot be saved. This will result in terminations when navigating within a Web application.

Example:

The development system is called dev_sys, and the quality security system, qsys. This means the fully qualified domain name is:

qsys.company.co.xx

The following notation is not accepted:
dev_sys.company.co.xx
qsys.my_company.co.xx

For this reason, host and domain names must never contain the underscore character, '_'.

Domain Restrictions in Accordance with the Cookie Specification

The portal must be started with a domain that complies with the domain specification of the Internet standard cookie specification. Otherwise the portal cannot create the MYSAPSSO2 cookie.

So that the browser can decide which servers a cookie can be sent to, the URL must contain the domain specification, since the decision is based on this information. In accordance with the Netscape cookie specification (available at http://wp.netscape.com/newsref/std/cookie_spec.html), cookies can be set for one domain only, and a domain must contain two or three dots (.) due to security restrictions. Each of the seven top level domains (.COM,.EDU,.NET,.ORG,.GOV,.MIL,.INT) must contain at least one further domain component (usually the name of the company or organization), amounting to two dots. Each domain with a different ending (this includes the top level domains for countries, such as UK, DE, FR, and so on) must consist of two further domain components, that is, these domains must contain at least three dots. For more information see the cookie specification.

Examples of valid domains:

●        <host>.sap.com
Top level domain -> two domain components

●        <host>.portal.sap.de
No top level domain -> three domain components

 

Some browsers (for instance, Microsoft Internet Explorer) are less strict and permit domains that violate the cookie specification rules listed above.

The Internet Explorer would allow the following domain:

<host>.sap.de

This is not a top level domain, yet it only has two domain components.

Domains appear to be accepted whose penultimate component consists of at least three characters, because otherwise there would be problems, for instance with all British domains, due to there being insufficient restrictions on how cookies are sent.

Examples

URL	Description
http://www.xy.com	Compliant with specification
http://www.xy.co.uk	Compliant with specification
http://<host>.epd.de	For MS IE ok
http://www.sap.de	For MS IE ok
http://<host>.ep.de	For MS IE not ok
http://www.co.uk	Not ok (compliant with specification)

SAP generally recommends that you always comply with the definitions of the cookie specifications.

HTTPS

The use of SSL (with HTTPS), as well as ensuring encrypted data transfer, should also ensure that the server being contacted (for example, a company or organization) is authentic. This is done using SSL server certificates. For each HTTPS URL the browser checks whether the full host name contained in the URL corresponds to the relevant specification (such as common name, CN) in the checked SSL server certificate. If the browser ascertains a difference, it triggers an error warning.

Examples

The SSL server certificate was issued on "CN=tcs.mysap.com, OU=SAP Trust Community, O=SAP AG, L=Walldorf, C=DE". The following URLs are checked:

URL	Description/Behavior
http://tcs.mysap.com/...	No SSL/HTTPS
https://tcs.mysap.com/...	Compliant with specification
https://tcs01.mysap.com/...	Warning/error

With an SSL server certificate issued on "CN=mysap.com, ..." all the URLs listed above return an error.

With an SSL server certificate issued on "CN=*.mysap.com, ..." all the URLs listed above return an error. A certification authority (CA), however, usually establishes its own rules for components that it issues and for verified certificates. The use of wildcards (*) in the common name is generally not permitted.

When you use SSL terminating reverse proxies (in front of the Web Server/AS-ABAP), make sure that the SSL server certificate of the reverse proxy corresponds to the host name of the reverse proxy that is visible for the browser.

For more information about security see SAP Web Application Server Security (ABAP).

Setting the FQDN

The following variables and parameters are used to set the host and domain names:

●      SAPLOCALHOST

●      SAPLOCALHOSTFULL

●      icm/host_name_full

The ICM sets the FQHN in accordance with the hierarchy below:

...

       1.      The SAPLOCALHOSTFULL parameter in the SAP profile (recommended for high availability configurations) has top priority. If it is set in the profile file, the ICM takes this as the FQHN value.

Note that the system default value of SAPLOCALHOSTFULL contains the host name without the domain, which is why the ICM ignores the system default.

       2.      If the parameter is not set, the value in icm/host_name_full is used.

Set the value iicm/host_name_full = $(SAPLOCALHOST).domain.ext.

This is particularly suitable for situations where multiple application servers are operating with one instance profile.

       3.      If this parameter is also not set, the ICM takes the FQHN of the operating system.

The SAPLOCALHOST parameter is not fully qualified and is not used by the ICM for services.

SAP recommends that you set either SAPLOCALHOSTFULL (for high availability configurations), or icm/host_name_full.