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.
The available authentication repository types include the following:
- Local Repositories (for example, Local User Store)
- Database Repositories
- LDAP Repositories
- CA SiteMinder Repositories
- Oracle Access Manager Repositories
- Tivoli Repositories
For details how to configure the various authentication repository types,
see the Authentication Repository
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.
|
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.
|
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.
|
SMTP Servers
|
SMTP Servers are global configuration items that can be configured here
and then referenced by SMTP-related filters. Right-click the SMTP
Servers node on the External Connections tab, and
select the Add an SMTP Server option. The following fields
must be configured:
Server Name:
Enter the hostname or IP address of the SMTP server.
Port:
Enter the SMTP port on the server specified in the field above. By
default, SMTP servers run on port 25.
User Name:
Enter the user name of a registered user that can access the SMTP server.
Password:
Enter the password for this user.
|
URL Connection Sets
|
URL Groups are used by the Enterprise Gateway's certificate validation filters
to round-robin between groups of OCSP or XKMS responders. These global
groups can be reused when configuring different validation filters in
the Policy Studio. For this reason, URL Connection Sets are labeled 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 be available from the XKMS Certificate
Validation filter.
At runtime, the Enterprise Gateway can round-robin between the responders in
the group to ensure that if one of the responders becomes unavailable,
the Enterprise Gateway can use one of the other responders in the group.
To add a URL Connection Set for a particular category of filters,
right-click the appropriate node under the OCSP URL 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.
|
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.
|
Kerberos Connections
|
You can configure global Kerberos Clients, Services, and Principals
under on the External Connections tab in 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.
|
CA SiteMinder
|
To add a CA SiteMinder connection, right-click the SiteMinder/SOA
Security Manager node on the External Connections
tab in the Policy Studio. Select the Add a SiteMinder Connection
menu option to display the SiteMinder Connection Details dialog.
For details on configuring the fields on this dialog, see the
SiteMinder/SOA Security Manager
Connection topic.
|
CA SOA Security Manager
|
To add a CA SiteMinder connection, right-click the SiteMinder/SOA
Security Manager node on the External Connections
tab in the Policy Studio. Select the Add a SOA Security Manager
Connection menu option 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.
|
|