# External Connections

## Contents
Overview Authentication Repository Profiles Connection Sets Database Connections Kerberos Connections LDAP Connections OCSP Connections Proxy Servers RADIUS Clients SiteMinder SMTP Servers SOA Security Manager Syslog Servers TIBCO Tivoli URL Connection Sets XKMS Connections

## Overview
The Enterprise Gateway can leverage your existing Identity Management infrastructure, thus avoiding the need to maintain separate silos of user information. For example, if you already have a database full of user credentials, the Enterprise Gateway can authenticate requests against this database, rather than using its own internal user store. Similarly, the Enterprise Gateway can authorize users, lookup user attributes, and validate certificates against third-party Identity Management servers. You can add a connection to an external system as a global External Connection in the Policy Studio so that it can be reused across all filters and policies. For example, if you create a circuit that authenticates users against an LDAP directory, and then validates an XML signature by retrieving a public key from the same LDAP directory, it makes sense to create a global External Connection for that LDAP directory. You can then select the LDAP Connection in both the authentication and XML signature verification filters, rather than having to reconfigure them in both filters. You can also use External Connections in cases where you want to configure a group of related URLs. This is most useful when you want to round-robin between a number of related URLs to ensure high availability. When the Enterprise Gateway is configured to use a URL Connection Set (instead of a single URL), it round-robins between the URLs in the set. You can configure External Connections by right-clicking the appropriate node (for example, Database Connections) on the External Connections tab in the Policy Studio. This topic introduces the different types of External Connection and shows where to obtain more details.
## Authentication Repository Profiles
The Enterprise Gateway can authenticate users against external databases and LDAP repositories, in addition to its own local user store. You can also use a number of bespoke authentication connectors to enable the Enterprise Gateway to authenticate against specific third-party Identity Management products. Connection details for these authentication repositories are configured at a global level, making them available for use across authentication (and authorization) filters. This saves the administrator from reconfiguring connection details in each filter. For example, the available authentication repository types include the following: CA SiteMinder Repositories Database Repositories Entrust GetAccess Repositories LDAP Repositories Local Repositories (for example, Local User Store) Oracle Access Manager Repositories Oracle Entitlements Server Repositories RADIUS Repositories RSA Access Manager Repositories Tivoli Repositories For details how to configure the various authentication repository types, see the Authentication Repository topic.
## Connection Sets
Connection Sets are used by the Enterprise Gateway to round-robin between groups of external servers (for example, RSA Access Manager). You can use reuse these global groups when configuring connections to external servers in the Policy Studio. For this reason, Connection Sets are available on the External Connections tab according to the filter from which they are available. For example, Connection Sets under the RSA ClearTrust Connection Sets node are available in the RSA Access Manager filter. At runtime, the Enterprise Gateway can round-robin between the servers in the group to ensure that if one of the servers becomes unavailable, the Enterprise Gateway can use one of the other servers in the group. To add a Connection Set for a particular category of filters, right-click the appropriate node under the Connection Sets node on the External Connections tab. Select Add a Connection Set to display the Connection Group dialog. For more details, see the Configuring Connection Groups topic.
## Database Connections
The Enterprise Gateway typically connects to databases to authenticate or authorize users using the Enterprise Gateway's numerous Authentication and Authorization filters. Similarly, the Enterprise Gateway can retrieve user attributes from a database (for example, which can then be used to generate SAML attribute assertions later in the policy). You can configure database connections globally on the External Connections tab, making them available to the various filters that require a database connection. This means that an administrator can reuse the same database connection details across multiple authentication, authorization, and attribute-based filters. The Enterprise Gateway maintains a JDBC pool of database connections to avoid the overhead of setting up and tearing down connections to service simultaneous requests. This pool is implemented using Jakarta DBCP (Database Connection Pools). The settings in the Advanced section of the Configure Database Connection dialog are used internally by the Enterprise Gateway to initialize the connection pool. The table at the end of this section shows how the fields correspond to specific configuration DBCP settings. To configure details for a global database connection, right-click the Database Connections node on the External Connections tab. Select the Add a Database Connection menu option, and configure the fields on the Configure Database Connection dialog. For details on configuring these fields, see the Database Connection topic.
## Kerberos Connections
You can configure global Kerberos Clients, Kerberos Services, and Kerberos Principals on the External Connections tab in the Policy Studio. When a Kerberos item is configured, it is available for selection in all Kerberos-related configuration screens that require this item. This enables you to share Kerberos configuration items across multiple filters. For more details on configuring Kerberos clients, services, principals and filters, see the Kerberos Index page.
## LDAP Connections
In the same way that database connections can be configured globally in the Policy Studio (and then reused across individual filters), LDAP connections are also managed globally in the Policy Studio. LDAP connections are used by authentication, authorization, and attribute filters. Filters that require a public key (from a public-private key pair) can also retrieve the key from an LDAP source. When a filter that uses an LDAP directory is run for the first time, it binds to the LDAP directory using the connection details configured on the Configure LDAP Server dialog. Usually the connection details include the username and password of an administrator user who has read access to all users in the LDAP directory for whom you wish to retrieve attributes or authenticate. To configure a global LDAP connection, right-click the LDAP Connections node on the External Connections tab. Select the Add an LDAP Connection menu option, and configure the following fields on the Configure LDAP Server dialog: Name: Enter a name for the LDAP connection in the Name field. URL: Enter the location of the LDAP directory in the URL field. An LDAP URL is a combination of the protocol (LDAP), the IP address or host name of the LDAP server, and the port number for the LDAP service. By default, port 389 is reserved for LDAP connections. The following is an example of a typical LDAP directory URL: `ldap://192.168.0.45:389` Authentication Type: If the configured LDAP directory requires clients to authenticate to it, you must select the appropriate authentication method in the Type drop-down list. When the Enterprise Gateway connects to the LDAP directory, it is authenticated to it using the method selected here. The Enterprise Gateway can authenticate to an LDAP directory using the following methods: No Authentication No authentication credentials need be submitted to the LDAP server. The client connects anonymously to the server. Typically, a client is only allowed to perform read operations when connected anonymously to the LDAP server. You do not need to enter any authentication details for this authentication method. Simple Authentication Simple authentication involves sending a user name and corresponding password in clear text to the LDAP server. Because the password is passed in clear text, you should connect over an encrypted channel (for example, SSL). You do not need to specify a Realm when using Simple authentication. The realm is only used when a hash of the password is supplied (for Digest-MD5). However, when the LDAP server contains multiple realms, and the specified user name is present in more than one of these realms, it is at the discretion of the specific LDAP server as to which user name binds bind to it. Select the SSL Enabled checkbox to force the Enterprise Gateway to connect to the LDAP server over SSL. To successfully establish SSL connections with the LDAP server, you must import its certificate into the Enterprise Gateway's certificate store. You can do this using the global Certificates screen. Digest-MD5 Authentication With Digest-MD5 authentication, the server generates some data and sends it to the client. The client encrypts this data with its password according to the MD5 algorithm. The LDAP server then uses the client's stored password to decrypt the data and hence authenticate the user. The Realm field is optional, but may be necessary if the LDAP server contains multiple realms. If a realm is specified, the LDAP server attempts to authenticate the user for the specified realm only. Test Connection: When you have entered all the necessary connection details, you can test the configuration by clicking the Test Connection button. This enables you to detect configuration errors at design time, rather than at runtime.
## OCSP Connections
The Enterprise Gateway can use OCSP (Online Certificate Status Protocol) to validate a certificate against an OCSP responder or group of responders. OCSP requests for certificate validation can be signed by a key from the Certificate Store, and the response from the OCSP responder can be optionally validated. An OCSP Connection typically comprises a group of OCSP Responder URLs, together with options to sign OCSP requests and validate OCSP responses. To configure a global OCSP Connection, right-click the OCSP Connection node on the External Connections tab. Select the Add an OCSP Connection option to display the Certificate Validation - OCSP dialog. For more details, see the OCSP Certificate Validation topic. Important Note: When an OCSP Connection is added in this manner, it is available for selection in the OCSP Certificate Validation filter, which is found under the Certificate category of filters in the Policy Studio.
## Proxy Servers
You can configure proxy servers on the External Connections tab, which can then be specified in the Connection and Connect To URL filters. When configured, the filter connects to the proxy server, which routes the message to the destination server. To configure a proxy server, click the External Connections tab, and select Proxy Servers -> Add a Proxy Server. For details on how to configure the settings the Proxy Server Settings dialog, see the Proxy Server topic.
## RADIUS Clients
The Remote Authentication Dial In User Service (RADIUS) protocol provides centralized authentication and authorization for clients connecting to remote services. To configure a client connection to a remote server over the RADIUS protocol, click the External Connections tab, and select RADIUS Clients -> Add a RADIUS Client. For details on how to configure the settings the RADIUS Client dialog, see the RADIUS Clients topic. For details on how to configure a RADIUS Authentication Repository, see the Authentication Repository topic.
## SiteMinder
To add a CA SiteMinder connection, right-click the SiteMinder/SOA Security Manager node on the External Connections tab, and select Add a SiteMinder Connection to display the SiteMinder Connection Details dialog. For details on configuring the fields on this dialog, see the SiteMinder/SOA Security Manager Connection topic.
## SMTP Servers
SMTP Servers are global configuration items that can be configured on the External Connections tab, and then referenced by the SMTP filter. Right-click the SMTP Servers node on the External Connections tab, and select Add an SMTP Server. You must configure the following fields: SMTP Server Hostname: Enter the hostname or IP address of the SMTP server. Port: Enter the SMTP port on the specified server hostname. By default, SMTP servers run on port 25. Connection Security: Select the security required for the connection to the SMTP server (`NONE`, `SSL`, or `TLS`). Defaults to `NONE`. User Name: Enter the user name of a registered user that can access the SMTP server. Password: Enter the password for this user.
## SOA Security Manager
To add a CA SiteMinder connection, right-click the SiteMinder/SOA Security Manager node on the External Connections tab, and select Add a SOA Security Manager Connection to display the SOA Security Manager Connection Details dialog. For details on configuring the fields on this dialog, see the SiteMinder/SOA Security Manager Connection topic.
## Syslog Servers
You can configure Syslog Servers globally, and then select them as a customized logging destination for a Process. Right-click the Syslog Servers node on the External Connections tab, and select the Add a Syslog Server menu option. Complete the following fields on the Syslog Server dialog: Name: Enter a name for the Syslog server. Host: Specify the host on which the Syslog daemon is running. Facility: Select the Syslog facility that you want to log to. To configure a Process to log to this global Syslog Server, complete the following steps: On the Policy Studio Services tab, right-click the name of the Process in the tree (for example, Oracle Enterprise Gateway). Select the Logging -> Custom option. On the Configure Logging dialog, open the Syslog tab, and select the globally configured Syslog Server from the drop-down list. Ensure to select the Enable logging to Syslog checkbox.
## TIBCO
You can add connections to the following TIBCO products: TIBCO Enterprise Messaging System (EMS) TIBCO Rendezvous Daemon To add a TIBCO EMS connection, right-click the TIBCO EMS Connection node on the External Connections tab, and select Add a TIBCO EMS Connection. For details on configuring the fields on the dialog, see the TIBCO Enterprise Messaging System Connection topic. To add a TIBCO Rendezvous Daemon, right-click the TIBCO Rendezvous Daemon node on the External Connections tab, and select Add a TIBCO Rendezvous Daemon. For details on configuring the fields on the dialog, see the TIBCO Rendezvous Daemon topic.
## Tivoli
You can create a connection to an IBM Tivoli server to enable integration between the Enterprise Gateway and Tivoli Access Manager. Tivoli connections can then be used by the Enterprise Gateway's Tivoli filter to delegate authentication and authorization decisions to Tivoli Access Manager, and to leverage existing Tivoli Access Manager policies. To add a Tivoli connection, right-click the Tivoli Connections node on the External Connections tab, and select Add a Tivoli Connection. For details on configuring the fields on the Tivoli Configuration dialog, see the Tivoli Integration topic.
## URL Connection Sets
URL Connection Sets are used by Enterprise Gateway filters to round-robin between groups of external servers (for example, Entrust GetAccess, OCSP, SAML PDP, or XKMS). These global groups can then be reused when configuring these filters in the Policy Studio. For this reason, URL Connection Sets are available on the External Connections tab according to the filters from which they are available. For example, URL sets under the OCSP URL Sets node are available in the OCSP Certificate Validation filter, while sets under the XKMS URL Sets are only available from the XKMS Certificate Validation filter. At runtime, the Enterprise Gateway can round-robin between the servers in the group to ensure that if one of the servers becomes unavailable, the Enterprise Gateway can use one of the other servers in the group. To add a URL Connection Set for a particular category of filters, right-click the appropriate node under the URL Connection Sets node on the External Connections tab. Select the Add a URL Set option to display the URL Group dialog. For more details, see the Configuring URL Groups topic.
## XKMS Connections
The Enterprise Gateway can also validate certificates against an XKMS (XML Key Management Service) responder or group of responders. An XKMS Connection consists of a group of XKMS responders to validate certificates against, coupled with the signing key to use for signing requests to each of the responders in the group. To add a global XKMS Connection, right-click the XKMS Connection node on the External Connections tab, and select the Add an XKMS Connection option to display the Certificate Validation - XKMS dialog. For more details, see the XKMS Certificate Validation topic. All global XKMS Connections are available for selection when configuring the Certificate Validation - XKMS filter. This saves the administrator from reconfiguring XKMS connection details across multiple filters.