Overview
|
|
The Enterprise Gateway supports a wide range of common authentication schemes,
including SSL, XML Signatures, WS-Security Username tokens, and HTTP
Authentication. With SSL, the client authenticates to the Enterprise Gateway using
a client certificate. With XML Signatures, the client is authenticated
by validating the signature contained within the XML message. However,
when the Enterprise Gateway attempts to authenticate a client using a username and
password (for example, WS-Security Username tokens and HTTP Authentication), it
must compare the username and password presented by the client to those
stored in the Oracle Authentication Repository.
The Authentication Repository acts as a repository for
Users. Users serve many roles in
the Enterprise Gateway. For example, they can be used to carry out certain
privileged tasks, such as generating reports and remotely viewing logging
data remote logging. Similarly, clients whose username and password
combinations are stored in the Authentication Repository
can authenticate to the Enterprise Gateway using that username and password
combination. For more information on Users, see the
Enterprise Gateway Users tutorial.
The Authentication Repository can be maintained in
the Enterprise Gateway's local configuration store, in an LDAP directory, or
in a range of third-party Identity Management products and services.
When a user has been successfully authenticated against one of these
repositories, the Enterprise Gateway can use any one of that user's stored
attributes (for example, DName, email address, username) to authorize
that same user in a subsequent Authorization Filter.
For example, this credential mapping is useful in
cases where your client-base uses username-password combinations for
authentication (authentication attributes), yet
their access rights must be looked up in an authorization server using
the client's DName (authorization attribute). In
this way, the client possesses a single virtual identity
within the Enterprise Gateway. The client can use one "identity" for authentication,
and another for authorization, yet the Enterprise Gateway sees both identities
as representing the same client.
You can add a new repository on the External Connections tab by
right-clicking the appropriate node (for example, Database Repositories),
and selecting Add a new Repository. Similarly, you can edit an existing
repository by right-clicking the repository node (for example, the default Local
User Store), and selecting Edit Repository.
|
Local Repositories
|
|
The Authentication Repository can be maintained in the
same database that the Enterprise Gateway uses to store all its configuration
information. To edit the default user store, select Local Repositories
-> Local User Store -> Edit Repository. Alternatively, to create a new
user store, select Local Repositories -> Add a new Repository.
You can enter an appropriate name for the repository in the Repository
Name field. The Authorization Attribute Format field
enables administrators to specify whether to use the client's X.509
Distinguished Name or User Name in subsequent
Authorization Filters. If User Name is selected, the
user name used by the client to authenticate to the Enterprise Gateway is used
in any configured Authorization filters. If X.509 Distinguished
Name is selected, the X.509 DName stored by the Enterprise Gateway for
that user is used for subsequent authorization.
For example, if the administrator selected User Name from the
Authorization Attribute Format drop-down list, admin
(the User Name field) is used for authorization. Alternatively,
if X.509 Distinguished Name is selected, the X.509 DName is used
for authorization (for example, O=Company, OU=comp, EMAIL=emp@company.com,
CN=emp).
For more information on adding and configuring users to the Authentication
Repository, see the Users tutorial.
|
LDAP Repositories
|
|
In cases where an organization stores user profiles in an LDAP
directory, it does not make sense to re-enter those profiles into the
default Enterprise Gateway store. Rather, the Enterprise Gateway can leverage an
existing LDAP directory by querying it for user profile data. If a
user's profile can be retrieved and you can bind to the LDAP directory
as that user, the user is authenticated.
When a filter is configured to authenticate a user against an LDAP
repository using a username and password combination, the following
steps occur:
-
A pooled LDAP connection with details corresponding to the
repository selected in the LDAP Directory field
is retrieved.
-
A search filter (for example,
(&(objectClass={User})
(sAMAccountName={c05vc}))) is run using the retrieved connection.
Attributes configured in the
Login Authentication Attribute and
Authorization Attribute fields are also retrieved
in the same search operation.
For example, if Distinguished Name is selected from the
drop-down list, the user's DName is retrieved from the LDAP directory.
The user's DName uniquely identifies the user in the LDAP directory,
and is used to bind to the directory so that the user's password
can be verified. The attribute specified in the Login
Authentication Attribute field is used for the bind operation
when you bind as any user. The value of the LDAP attribute specified in
the Authorization Attribute field is stored in the
authentication.subject.id and may be used by subsequent
filters in the circuit (for example, by authorization filters to authorize
the authenticated user).
-
If no results are returned from the search, the user has not been
found in the directory. It is important that the administrator
user configured on the Configure LDAP Server
screen has the ability to see the user you are attempting to
authenticate.
-
If multiple results (users) are returned from the search, an
attempt is made to bind to the directory using each
Login Authentication Attribute value retrieved
from the search, together with the password from the message.
-
If more than one user is authenticated correctly, an error is
returned because you only want to authenticate a single user.
-
If no user is authenticated, an error is returned.
-
If a single user's Login Authentication Attribute
value and password binds successfully to the directory,
authentication has succeeded.
-
Any successful bind is immediately closed.
To create a new LDAP repository, right click LDAP Repositories
and select Add a new Repository. The details entered on the
Authentication Repository screen depend on the type of LDAP
directory that you are using. The Policy Studio has default entries for some of
the more common LDAP directories, which are available from the drop-down lists
on the screen. However, you can also connect to alternative LDAP directories.
The following sections demonstrate how to configure this screen for typical user
searches on three common LDAP servers:
|
Sun iPlanet Directory Server
|
|
The following instructions explain the values entered here:
-
Enter a suitable name for this user store in the
Repository Name field.
-
Click Add/Edit to add details of your iPlanet
Directory Server.
The User Search Conditions section instructs the Enterprise Gateway
to search the LDAP tree according to certain conditions.
-
Base Criteria:
The specifies where the Enterprise Gateway should begin searching the LDAP
directory.
-
User Class:
This is the name given by the particular LDAP directory to the
User class. For iPlanet, select
'inetorgperson' LDAP Class from the drop-down list.
-
User Search Attribute:
The value entered depends on the type of LDAP directory to which you
are connecting. When a user is stored in an LDAP directory, a number
of user attributes are stored along with that
user. One of these attributes corresponds to the user name presented
by the client for authentication. However, different LDAP directories use different
names for that user attribute. For iPlanet, select cn
from the drop-down list.
-
Allow Blank Passwords:
Check this box to allow the use of blank passwords.
In the next section, you need to specify the following:
-
Login Authentication Attribute:
In an LDAP directory tree, there must be one user attribute that
uniquely distinguishes any one user from all the others. This is
usually the Distinguished Name of the user, however this is called
different things in different LDAP directories. In iPlanet, the
Distinguished name is referred to as the entrydn,
so select Entry Domain Name in this drop-down list
to uniquely identify the client authenticating to the Enterprise Gateway.
-
Authorization Attribute:
When the client has been successfully authenticated, you can
use any one of that user's stored attributes in a subsequent
Authorization Filter. In this case, you want to use the
user's Distinguished Name for an Authorization filter, so enter
entrydn in the text box. However, you can enter
any user attribute as long as the subsequent Authorization filter
supports it. The value of the LDAP attribute specified is
stored in the authentication.subject.id
Oracle message attribute.
-
Authorization Attribute Format:
Because any user attribute can be specified in the Authorization
Attribute above, it is necessary to inform the Enterprise Gateway of
the type of this attribute. This information is used internally by the
Enterprise Gateway in subsequent Authorization filters. Select X.509
Distinguished Name from the drop-down list.
|
Microsoft Active Directory Server
|
|
This section describes how to configure the Authentication Repository
dialog for Microsoft Active Directory Server. It is important to note how the values
entered here differ from those entered when interfacing to the iPlanet Directory Server.
-
Repository Name:
Enter a suitable name for this search.
-
LDAP Directory:
Click Add/Edit to add details of your Active
Directory Server.
The User Search Conditions instruct the Enterprise Gateway to
search the LDAP tree according to certain criteria. The values
entered/selected are different from those selected for iPlanet,
because Active Directory Server uses different attributes and classes to
iPlanet.
-
Base Criteria:
The base criteria specify the base object under which to search
for the user's profile.
-
User Class:
In Active Directory Server, the user class is simply called
User, so select 'User' LDAP
Class from this drop-down list.
-
User Search Attribute:
This field specifies the name of the user attribute whose value
corresponds to the user name entered by the client during a
successful authentication process. With Active Directory Server,
this attribute is called givenName and it
represents the name of the user. Enter givenName
in this drop-down list.
-
Login Authentication Attribute:
Enter the name of the user attribute that uniquely identifies the user
in the LDAP directory. This attribute is the Distinguished Name and is
called distinguishedName in Active Directory Server.
Select Distinguished Name from the drop-down list to
uniquely identify the user. The Enterprise Gateway authenticates the username
and password presented by the client against the values stored for
the user identified in this field.
-
Authorization Attribute:
When the client has been successfully authenticated, the Enterprise Gateway
can use any of that user's stored attributes in subsequent Authorization
filters. Because most Authorization filters require a Distinguished Name,
enter Distinguished Name in the text box. However,
any user attribute could be entered here, as long as the subsequent
Authorization filter supports it.
-
Authorization Attribute Format:
The Enterprise Gateway needs to know the format of the Authorization
Attribute. Select X.509 Distinguished Name from
the drop-down list.
|
IBM Directory Server
|
|
The configuration details for IBM Directory Server deserve a special
mention as an example of a directory server that does not return a full
Distinguished Name (DName) as the result of a standard LDAP user search.
Instead, it returns a contextualized DName, which is
relative to the specified Base Criteria. In such cases,
the Enterprise Gateway can build up the full DName by combining the Base
Criteria and the returned name. The following example shows how
this works in practice.
If C=IE is specified as the Base Criteria,
the IBM Directory Server returns CN=niall, OU=Dev, instead of
the full DName, which is C=IE, CN=niall, OU=Dev. To enable the
Enterprise Gateway to do this, leave the Login Authentication Attribute
field blank. The Enterprise Gateway then automatically concatenates the specified
Base Criteria (C=IE) with the contextualized
DName returned from the directory server (CN=niall, OU=Dev) to
obtain the fully qualified DName (C=IE, CN=niall, OU=Dev).
You can also leave the Authorization Attribute field blank,
which enables the Enterprise Gateway to automatically use the fully qualified
DName for subsequent Authorization Filters. You should select
X.509 Distinguished Name from the Authorization
Attribute Format drop-down list.
|
Database Repositories
|
|
The Enterprise Gateway can store its Authentication Repository in
an external database. This option makes sense when an organization
already has a silo of user profiles stored in the database and does
not want to duplicate this store within the Enterprise Gateway's local configuration
storage.
To authenticate users against a database repository, right click Database
Repositories, and select Add a new Repository. Complete
the following fields on the Authentication Repository dialog:
Repository Name:
Enter an appropriate name for the database in the Repository
Name field.
Database:
There are two basic configuration items required to retrieve a user's
profile from the database:
-
Database Location:
You can configure connection details for the database by clicking
Add, and completing the Database Connection
dialog. For details on configuring the fields on this dialog, see the
Database Connection topic.
You can edit or remove previously configured database connections
by selecting them in the drop-down list and clicking Edit or
Delete.
-
Database Query:
The Database Query retrieves a specific
user's profile from the database to enable the Enterprise Gateway to
authenticate them. Having successfully authenticated the user,
you can select an attribute of this user to use for the authorization
filter later in the policy. The Database Query can take
the form of an SQL statement, stored procedure, or function call. For
details on how to configure the Database Query, see the Database Query topic.
Format Password Received From Client:
If the user sends up a clear-text password to the Enterprise Gateway, but that
user's password is stored in a hashed format in the database, it is
the Enterprise Gateway must hash the password before performing the
authentication step.
-
Hash Client Password:
Depending on whether you wish to hash the user's submitted password,
select the appropriate radio button.
-
Hash Format:
If you have selected to hash the client's password, the Enterprise Gateway
needs to know the format of the hashed password. The most typical
formats are available from the drop-down list, however, you can also
enter another format. Formats should be entered in terms of message
attributes. The following formats are available from the Hash
Format drop-down list. The first option combines the username,
authentication realm, and password respectively. This combination is then
hashed. The second option simply creates a hash of the user's password.
|
| | |
|
${authentication.subject.id}:${authentication.subject.realm}:${authentication.subject.password}
${authentication.subject.password}
| |
| | |
|
-
Hash Algorithm:
Select either MD5 or SHA1 to use
as the digest algorithm to use when creating the hash.
Query Result Processing:
This section enables you to provide the Enterprise Gateway with some
meta information about the result returned by the Database
Query configured earlier on this screen. It enables allows
you to identify the name of the database table column or row that contains
the user's password, and also the name of the column or row that contains
the attribute that is to be used for the authorization filter.
-
Password Column:
Specify the name of the database table column that contains the
user's password. The contents of this column are compared to
the password submitted by the user.
-
Password Type:
Depending on how the user's password has been stored in the
database, select either Clear Password or
Digest Password from the drop-down list.
-
Authorization Attribute Column:
By running the Database Query, all of the user's
attributes are returned. Only the user's username and password are
used for the authentication event. You can also use one of the other
user's attributes for authorization at a later stage in the policy.
The additional authorization attribute should be either a username
or an X.509 distinguished name (DName). The name of the column
containing either the username or the Dname should be entered here,
but only if this value is required for authorization purposes.
-
Authorization Attribute Format:
The Enterprise Gateway's authorization filters all operate on the basis of a
username or DName. They all evaluate whether a user identified by a
username or DName is allowed to access a specific resource. Select
the appropriate format from the drop-down list depending on what type
of user credential is stored in the database table column entered above.
|
CA SiteMinder Repositories
|
|
In cases where user profiles have been stored in an existing SiteMinder
server, the Enterprise Gateway can query SiteMinder to authenticate users.
To authenticate users against a CA SiteMinder repository, right-click CA
SiteMinder Repositories, and select Add a new Repository.
Complete the following fields on the Authentication Repository dialog:
Repository Name:
Enter a suitable name for this repository.
Agent Name:
Select a previously configured SiteMinder Agent name from the drop-down list.
Click Add to register a new agent. Complete the following
fields in the SiteMinder Connection Details dialog:
-
Agent Name:
Enter the name of the agent to connect to SiteMinder in the
Agent Name field. This name must
correspond with the name of an agent that was previously configured
in the Policy Server.
-
Agent Configuration Object:
The name entered must match the name of the Agent Configuration
Object (ACO) configured in the Policy Server. The Enterprise Gateway
currently does not support any of the features represented by the
ACO parameters except for the PersistentIPCheck setting.
For example, the Enterprise Gateway disregards the DefaultAgent
parameter and uses the agent value it collects separately during agent
registration.
When the PersistentIPCheck ACO parameter is set to
yes, it instructs the Enterprise Gateway to compare the IP address
from the last request (stored in a persistent cookie) with the IP address
in the current request to see if they match. If the IP addresses do not
match, the Enterprise Gateway rejects the request. If this parameter is
set to no, this check is disabled.
-
Connection Details:
For more information on configuring this section, please
refer to the instructions in the
SiteMinder Connection Details section of the
SiteMinder Certificate Authentication
help page.
Resource:
Enter the name of the protected resource for which the user must
be authenticated.
Alternatively, you can enter a property representing a message attribute,
which is looked up and expanded to a value at runtime. Properties have the
following format:
For example, to specify the original path on which the request was
received by the Enterprise Gateway as the resource, enter the following property:
Action:
The user must be authenticated for a specific action on the
protected resource. By default, this action is taken from the HTTP
verb used in the incoming request. You can use the following property
to get the HTTP verb:
|
| | |
|
${http.request.verb}<br/>
| |
| | |
|
Alternatively, you can enter any user-specified value.
Create Single Sign-On Token:
When this option is selected, SiteMinder generates a single sign-on token
as part of the authentication event and returns it to the Enterprise Gateway.
This is then inserted into the downstream message for re-use later, either
by another instance of the Enterprise Gateway running the SiteMinder Session
Validation filter, or by another SiteMinder-aware agent.
Put Token in Message Attribute:
Enter the name of the message attribute where you wish to store the single
sign-on token. By default, the token is stored in the
siteminder.session attribute. Please refer to the
Message Attribute Reference
for a complete list of available message attributes.
|
Tivoli Repositories
|
|
The Enterprise Gateway can integrate with Tivoli Access Manager to authenticate users.
To authenticate users against a Tivoli repository, right-click Tivoli
Repositories, and select Add a new Repository.
For more information on how to configure Enterprise Gateway to communicate with a Tivoli
server, see the Tivoli Integration
topic.
|
|