3 Preparing the Network for an Enterprise Deployment

This chapter describes the prerequisites for the Oracle Identity Management Infrastructure enterprise deployment topologies.

This chapter includes the following topics:

3.1 Overview of Preparing the Network for an Enterprise Deployment

You must configure several virtual servers and associated ports on the load balancer for different types of network traffic and monitoring. These virtual servers should be configured to the appropriate real hosts and ports for the services running. Also, the load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.

3.2 Planning Your Network

As shown in the deployment topology figures in Section 2.2, "Understanding the Topologies," each deployment is spread across multiple zones. A zone is a means of restricting access to components of your infrastructure to those that actually need it. In the examples in this guide, two zones are shown.

  • The public zone–This is where the outside world gains access to your systems. You place into this zone only those components that the outside world must access, such as the Load Balancers and Web Tiers. If users from the outside world attempts to access any servers or services below this zone, they are prevented from doing so by firewalls.

    The public zone is configured so that the servers in this zone can interact with the application servers in the private zone.

  • The intranet zone–This is where you place servers that contain core services, such as databases. These services are very tightly controlled by the organization as they contain the most sensitive data.

By using this approach, you restrict access to information to only those components that require it. This approach is useful where you have users coming in from outside of your organization. If, instead of an extranet, you are setting up an intranet, where all communication is from trusted sources, then you might reasonably decide to do away with one or more of the zones.

3.3 About Virtual Server Names Used by the Topologies

Virtual server names are configured on your load balancer. A load balancer can be configured so that traffic received on a given IP Address is distributed to a pool of dedicated servers associated with that IP address.

This load balancer IP address is associated with a name, known as a virtual server name, which is defined in DNS. The load balancer includes this name in HTTP headers so that it can be distinguished by Oracle HTTP Server.

This section contains the following topics:

3.3.1 Virtual Host Names

The load balancer is configured with a number of virtual host names, depending on the access required DNS is set up in such a way that these virtual host names are accessible in the areas where they are used. For example:

Public communication is configured using a virtual host which is resolvable both inside and outside of the organization.

Interprocess communication is configured using a virtual host which is only resolvable in the private zone.

Administration access is resolvable only inside the organization.

3.3.2 Virtual Server names

The Identity Management enterprise topologies use the following virtual server names:

Ensure that the virtual server names are associated with IP addresses and are part of your DNS. The computers on which Oracle Fusion Middleware is running must be able to resolve these virtual server names.

You define the virtual server names on the load balancer using the procedure in Section 3.4, "Configuring the Load Balancers"

The rest of this guide assumes that the deployment is one of those shown in Chapter 2, "Introduction and Planning."

3.3.2.1 IDSTORE.mycompany.com

  • This virtual server is enabled on LBR2. It acts as the access point for all Identity Store LDAP traffic. Traffic to both the SSL and non-SSL is configured. The clients access this service using the address IDSTORE.mycompany.com:636 for SSL and IDSTORE.mycompany.com:389 for non-SSL.

  • If your Identity Store is accessed through Oracle Virtual Directory, monitor the heartbeat of the Oracle Virtual Directory processes on OVDHOST1 and OVDHOST2. If an Oracle Virtual Directory process stops, the load balancer must continue to route the LDAP traffic to a surviving Oracle Virtual Directory instance.

  • If your Identity Store is in Oracle Internet Directory and is accessed directly, monitor the heartbeat of the Oracle Internet Directory processes on the Oracle Internet Directory Hosts. If an Oracle Internet Directory process stops, the load balancer must continue to route the LDAP traffic to a surviving Oracle Internet Directory instance.

  • If your Identity Store is in Oracle Unified Directory and is accessed directly, monitor the heartbeat of the Oracle Unified Directory processes. If an Oracle Unified Directory process stops, the load balancer must continue to route the LDAP traffic to a surviving Oracle Unified Directory instance.

  • If your identity store is in Oracle Unified Directory, this virtual server directs traffic received on port 389 (LDAP_LBR_PORT) to each of the Oracle Unified Directory instances on port 1389 (LDAP_DIR_PORT).

  • If your identity store is in Oracle Unified Directory, this virtual server directs traffic received on port 636 (LDAP_LBR_SSL_PORT) to each of the Oracle Unified Directory instances on port 1636 (LDAP_DIR_SSL_PORT).

  • If your identity store is in Oracle Internet Directory, this virtual server directs traffic received on port 389 (LDAP_LBR_PORT) to each of the Oracle Internet Directory instances on port 3060.

  • If your identity store is in Oracle Internet Directory, this virtual server directs traffic received on port 636 (LDAP_LBR_SSL_PORT) to each of the Oracle Internet Directory instances on port 3131.

  • If your identity store is in Oracle Virtual Directory, this virtual server directs traffic received on port 389 (LDAP_LBR_PORT) to each of the Oracle Virtual Directory instances on port 6501.

  • If your identity store is in Oracle Virtual Directory, this virtual server directs traffic received on port 636 (LDAP_LBR_SSL_PORT) to each of the Oracle Virtual Directory instances on port 7501.

3.3.2.2 ADMIN.mycompany.com

  • This virtual server is enabled on LBR1. It acts as the access point for all internal HTTP traffic that gets directed to the administration services. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address ADMIN.mycompany.com:80 and in turn forward these to port 7777 (OHS_PORT) on WEBHOST1 and WEBHOST2. The services accessed on this virtual host include the WebLogic Administration Server Console, Oracle Enterprise Manager Fusion Middleware Control, Oracle Authorization Policy Manager, and Oracle Directory Services Manager.

  • Create rules in the firewall to block outside traffic from accessing the /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the ADMIN.mycompany.com virtual host.

3.3.2.3 IDMINTERNAL.mycompany.com

  • This virtual server is enabled on LBR1. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address IDMINTERNAL.mycompany.com:80 and in turn forward these to port 7777 (OHS_PORT) on WEBHOST1 and WEBHOST2. The SOA Managed servers access this virtual host to callback Oracle Identity Manager web services

  • Create rules in the firewall to block outside traffic from accessing this virtual host. Only traffic inside the DMZ should be able to access these URLs on the IDMINTERNAL.mycompany.com virtual host.

3.3.2.4 SSO.mycompany.com

  • This is the virtual name which fronts all Identity Management components, including Oracle Access Management and Oracle Identity Manager.

  • This virtual server is enabled on LBR1. It acts as the access point for all HTTP traffic that gets directed to the single sign on services. The incoming traffic from clients is SSL enabled. Thus, the clients access this service using the address SSO.mycompany.com:443 and in turn forward these to port 7777 (OHS_PORT) on WEBHOST1 and WEBHOST2. All the single sign on enabled protected resources are accessed on this virtual host.

  • Configure this virtual server in the load balancer with both port 80 (HTTP_PORT) and port 443 (HTTP_SSL_PORT).

  • This virtual host must be configured to preserve the client IP address for a request. In some load balancers, you configure this by enabling the load balancer to insert the original client IP address of a request in an X-Forwarded-For HTTP header.

3.4 Configuring the Load Balancers

Several virtual servers and associated ports must be configured on the load balancer for different types of network traffic and monitoring. These should be configured to the appropriate real hosts and ports for the services running. Also, the load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.

There are two load balancer devices in the recommended topologies. One load balancer is set up for external HTTP traffic and the other load balancer is set up for internal LDAP traffic. A deployment may choose to have a single load balancer device due to a variety of reasons. While this is supported, the deployment should consider the security implications of doing this and if found appropriate, open up the relevant firewall ports to allow traffic across the various zones. It is worth noting that in either case, it is highly recommended to deploy a given load balancer device in fault tolerant mode.

This section contains the following topics:

3.4.1 Load Balancer Requirements

The enterprise topologies use an external load balancer. This external load balancer must have the following features:

  • Ability to load-balance traffic to a pool of real servers through a virtual host name: Clients access services using the virtual host name (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.

  • Port translation configuration.

  • Monitoring of ports (HTTP and HTTPS).

  • Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:

    • The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for Oracle WebLogic Clusters, the load balancer must be configured with a virtual server and ports for HTTP and HTTPS traffic.

    • The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.

  • Ability to detect node failures and immediately stop routing traffic to the failed node.

  • Resource monitoring / port monitoring / process failure detection: The load balancer must be able to detect service and node failures (through notification or some other means) and to stop directing non-Oracle Net traffic to the failed node. If your external load balancer has the ability to automatically detect failures, you should use it.

  • Fault tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.

  • Other: It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the back-end services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.

  • SSL acceleration, which refers to off loading the public-key encryption algorithms involved in SSL transactions to a hardware accelerator. This feature is recommended, but not required.

  • Ability to terminate SSL requests at the load balancer and forward traffic to the backend real servers using the equivalent non-SSL protocol. For example, the load balancer must be able to forward HTTPS requests as HTTP. This feature is sometimes called "SSL termination." It is required for this Enterprise Deployment.

  • Ability to Preserve the Client IP Addresses: The Load Balancer must have the capability to insert the original client IP address of a request in an X-Forwarded-For HTTP header to preserve the Client IP Address.

  • Ability to add WL-Proxy-SSL: true to the HTTP Request Header. Some load balancers do this automatically.

3.4.2 Load Balancer Configuration Procedures

The procedures for configuring a load balancer differ, depending on the specific type of load balancer. Refer to the vendor supplied documentation for actual steps. The following steps outline the general configuration flow:

  1. Create a pool of servers. This pool contains a list of servers and the ports that are included in the load balancing definition. For example, for load balancing between the web hosts you create a pool of servers which would direct requests to hosts WEBHOST1 and WEBHOST2 on port 7777 (OHS_PORT).

  2. Create rules to determine whether or not a given host and service is available and assign it to the pool of servers described in Step 1.

  3. Create a Virtual Server on the load balancer. This is the address and port that receives requests used by the application. For example, to load balance Web Tier requests you would create a virtual host for SSO.mycompany.com:80.

  4. If your load balancer supports it, specify whether or not the virtual server is available internally, externally or both. Ensure that internal addresses are only resolvable from inside the network.

  5. Configure SSL Termination, if applicable, for the virtual server.

  6. Assign the Pool of servers created in Step 1 to the virtual server.

  7. Tune the time out settings as listed in Table 3-3, "Ports Used in the Oracle Identity Management Enterprise Deployment Topologies". This includes time to detect whether a service is down.

3.4.3 Load Balancer Configuration

For an Identity Management deployment, configure your load balancer as shown in Table 3-1.

Table 3-1 Load Balancer Configuration

Virtual Host Server Pool Protocol SSL Termination External Other Required Configuration/Comments

SSO.mycompany.com:80

WEBHOST1.mycompany.com:7777

WEBHOST2.mycompany.com:7777

HTTP

No

Yes

Identity Management requires that the following be added to the HTTP header:

Header Name: IS_SSLFoot 1 

Header Value: ssl

SSO.mycompany.com:443

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

Yes

Yes

Identity Management requires that the following be added to the HTTP header:

Header Name: IS_SSL

Header Value: ssl

ADMIN.mycompany.com:80

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

No

No

  

IDMINTERNAL.mycompany.com:80

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

No

No

  

IDSTORE.mycompany.com:389

IDMHOST1.mycompany.com:1389

IDMHOST2.mycompany.com:1389

LDAP

No

No

Only required if Identity Management users are stored in an Oracle Unified Directory.

IDSTORE.mycompany.com:636

IDMHOST1.mycompany.com:1636

IDMHOST2.mycompany.com:1636

LDAP

No

No

Only required if Identity Management users are stored in an Oracle Unified Directory.

IDSTORE.mycompany.com:389

OIDHOST1.mycompany.com:3060 OIDHOST2.mycompany.com:3060

LDAP

No

No

This will generally have been setup as part of your OID installation. It is used to load balance LDAP calls to OID.

IDSTORE.mycompany.com:636

OIDHOST1.mycompany.com:3131 OIDHOST2.mycompany.com:3131

LDAP

No

No

This will generally have been setup as part of your OID installation. It is used to load balance LDAP calls to OID.

IDSTORE.mycompany.com:389

OVDHOST1.mycompany.com:6501 OVDHOST2.mycompany.com:6501

LDAP

No

No

This will generally have been setup as part of your OVD installation. It is used to load balance LDAP calls to OVD.

IDSTORE.mycompany.com:636

OVDHOST1.mycompany.com:7501 OVDHOST2.mycompany.com:7501

LDAP

No

No

This will generally have been setup as part of your OVD installation. It is used to load balance LDAP calls to OVD.

Footnote 1 For information about configuring IS_SSL, see "About User Defined WebGate Parameters" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

3.5 About IP Addresses and Virtual IP Addresses

A virtual IP address is an unused IP Address which belongs to the same subnet as the host's primary IP address. It is assigned to a host manually and Oracle WebLogic Managed servers are configured to listen on this IP Address. In the event of the failure of the node where the IP address is assigned, the IP address is assigned to another node in the same subnet, so that the new node can take responsibility for running the managed servers assigned to it.

The following is a list of the Virtual IP addresses required by Oracle Identity Management:

  • ADMINVHN.mycompany.com

    In Enterprise deployments the WebLogic Administration Server must be able to continue processing requests after the host it is residing on fails. A virtual IP address should be provisioned in the application tier so that it can be bound to a network interface on any host in the application tier. The WebLogic Administration Server is configured later to listen on this virtual IP address, as discussed later in this manual. The virtual IP address fails over along with the Administration Server from IDMHOST1 to IDMHOST2, or vice versa.

  • SOAHOSTXVHN.mycompany.com

    One virtual IP address is required for each SOA managed server. This enables the servers to participate in Server migration.

    Provision a virtual IP address in the application tier so that it can be bound to a network interface on any host in the application tier.

  • OIMHOSTXVHN.mycompany.com

    One virtual IP Address is required for each Oracle Identity Manager managed server. This enables the servers to participate in Server migration.

    Provision a virtual IP address in the application tier so that it can be bound to a network interface on any host in the application tier.

Configure the Administration Server and the managed servers to listen on different virtual IPs and physical IPs as illustrated in Figure 3-1.

Figure 3-1 IP Addresses and VIP Addresses

Surrounding text describes Figure 3-1 .

Table 3-2 provides descriptions of the various virtual hosts.

Table 3-2 VIP Addresses and Virtual Hosts

Virtual IP VIP Maps to... Description

VIP1

ADMINVHN

ADMINVHN is the virtual host name that is the listen address for the Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the Administration Server process is running (IDMHOST1 by default).

VIP2

SOAHOST1VHN

SOAHOST1VHN is the virtual host name that maps to the listen address for WLS_SOA1 and fails over with server migration of this managed server. It is enabled on the node where WLS_SOA1 process is running (IDMHOST1 by default).

VIP3

OIMHOST1VHN

OIMHOST1VHN is the virtual host name that maps to the listen address for the WLS_OIM1 server and fails over with server migration of this server. It is enabled in the node where the WLS_OIM1 process us running (IDMHOST1 by default)

VIP4

SOAHOST2VHN

SOAHOST2VHN is the virtual host name that maps to the listen address for WLS_SOA2 and fails over with server migration of this managed server. It is enabled on the node where WLS_SOA2 process is running (IDMHOST2 by default).

VIP5

OIMHOST2VHN

OIMHOST2VHN is the virtual host name that maps to the listen address for the WLS_OIM2 server and fails over with server migration of this server. It is enabled in the node where the WLS_OIM2 process us running (IDMHOST2 by default)

3.6 About Firewalls and Ports

Many Oracle Fusion Middleware components and services use ports. As an administrator, you must know the port numbers used by these services, and to ensure that the same port number is not used by two services on a host.

Most port numbers are assigned after installation. You can use different port numbers if you want to. The port numbers shown in Table 3-3 are examples that are used throughout this guide for consistency. If you use different port numbers, you must substitute those values for the values in the table wherever they are used.

Table 3-3 lists the ports used in the Oracle Identity Management topologies, including the ports that you must open on the firewalls in the topologies.

Firewall notation:

  • FW0 refers to the outermost firewall.

  • FW1 refers to the firewall between the web tier and the application tier.

  • FW2 refers to the firewall between the application tier and the database tier.

You can use the Port Mapping worksheet in Appendix B to help you keep track of your port usage.

Table 3-3 Ports Used in the Oracle Identity Management Enterprise Deployment Topologies

Type Firewall Port and Port Range Protocol / Application Inbound / Outbound Timeout

Browser request

FW0

80

HTTP / Load balancer

Both

Timeout depends on all HTML content and the type of process model used for Oracle Identity Management.

Browser request

FW0

443

HTTPS / Load balancer

Both

Timeout depends on all HTML content and the type of process model used for Oracle Identity Management.

Browser request

FW1

80

HTTPS / Load Balancer

Outbound (for intranet clients)

Timeout depends on all HTML content and the type of process model used for IDM.

Browser request

FW1

443

HTTPS / Load Balancer

Outbound (for intranet clients)

Timeout depends on all HTML content and the type of process model used for IDM.

Load balancer to Oracle HTTP Server

n/a

7777

HTTP

n/a

See Section 3.4, "Configuring the Load Balancers."

OHS registration with Administration Server

FW1

7001

HTTP/t3

Inbound

Set the timeout to a short period (5-10 seconds).

Oracle WebLogic Administration Server access from web tier

FW1

7001

HTTP / Oracle HTTP Server and Administration Server

Inbound

N/A

Enterprise Manager Agent - web tier to Enterprise Manager

FW1

5160

HTTP / Enterprise Manager Agent and Enterprise Manager

Both

N/A

Oracle HTTP Server to WLS_OAM

FW1

14100

HTTP / Oracle HTTP Server to WebLogic Server

Inbound

Timeout depends on the mod_weblogic parameters used.

Oracle HTTP Server WLS_OIM

FW1

14000

HTTP / Oracle HTTP Server to WebLogic Server

Inbound

Timeout depends on the mod_weblogic parameters used

Oracle HTTP Server WLS_SOA

FW1

8001

HTTP / Oracle HTTP Server to WebLogic Server

Both

Timeout depends on the mod_weblogic parameters used

Oracle HTTP Server management by Administration Server

FW1

OPMN remote port (6701) and OHS Admin Port (7779)

TCP and HTTP, respectively

Outbound

Set the timeout to a short period, such as 5-10 seconds.

OAM Server

FW1

5575

OAP

Both

N/A

Access Manager Coherence port

FW1

9095

TCMP

Both

N/A

Oracle Coherence Port

FW1

8000 - 8088

TCMP

Both

N/A

IDMDomain Oracle WebLogic Administration Server access from directory tier

FW2

7001

HTTP / Oracle Internet Directory, Oracle Virtual Directory, and Administration Server

Outbound

N/A

Enterprise Manager Agent - directory tier to Enterprise Manage, if directory tier is implemented.

FW2

5160

HTTP / Enterprise Manager Agent and Enterprise Manager

Both

N/A

Oracle HTTP Server to Administration Server

FW2

OPMN remote port

HTTP / Administration Server to OPMN

Inbound

N/A

Application Tier to Database Listener

FW2

1521

SQL*Net

Both

Timeout depends on all database content and on the type of process model used for Oracle Identity Management.

Oracle Notification Server (ONS)

FW2

6200

ONS

Both

Required for Gridlink. An ONS server runs on each database server.

LDAP Port

FW2

Depends on directory

LDAP

Inbound

Ideally, these connections should be configured not to time out.

LDAP SSL Port

FW2

Depends on directory

LDAP SSL

Inbound

Ideally, these connections should be configured not to time out.

Node Manager

N/A

5556

TCP/IP

N/A

N/A

Note:

Additional ports might need to be opened across the firewalls to enable applications in external domains, such as SOA or WebCenter Portal domains, to authenticate against this Identity Management domain.

3.7 Managing Access Manager Communication Protocol

This section discusses Oracle Access Protocol (OAP) and provides an overview of a user request.

This section contains the following topics:

3.7.1 Access Manager Protocols

Oracle Access Protocol (OAP) enables communication between Access System components (for example, OAM Server, WebGate) during user authentication and authorization. This protocol was formerly known as NetPoint Access Protocol (NAP) or COREid Access Protocol.

3.7.2 Overview of Integration Requests

Oracle Access Management Access Manager is responsible for creating sessions for users. When Access Manager is integrated with another Identity Management component, such as Oracle Identity Manager, authentication is delegated to that component.

A typical request flow is as follows:

  1. The user tries to access a resource for the first time.

  2. WebGate intercepts the request and detects that the user is not authenticated.

  3. Access Manager credential collector is invoked and the user enters a user name and password in response to a prompt. Access Manager knows that password policy requires the password to be changed at first login, so the user's browser is redirected to Oracle Identity Manager.

  4. The user is prompted to change password and set up challenge questions.

  5. At this point, Oracle Identity Manager has authenticated the user using the newly entered password. Oracle Identity Manager creates a TAP request to say that Access Manager can create a session for the user. That is, the user will not be expected to log in again. This is achieved by adding a token to the user's browser that Access Manager can read.

    The TAP request to Access Manager will include such things as:

    • Where the Access Manager servers are located.

    • What web gate profile to use.

    • WebGate profile password.

    • Certificates, if Access Manager is working in simple or cert mode.

3.7.3 Overview of User Request

The request flow when a user requests access is as follows:

  1. The user requests access to a protected resource over HTTP or HTTPS.

  2. The WebGate intercepts the request.

  3. The WebGate forwards the request to the OAM Server over Oracle Access Protocol to determine if the resource is protected, how, and whether the user is authenticated (if not, there is a challenge).

  4. The OAM Server checks the directory server for credentials such as a user ID and password, sends the information back to WebGate over Oracle Access Protocol, and generates an encrypted cookie to authenticate the user.

  5. Following authentication, the WebGate prompts the OAM Server over Oracle Access Protocol and the OAM Server looks up the appropriate security policies, compares them to the user's identity, and determines the user's level of authorization.

    • If the access policy is valid, the user is allowed to access the desired content and/or applications.

    • If the policy is false, the user is denied access and redirected to another URL determined by the organization's administrator.

3.7.4 About the Unicast Requirement for Communication

Oracle recommends that the nodes in the topology communicate using unicast communication. Unlike multicast communication, unicast does not require cross-network configuration. Using unicast avoids network errors due to multicast address conflicts.

In unicast messaging mode, the default listening port of the server is used if no channel is configured. Cluster members communicate to the group leader when they need to send a broadcast message which is usually the heartbeat message. When the cluster members detect the failure of a group leader, the next oldest member becomes the group leader. The frequency of communication in unicast mode is similar to the frequency of sending messages on multicast port.

The following considerations apply when using unicast to handle cluster communications:

  • All members of a WebLogic cluster must use the same message type. Mixing multicast and unicast messaging is not allowed.

  • Individual cluster members cannot override the cluster messaging type.

  • The entire cluster must be shut down and restarted to change the message modes from unicast to multicast or from multicast to unicast.

  • JMS topics configured for multicasting can access WebLogic clusters configured for unicast because a JMS topic publishes messages on its own multicast address that is independent of the cluster address. However, the following considerations apply:

    • The router hardware configurations that allow unicast clusters may not allow JMS multicast subscribers to work.

    • JMS multicast subscribers need to be in a network hardware configuration that allows multicast accessibility. (That is, JMS subscribers must be in a multicast-enabled network to access multicast topics.)