> Installation Guide > External Accounts Integration

Installation Guide

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

External Accounts Integration

During database installation or by employing the Setup tool, you may choose to use accounts from external repositories. This chapter describes how to integrate accounts from an LDAP server and from non-LDAP user stores into BEA AquaLogic Service Registry.

An LDAP server can be integrated with BEA AquaLogic Service Registry with these scenarios:

For information about configuring LDAP scenarios, see LDAP.

This chapter also contains the following configuration examples:

Notes: 1. BEA AquaLogic Service Registry treats external stores as read-only. User account properties stored in these external stores cannot be modified by BEA AquaLogic Service Registry.
Note: 2. The Administrator account must not be stored in the LDAP. We strongly recommend that users stored in account_list.xml (by default, only administrator) should not be in the LDAP. If you really need to have users from LDAP in the file account_list.xml, delete password items from the file and change of all the accounts' properties according to the LDAP. The account_list.xml file contains a list of users that can be logged into a registry without connection to the database.

To integrate external accounts from another repository, either:

See the command-line parameters for Setup in Command Line Scripts.

Figure 11-1 Setup Select Authentication Account Provider

Setup Select Authentication Account Provider

For more information on the Setup tool, please see Reconfiguration After Installation.

 

LDAP

Select LDAP on the Account Provider panel.

Figure 11-2 Select LDAP

Select LDAP

Enter the settings as described in the following figure.

Figure 11-3 LDAP Service

LDAP Service

BEA AquaLogic Service Registry uses a JNDI interface to connect to LDAP servers. The following JNDI properties must be known to the server. (The default properties are noted in parentheses.)

Java naming provider URL

A URL string for configuring the service provider specified by the "Java naming factory initial" property. (ldap://hostname:389).

Initial Naming Factory

Class name of the initial naming factory. (com.sun.jndi.ldap.LdapCtxFactory).

Security Principal

The name of the principal for anonymous read access to the directory service.

Password

Password of security principal.

Security Protocol

Name of the security protocol. (simple)
Figure 11-4 LDAP Usage Scenarios


LDAP Usage Scenarios

You can select the following LDAP usage scenarios:

LDAP with a single search base

The scenario is very simple. There is only one LDAP server in this scenario. All identities are stored under a single search base.

LDAP with multiple search bases

In this scenario there is also only one LDAP server, but it has multiple search bases mapped to a domain. The domain is a specified part of user's login name (that is, DOMAIN/USERNAME). All users must specify the domain name in the login dialog. During the managing with accounts or groups it is recommended to use DOMAIN/USERNAME because of performance. If no domain is set then search is performed across all domains.
Domains can be specified dynamically or statically. For dynamic settings it is necessary to specify, for example, a domain prefix or postfix. Static domains are set during the installation directly and so they must be known in time of installation.

Multiple LDAP services

More than one LDAP service are used in this scenario. The correct LDAP service is chosen via DNS. As in the previous scenario, users must specify a domain name during login. When managing accounts or groups users have to set domain name. If domain name is not specified then no domain is processed.
Note: Automatic discovery of the LDAP service using the URL's distinguished name is supported only in Java 2 SDK, versions 1.4.1 and later, so be sure of the Java version you are using.
Note: The automatic discovery of LDAP servers allows you not to hardwire the URL and port of the LDAP server. For example, you can use ldap:///o=JNDITutorial,dc=example,dc=com as a URL and the real URL will be deduced from the distinguished name o=JNDITutorial,dc=example,dc=com.
Note: BEA AquaLogic Service Registry integration with LDAP uses the JNDI API. For more information, see
Note: http://java.sun.com/products/jndi/tutorial/ldap/connect/create.html
Note: and
Note: http://java.sun.com/j2se/1.4.2/docs/guide/jndi/jndi-dns.html#URL

LDAP with a Single Search Base

The installation consists of the following steps:

  1. Specify user/account search properties as shown in Figure 11-5.
  2. Map Registry user properties to LDAP properties as shown in Figure 11-6.
  3. Specify group search properties as shown in Figure 11-7.
  4. Map Registry group properties to LDAP properties as shown in Figure 11-8.
    5. Figure 11-5 User Search Properties


    User Search Properties

Field description:

Search Filter

The notation of the search filter conforms to the LDAP search notation. You can specify the LDAP node property that matches the user account.

Search Base

LDAP will be searched from this base including the current LDAP node and all possible child nodes.

Search Scope

Here you can specify how deep the LDAP tree structure's data will be searched.
- Object Scope - Only the search base node will be searched. - One-level Scope - Only direct sub-nodes of the search base (entries one level below the search base) will be searched. The base entry is not included in the scope. - Subtree Scope - Search base and all its sub-nodes will be searched.

Results Limit

Number of items returned when searching LDAP.
Figure 11-6 User Properties Mapping


User Properties Mapping

You can specify mapping between BEA AquaLogic Service Registry user account properties and LDAP properties. You can add rows by clicking Add. To edit an entry, double click on the value you wish to edit.

The following user account properties can be mapped from an LDAP server.

Listing 11-1 Account Properties can be Mapped from an LDAP Server 
java.lang.String loginName
java.lang.String email
java.lang.String fullName
java.lang.String languageCode
java.lang.String password
java.lang.String description
java.lang.String businessName
java.lang.String phone
java.lang.String alternatePhone
java.lang.String address
java.lang.String city
java.lang.String stateProvince
java.lang.String country
java.lang.String zip
java.util.Date expiration
java.lang.Boolean expires
java.lang.Boolean external
java.lang.Boolean blocked
java.lang.Integer businessesLimit
java.lang.Integer servicesLimit
java.lang.Integer bindingsLimit
java.lang.Integer tModelsLimit
java.lang.Integer assertionsLimit
java.lang.Integer subscriptionsLimit

The Registry account property dn specifies the LDAP distinguished name. The value depends on the LDAP vendor.

If an optional property (such as email) does not exist in the LDAP, then the property's value is set according to the default account. The default account is specified in the configuration file whose name is account_core.xml.

Note: User account properties that you specify at the Figure 11-6 will be treated as read-only from Registry Console and registry APIs.

For more information, please see "userAccount data structure" in the Developer's Guide in Using the AquaLogic Service Registry.

Figure 11-7 Group Search Properties

Group Search Properties

Field Description

Search Filter

The notation of the search filter conforms to LDAP search notation. You can specify the LDAP node property that matches the group.

Search Base

LDAP, including the current LDAP node and possible all child nodes, will be searched from this base.

Search Scope

Here you can specify how deep the LDAP tree structure data will be searched.
- Object Scope - Only the search base node will be searched. - One-level Scope - Search base and its direct sub-nodes will be searched. - Subtree Scope - Search base and all its sub-nodes will be searched.
Figure 11-8 Group Properties Mapping


Group Properties Mapping

You can specify mapping between BEA AquaLogic Service Registry group properties and LDAP properties. You can add rows by clicking Add. To edit an entry, double click on the value you wish to edit.

If a property (such as description) does not exist in the LDAP then property value is set according to the default group. The default group (groupInfo) is specified in the configuration file whose name is group.xml.

For more information, please see"group data structure" in the Developer's Guide in Using the AquaLogic Service Registry.

LDAP with Multiple Search Bases

The installation consists of the following steps:

  1. Specify the domain delimiter, domain prefix and postfix as shown in Figure 11-9.
  2. Enable/Disable domains as shown in Figure 11-10.
  3. Specify User Search properties as shown in Figure 11-5.
  4. Map Registry user properties to LDAP properties as shown in Figure 11-6
  5. Specify group search properties as shown in Figure 11-7.
  6. Map Registry group properties to LDAP properties as shown in Figure 11-8
    7. Figure 11-9 LDAP Delimiter


    LDAP Delimiter

Field descriptions:

Domain Delimiter

Specifies the character that delimits domain and user name. When left empty, users are searched from all domains.

Domain Prefix, Domain Postfix

Domains are searched using the following pattern:
{domain prefix}domain_name{domain postfix}{search base} where {domain prefix} is value of property whose name is domain prefix, {domain postfix} is value of property whose name is domain postfix and {searchbase} is value of property whose name is searchbase.
Figure 11-10 Enable/Disable Domains


Enable/Disable Domains

Enable Domains

Left column: domain name that users will be using during login. Right column: distinguished domain name.

Disable Domains

Enter distinguished domain name of domains you wish to disable.

Multiple LDAP Services

The correct LDAP service is chosen via DNS. The installation consists of the following steps:

  1. Specify user/account search properties as shown in Figure 11-5.
  2. Map Registry user properties to LDAP properties as shown in Figure 11-6.
  3. Specify group search properties as shown in Figure 11-7.
  4. Map Registry group properties to LDAP properties as shown in Figure 11-8

LDAP over SSL/TLS

It is only a matter of configuration to setup LDAP over SSL (or TLS) with a directory server of your choice. We recommend that you first install BEA AquaLogic Service Registry with a connection to LDAP that does not use SSL. You can then verify the configuration by logging in as a user defined in this directory before configuring use of SSL.

The configuration procedure assumes that you have already installed BEA AquaLogic Service Registry with an LDAP account provider. BEA AquaLogic Service Registry must not be running.

LDAP over SSL Without Client Authentication

In this case only LDAP server authentication is required. This is usually the case.

Edit the REGISTRY_HOME/app/uddi/conf/directory.xml file in one of the following ways depending on the version of Java used to run BEA AquaLogic Service Registry:

This is shown in the following example:

Listing 11-2 
<config name="directory" savingPeriod="5000">
  <directory>
    <!-- LDAP over (SSL/TLS) unprotected connection -->
    <!--
    <property name="java.naming.provider.url" value="ldap://hostname:47361"/>
    -->
    <!-- LDAP over SSL/TLS for Java 1.4.2 and later -->
    <!--
    <property name="java.naming.provider.url" value="ldaps://hostname:636"/>
    -->
    <!-- LDAP over SSL/TLS for Java where LDAP over SSL is supported -->
    <property name="java.naming.provider.url" value="ldap://hostname:636"/>
    <property name="java.naming.security.protocol" value="ssl"/>
    ...
    ...
    ...
  </directory>
</config>

In both cases, be sure that the hostname specified in the java.naming.provider.url property matches the name that is in the directory server certificate's subject common name (CN part of certificate's Subject). Otherwise you will get an exception during startup of BEA AquaLogic Service Registry. It will inform you of a hostname verification error. The stack trace contains the hostname that you must use.

LDAP over SSL With Mutual Authentication

BEA AquaLogic Service Registry does not support LDAP over SSL with mutual authentication.

Ensuring Trust of the LDAP Server

The client that connects to the SSL/TLS server must trust the server certificate in order to establish communication with that server. The configuration of LDAPS explained above inherits the default rule for establishing trust from JSSE (the Java implementation of SSL/TLS). This is based on trust stores.

When a trust store is needed to verify a client/server certificate, it is searched for in the following locations in order:

  1. The file specified by the javax.net.ssl.trustStore system property, if defined;
  2. Otherwise the file JAVA_HOME\jre\lib\security\jssecacerts if it exists;
  3. Otherwise the file JAVA_HOME\jre\lib\security\cacerts if it exists;

It is recommended to use the first option to define a trust store specifically for the application you are running. In this case, you have to change the command that starts the registry (or the JVM environment of the ported registry) to define the following Java system properties:

Table 11-1 Java System Properties
Property
Description
javax.net.ssl.trustStore
Absolute path of your trust store file.
javax.net.ssl.trustStorePassword
Password for the trust store file.

To ensure that the server certificate is trusted, you have to:

  1. Contact the administrator of the LDAP server and get the certificate of the server or the certificate of the authority that signed it.
  2. Import the certificate into the trust store of your choice using the Java keytool:
    3. keytool -import -trustcacerts -alias alias -file file -keystore keystore 
-storepass storepass

    where the parameters are as follows:

alias

A mandatory, unique alias for the certificate in the trust store;
The file containing the certificate (usually with .crt extension);
The keystore file of your choice;
A password designed to protect the keystore file from tampering. Java level keystores (cacerts and jssecacerts) usually require the password changeit;

file

The file containing the certificate (usually with .crt extension);
The keystore file of your choice;
A password designed to protect the keystore file from tampering. Java level keystores (cacerts and jssecacerts) usually require the password changeit;

keystore

The keystore file of your choice;
A password designed to protect the keystore file from tampering. Java level keystores (cacerts and jssecacerts) usually require the password changeit;

storepass

A password designed to protect the keystore file from tampering. Java level keystores (cacerts and jssecacerts) usually require the password changeit;

LDAP Configuration Examples

The following configuration examples are included in this section:

SUN One with Single Search Base

In this example, we show how to configure a Sun One Directory Server 5.2 under the LDAP with a Single Search Base scenario.

SUN One with Single Search Base shows user properties that are stored in the LDAP server.

Figure 11-11 User Properties in LDAP

User Properties in LDAP

SUN One with Single Search Base shows group properties that are stored in the LDAP server.

Figure 11-12 Group Properties in LDAP

Group Properties in LDAP

The following table shows how to configure BEA AquaLogic Service Registry using this scenario.

Table 11-2 SUN One with Single Search Base Configuration
Configuration Property
Configuration Value
See
Java naming provider URL
ldap://localhost:389
Figure 11-3
Initial Naming Factory
com.sun.jndi.ldap.LdapCtxFactory
Figure 11-3
Security Principal
uid=JPatroni,ou=people,dc=in,dc=idoox,dc=com
Figure 11-3
Security Protocol
simple
Figure 11-3
User Properties
   
Search Filter
objectClass=person
Figure 11-5
Search Base
ou=people,dc=in,dc=idoox,dc=com
Figure 11-5
Search Scope
Subtree Scope
Figure 11-5
Result Limit
100
Figure 11-5
telephoneNumber
phone
Figure 11-6
uid
loginName
Figure 11-6
cn
fullName
Figure 11-6
mail
mail
Figure 11-6
Group Properties
   
Search Filter
objectClass=groupofuniquenames
Figure 11-7
Search Base
ou=groups,dc=in,dc=idoox, dc=com
Figure 11-7
Search Scope
Subtree Scope
Figure 11-7
Result Limit
100
Figure 11-7
creatorsName
Owner
Figure 11-8
description
description
Figure 11-8
uniqueMember
member
Figure 11-8
cn
name
Figure 11-8

Sun One with Multiple Search Bases

In this example, we show how to configure Sun One Directory Server 5.2 with multiple search bases. In Figure 11-14, you can see users and domains that are stored on the LDAP server. We want to configure the LDAP integration with BEA AquaLogic Service Registry in this way:

Figure 11-14 shows how users from LDAP are mapped to BEA AquaLogic Service Registry

Figure 11-13 LDAP Users and Groups

LDAP Users and Groups

Figure 11-14

The following table shows how to configure BEA AquaLogic Service Registry using this scenario.

Table 11-3
Configuration Property
Configuration Value
See
Java naming provider URL
ldap://localhost:389
Figure 11-3
Initial Naming Factory
com.sun.jndi.ldap.LdapCtxFactory
Figure 11-3
Security Principal
uid=JPatroni,ou=people,dc=in,dc=idoox,dc=com
Figure 11-3
Security Protocol
simple
Figure 11-3
uddi.ldap.domain.delimiter
/
Figure 11-9
uddi.ldap.domain.prefix
ou=
Figure 11-9
uddi.ldap.domain.postfix
leave empty
Figure 11-9
Enable domains
   
domain name
domain3
Figure 11-10
Distinguished name
ou=domain10,ou=example,dc=in,dc=idoox,dc=com
Figure 11-10
Disable domains
   
Distinguished name
ou=domain2,ou=example,dc=in,dc=idoox,dc=com
Figure 11-10
User Properties
   
Search Filter
objectClass=person
Figure 11-5
Search Base
ou=people,dc=in,dc=idoox,dc=com
Figure 11-5
Search Scope
Subtree Scope
Figure 11-5
Result Limit
100
Figure 11-5
telephoneNumber
phone
Figure 11-6
uid
loginName
Figure 11-6
cn
fullName
Figure 11-6
mail
mail
Figure 11-6
Group Properties
   
Search Filter
objectClass=groupofuniquenames
Figure 11-7
Search Base
ou=groups,dc=in,dc=idoox, dc=com
Figure 11-7
Search Scope
Subtree Scope
Figure 11-7
Result Limit
100
Figure 11-7
creatorsName
Owner
Figure 11-8
description
description
Figure 11-8
uniqueMember
member
Figure 11-8
cn
name
Figure 11-8
SUN One with Multiple Search Base Configuration

Active Directory with Single Search Base

In this example, we show how to configure an Active Directory with a single search base. Figure 11-15 shows group properties that are stored in the Active Directory. These group properties will be mapped to BEA AquaLogic Service Registry as shown in Figure 11-16.

Figure 11-15 LDAP User Group

LDAP User Group

Figure 11-16 User Group in BEA AquaLogic Service Registry

User Group in BEA AquaLogic Service Registry

The following figure shows user properties that are stored in the Active Directory. These user properties will be mapped to BEA AquaLogic Service Registry as shown in Figure 11-16.

Figure 11-17 LDAP User Properties

LDAP User Properties

Figure 11-18 User Properties in BEA AquaLogic Service Registry

User Properties in BEA AquaLogic Service Registry

The following table shows how to configure BEA AquaLogic Service Registry using this scenario.

Table 11-4

Configuration Property
Configuration Value
See
Java naming provider URL
ldap://localhost:389
Figure 11-3
Initial Naming Factory
com.sun.jndi.ldap.LdapCtxFactory
Figure 11-3
Security Principal
CN=userx,OU=root,DC=registry,DC=in,DC=mycompany,DC=com
Figure 11-3
Security Protocol
DIGEST-MD5
Figure 11-3
User Properties
   
Search Filter
objectClass=person
Figure 11-5
Search Base
ou=example,dc=registry,dc=in,dc=mycompany,dc=com
Figure 11-5
Search Scope
Subtree Scope
Figure 11-5
Result Limit
100
Figure 11-5
telephoneNumber
phone
Figure 11-6
uid
loginName
Figure 11-6
cn
fullName
Figure 11-6
mail
mail
Figure 11-6
Group Properties
   
Search Filter
objectClass=group
Figure 11-7
Search Base
ou=example,dc=registry,dc=in,dc=mycompany,dc=com
Figure 11-7
Search Scope
Subtree Scope
Figure 11-7
Result Limit
100
Figure 11-7
memberq
member
Figure 11-8
cn
name
Figure 11-8
uniqueMember
member
Figure 11-8
cn
name
Figure 11-8

 

Custom (Non-LDAP)

Select External on the Advanced Account Settings panel.

Figure 11-19 External and Advanced Account Settings Panel

External and Advanced Account Settings Panel

External accounts require implementation of the interface org.systinet.uddi.account.ExternalBackendApi.


  Back to Top       Previous  Next