Overview
|
|
For convenience, the Policy Studio contains various global configuration options.
For example, it includes libraries of users, X.509 certificates, and schemas that
can be added globally and then referenced in filters and policies. This avoids
the need to re-configure details over and over again (for example, each time a schema
or certificate is used).
The following global libraries are available in the Policy Studio, each of
which are discussed briefly in the sections below:
- Enterprise Gateway Configuration Options
- Web Services Repository
- Processes
- Policies
- Certificates
- Enterprise Gateway Users
- Alerts
- External Connections
- Schema Cache
- Black list
- White list
- Caches
|
Enterprise Gateway Configuration Options
|
|
You can configure the underlying configuration settings for the Enterprise Gateway using the
the Policy Studio Settings menu option. This includes the following
options:
- Deploy
- Default Settings
- Logging Settings
- Namespace Settings
- MIME/DIME Settings
- Change Passphrase
For more information, see
Enterprise Gateway Configuration Options.
|
Web Services Repository
|
|
The easiest way to secure a Web Service with the Enterprise Gateway is
to import the WSDL (Web Services Description Language) file for the
service using the Policy Studio. This creates a Service Handler for the
Web Service, which is used to control and validate requests to the Web
Service and responses from the Web Service.
The WSDL file is also added to the Web Services Repository, making sure
to update the URL of the Web Service to point at the machine on which
the Enterprise Gateway is running as opposed to that on which the Web Service is
running. Consumers of the Web Service can then query the Enterprise Gateway for
the WSDL file for the Web Service. The consumer then knows to route
messages to the Enterprise Gateway instead of attempting to route directly to
the Web Service, which most likely will not be available on a public IP
address.
The Web Services Repository offers administrators a very simple way of
securing a Web Service with minimal impact on consumers of that service.
Because of this, the Web Services Repository should be used as the
primary method of setting up policies within the Policy Studio. For more
information on using the Repository to setup policies, take a look at the
Web Services Repository
tutorial.
|
Processes
|
|
A Process represents a single running instance of a the
Enterprise Gateway. It enables you to configure at least 2 interfaces
- one for public traffic and a second for listening for and serving
configuration data. The configuration interface should rarely
need to be updated, however, it is likely that you will want to add
several HTTP interfaces. For example, you may want to add an HTTP
interface and also an SSL-enabled HTTPS interface.
Furthermore, it is possible to add JMS listeners, packet sniffers, and
directory scanners to a Process once it has been added. This allows
the Enterprise Gateway to listen for JMS messages, inspect packets at the
network level for logging and monitoring purposes, and scan messages
that have been dumped to the file system.
Because the Enterprise Gateway can read messages from HTTP, JMS, or a directory,
gives it the ability to perform protocol translation. For example, it is
possible to read a message from a JMS queue and then route it on over
HTTP to a Web Service. Similarly, the Enterprise Gateway can read XML messages
that have been FTP-ed to a directory on the file system and send them
to a JMS messaging system or route them over HTTP to a back-end system.
For more information on configuring processes, please refer to the
Processes tutorial.
|
Policies
|
|
A policy is made up of a sequence of modular, reusable message filters,
each of which processes the message in a particular way. There are many
categories of filters available, including authentication, authorization,
content filtering, routing, and many more.
So, for example, a typical policy might contain an authentication filter,
followed by several content-based filters (e.g. Schema Validation,
Threatening Content, Message Size, XML Complexity, etc), and provided all
configured filters run successfully, the message will be routed on to
the configured destination.
A policy can be thought of as a network of message filters. A message
can traverse different paths through the network depending on what filters
succeed or fail. This allows us to configure policies that, for example,
route messages that pass one Schema Validation filter to one back-end
system, and route messages that pass a different
Schema Validation filter to a different system.
To help manage your policies, Policy Containers can
be used. A Policy Container is typically used to group together a number
of similar policies (e.g. all authentication policies) or to act as an
umbrella around several policies that relate to a particular policy (e.g.
all policies for the "getQuote" Web Service.
A number of useful policies that ship with the Enterprise Gateway can be found
under the "Policy Library" Policy Container. This container is
pre-populated with policies to return various types of faults to the
client and policies to block certain types of threatening content, amongst
others. It is, of course, possible to add your own policies to this
container, as it is to create your own Policy Containers as necessary to
suit your own requirements.
The "Configuration" Policy Container is used to store the authentication
and (non-editable) content-based filtering that is applied to
configuration messages. It should only be changed under strict
supervision from the Oracle support team.
|
Certificates
|
|
The Enterprise Gateway must be able to trust X.509 certificates in
order to establish SSL connections with external servers, validate XML
Signatures, encrypt XML segments for certain recipients, and for other
such cryptographic operations. Similarly, in order to carry out certain
other cryptographic operations, such as message signing and decrypting
data, a private key is required.
The Trusted Certificate Store contains all the
certificates that are considered to be trusted by the Enterprise Gateway.
Certificates can either be imported into or created by the Certificate
Store. It is also possible to assign a private key to the public key
stored in a certificate, either by importing the private key or by
generating one using the provided interface.
For more information on importing and creating certificates, please refer
to the
Trusted Certificate Store
help page.
|
Enterprise Gateway User Store
|
|
Users are mainly used for authentication purposes in the Enterprise Gateway.
In this context, the User Store acts as a repository
for user information against which users can be authenticated. You can
also store user attributes for each user, which can then be used when
generating SAML attribute assertions on behalf of the user, for example.
Furthermore, a public and private key pair (and X.509 certificate) can
be associated with each user for use in SSL mutual authentication,
signing XML messages, signing log messages, signing OCSP and XKMS
requests, and XML Encryption, amongst other uses.
The Enterprise Gateway Users topic
contains more details on how to create users, create key pairs, import
certificates, and assign privileges to them.
|
System Alerts
|
|
The Enterprise Gateway can send system alerts to various error reporting systems
in the case of a policy error, for example, when a request is
blocked by a policy. Alerts can be sent to an Windows Event Log, UNIX
syslog, OPSEC firewall, SNMP NMS, or email recipient.
Please refer to the
System Alerts help page
for more information on how to configure the Enterprise Gateway to send these
alerts.
|
External Connections
|
|
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 3rd party identity
management servers.
Each such connection to an external system can be added as a global
External Connection in the Policy Studio so that it
can be re-used across all filters and policies. So, 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, then it makes sense to create a global External
Connection for that LDAP directory. The LDAP Connection can then be
merely selected in both the authentication
and XML signature verification filters, rather than having to be
re-configured in both filters.
The following default types of global connections can be configured
using the External Connections interface. Other bespoke
Connectors are available on request.
- Authentication Repository Profiles
- Database Connections
- LDAP Connections
- OCSP Connections
- XKMS Connections
- Kerberos Services
External Connections can also be used in cases where you want to
configure a group of related URLs. This is most useful in cases where
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 (as opposed to just a single URL),
it will round-robin between the URLs in the set.
For more information on configuring External Connections and Connection
Sets, please refer to the
External Connections
tutorial.
|
Schema Cache
|
|
The global Schema Cache contains all the XML Schemas
that the Enterprise Gateway can use to validate incoming requests against.
The Schema Validation filter validates the format of
an incoming message against a schema from the cache. This ensures that
only messages of the correct format are processed by the target system.
Refer to the
Schema Cache tutorial
for instructions on how to import XML Schemas into the cache. Once you
have imported your schemas, you can take a look at the
Schema Validation
tutorial for instructions on how to validate XML messages against the
schemas in the cache.
|
Black list and White list
|
|
The White list is a global library of regular expressions
that can be used across several different filters. For example, the
Validate HTTP Headers, Validate Query String,
and Validate Message Attributes filters all use regular
expressions from the White list to ensure that various
parts of the request contain expected content.
The White list is pre-populated with regular expressions
that can be used to identify common data formats, such as alphanumeric
characters, dates, email addresses, IP addresses, and so on. For example,
if a particular HTTP header is expected to contain an email address, the
Email Address expression from the library can be run against
the HTTP header to ensure that it contains an email address as expected. This
is yet another way that the Enterprise Gateway can ensure that only the correct data
reaches the Web Service.
While the White list contains regular expressions to identify valid
data, the Black list contains regular expressions that are used to
identify common attack signatures. For example, this includes expressions to scan for
SQL injection attacks, buffer overflow attacks, ASCII control characters, DTD entity
expansion attacks, and many more.
You can run various parts of the request message against the regular expressions
contained in the Black list library. For example, the HTTP headers,
request query string, and message (MIME) parts can be scanned for SQL injection
attacks by selecting the SQL-type expressions from the Black list.
The Threatening Content filter also uses regular expressions from
the Black list to identify attack signatures in request messages.
For more details on running regular expressions, see the following topics:
|
Caches
|
|
It is possible to configure the Enterprise Gateway to cache responses from a
back-end Web Service. So, for example, if the Enterprise Gateway receives 2
successive identical requests it can (if configured) take the response
for this request from the cache instead of routing the request on to the
Web Service and asking it to generate the response again.
As a result, excess traffic is diverted from the Web Service making it
more responsive to requests for other services, the Enterprise Gateway is saved
the processing effort of routing identical requests unnecessarily to
the Web Service, and the client benefits from the far shorter response
time.
Local caches can be configured for each running instance of the
Enterprise Gateway. If you have deployed multiple Enterprise Gateways throughout your
network, it is possible to configure a distributed cache where cache
events on one cache are replicated across all others. So, for example,
if a response message is cached at one instance of the Enterprise Gateway, it
will be added to all other caches.
For more information on how the Enterprise Gateway can be configured to use
local and distributed caches, please refer to the
Global Caches help page.
|
|