Tendencias de consumo

As for the BSF, for the NAF a build.xml, as well as a build.properties file is provided that can be used with the the Apache Ant build tool. The files can be adjusted to meet special building requirements. There is also a file named install.txt included, which describes the NAF building and NAF installation process in detail. Please refer to this file for further information of how to build and install the NAF server. The file can be found in the root directory of the NAF server. The following description introduces the NAF configuration files which need to be adjusted according to the installation environment:

DiameterPeer.xml For diameter connectivity with the BSF, the NAF Diameter peer need to be configured. The target BSF peer can be configured in the DiameterPeer.xml or can be detected and added at runtime dynamically. A full sample configuration file for the BSF can be found in the Appendix section E.4. The NAF Diameter peer is configured accordingly.

naf.properties The main NAF server configuration is done via the naf.properties file. A sample configuration file can be found in the Appendix section E.2. The configuration options include the virtual host settings as well as support of a secure BSF (HTTPS) and support of a non-secure BSF (plain HTTP). Transport Layer Security The NAF is equipped with a server certificate which should be stored in a Java Keystore file. This file should be placed into the conf directory in the NAF root directory. By default, the NAF contains a self-signed server certificate in a default keystore file .keytore. The keystore location may be changed by setting a location in the naf.properties files. Also, a keystore password need to be configured in this file.

The NAF server certificate is also used by the Authentication Proxy. The default self-signed certificate should be replaced with a certificate from a widely trusted certification authority. Many browsers dispose of a list of trusted certification authorities and have their root certificates pre-installed. The NAF / AP should be equipped with a certificate signed by one of these authorities to avoid warning messages popping up in the user’s browser. Whenever a server presents a non-trusted certificate (a certificate signed from a certification authority not existent in the list of trusted authorities), the user is required to accept the certificate before the browser allows further communication. To enable a easy to use and widely trusted infrastructure, the user should not be confronted with warnings like that. Therefore, the NAF / AP should be equipped with a certificate from a trusted authority

such as ”VeriSign” 14

4.3.2 The Authentication Proxy

The Authentication Proxy (AP) operation mode is the main operation mode for the NAF. In this operation mode, the NAF acts as a reverse proxy. While normal proxies connect many clients via the proxy to the Internet, the reverse proxy con- nects many web servers via the proxy to the client/Internet. The 3GPP definition for a reverse proxy is: A reverse proxy is a web server system that is capable of serving web pages sourced from other web servers (AS), making these pages look like they originated at the reverse proxy. [TS33.222]

As shown in figure 3.7 and figure 3.10, the AP may replace the interface Ut that is defined for HTTP connections between clients and Application Servers (AS). The AP implementation assumes that all connected ASs cannot be reached from the client directly. Their hostnames are resolved to the IP address of the AP. Therefore, the AP need to be configured so as to listen for all requests that are intended to be answered by the supported ASs. This is achieved in the implemen- tation by starting the AP with several virtual hostnames, each of them belonging to exactly one AS. So whenever a request, that is intended to hit an AS, is routed to the AP, the AP determines the correct AS (based on the request URL) and forwards the request to the AS. Upon receiving the AS response, it is delivered to the client.

The administrators of the connected ASs need to deploy their applications keep- ing in mind that the AP needs to forward client requests. This means that there may not be two applications deployed in the same location. The following exam- ple should clearify this issue. Service 1 is deployed at server1.open-ims.org: 8080/presence/service1 while Service 2 is deployed at server2.open-ims. org:8080/messaging/service2. In this scenario the AP forwards requests for service 1 to server1.open-ims.org based on the /presence/ part of the URL while requests to service 2 are forwarded to server2.open-ims.org because the URL contains a part/messaging/right behind the port 8080. The AP maintains a list (defined in naf.properties) of connected ASs and the corresponding URL patterns (root directories). For the example above this would be:

server1.open-ims.org presence

server2.open-ims.org messaging

Based on the root directory of the applications (presence, messaging) the AP de-

14

cides to which AS a request need to be forwarded to. This means that there must not be two different applications deployed in the same root directory although be- ing deployed on different server machines. There must be unique root directories for all services across all ASs intended to be supported by the AP. The sample configuration of the NAF including several virtual hostnames is listed in the Ap- pendix section E.2.