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:
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 the user's login name (that is, DOMAIN/USERNAME). All users must specify the domain name in the login dialog. When managing accounts or groups, we recommend using the DOMAIN/USERNAME format for performance reasons. If no domain is set, searches are performed across all domains.
Multiple LDAP services - More than one LDAP service is 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 the domain name is not specified, then no domain is processed.
This chapter also contains the following configuration examples:
![]() | Note |
---|---|
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. |
![]() | Important |
---|---|
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:
Create a database or create a new schema on the connected database by following the instructions in Database Settings, or
Use the Setup tool and choose Authentication provider. To run the Setup tool, execute the following script from the bin subdirectory of your installation:
Windows: | setup.bat |
UNIX: | ./setup.sh |
See command-line parameters in Setup.
For more information on the Setup tool, please see Reconfiguring After Installation.
Select LDAP on the Account Provider panel.
Enter the following settings:
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.)
A URL string for configuring the service provider specified by the "Java naming factory initial" property. (ldap://hostname:389).
Class name of the initial naming factory. (com.sun.jndi.ldap.LdapCtxFactory).
The name of the principal for anonymous read access to the directory service.
Password of security principal.
Name of the security protocol. (simple)
You can select the following LDAP usage scenarios:
The scenario is very simple. There is only one LDAP server in this scenario. All identities are stored under a single search base.
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.
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. 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. BEA AquaLogic Service Registry integration with LDAP uses the JNDI API. For more information, see http://java.sun.com/products/jndi/tutorial/ldap/connect/create.html and http://java.sun.com/j2se/1.4.2/docs/guide/jndi/jndi-dns.html#URL |
The installation consists of the following steps:
Field description:
The notation of the search filter conforms to the LDAP search notation. You can specify the LDAP node property that matches the user account.
LDAP will be searched from this base including the current LDAP node and all possible child nodes.
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 - Search base and its direct sub-nodes will be searched.
Subtree Scope - Search base and all its sub-nodes will be searched.
Number of items returned when searching LDAP.
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:
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
![]() | Important |
---|---|
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 config file whose name is account_core.xml. |
![]() | Note |
---|---|
User account properties that you specify at the Figure 34 will be treated as read-only from Registry Console and registry APIs. |
For more information, please see Developer's Guide, userAccount data structure .
Field description:
The notation of the search filter conforms to LDAP search notation. You can specify the LDAP node property that matches the group.
LDAP, including the current LDAP node and possible all child nodes, will be searched from this base.
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.
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 config file whose name is group.xml.
For more information, please see Developer's Guide, group data structure
The installation consists of the following steps:
Specify the domain delimiter, domain prefix and postfix as shown in Figure 37.
Enable/Disable domains as shown in Figure 38.
Specify User Search properties as shown in Figure 33.
Map Registry user properties to LDAP properties as shown in Figure 34.
Specify group search properties as shown in Figure 35.
Map Registry group properties to LDAP properties as shown in Figure 36
Field descriptions:
Specifies the character that delimits domain and user name. When left empty, users are searched from all domains.
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.
Left column: domain name that users will be using during login. Right column: distinguished domain name.
Enter distinguished domain name of domains you wish to disable.
The correct LDAP service is chosen via DNS. The installation consists of the following steps:
In this example, we show how to configure a Sun One Directory Server 5.2 under the LDAP Single Search Base scenario.
SUN One with Single Search Base shows user properties that are stored in the LDAP server.
SUN One with Single Search Base shows group properties that are stored in the LDAP server.
The following table shows how to configure BEA AquaLogic Service Registry using this scenario.
Config Property | Config Value | See |
---|---|---|
Java naming provider URL | ldap://localhost:389 | Figure 31 |
Initial Naming Factory | com.sun.jndi.ldap.LdapCtxFactory | Figure 31 |
Security Principal | uid=JPatroni,ou=people,dc=in,dc=idoox,dc=com | Figure 31 |
Security Protocol | simple | Figure 31 |
User Properties | ||
Search Filter | objectClass=person | Figure 33 |
Search Base | ou=people,dc=in,dc=idoox,dc=com | Figure 33 |
Search Scope | Subtree Scope | Figure 33 |
Result Limit | 100 | Figure 33 |
telephoneNumber | phone | Figure 34 |
uid | loginName | Figure 34 |
cn | fullName | Figure 34 |
Figure 34 | ||
Group Properties | ||
Search Filter | objectClass=groupofuniquenames | Figure 35 |
Search Base | ou=groups,dc=in,dc=idoox,dc=com | Figure 35 |
Search Scope | Subtree Scope | Figure 35 |
Result Limit | 100 | Figure 35 |
creatorsName | owner | Figure 36 |
description | description | Figure 36 |
uniqueMember | member | Figure 36 |
cn | name | Figure 36 |
In this example, we show how to configure Sun One Directory Server 5.2 with multiple search bases. In Figure 42, 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:
Only users from domain1 and domain10 can log into BEA AquaLogic Service Registry. LDAP domain2 will be disabled.
LDAP domain10 will be mapped to the domain3 user group in BEA AquaLogic Service Registry.
Figure 42 shows how users from LDAP are mapped to BEA AquaLogic Service Registry
The following table shows how to configure BEA AquaLogic Service Registry using this scenario.
Config Property | Config value | See |
---|---|---|
Java naming provider URL | ldap://localhost:1000 | Figure 31 |
Initial Naming Factory | com.sun.jndi.ldap.LdapCtxFactory | Figure 31 |
Security Principal | uid=JPatroni,ou=people,dc=in,dc=idoox,dc=com | Figure 31 |
Security Protocol | simple | Figure 31 |
uddi.ldap.domain.delimiter | / | Figure 37 |
uddi.ldap.domain.prefix | ou= | Figure 37 |
uddi.ldap.domain.postfix | leave empty | Figure 37 |
Enable domains | ||
domain name | domain3 | Figure 38 |
Distinguished name | ou=domain10,ou=example,dc=in,dc=idoox,dc=com | Figure 38 |
Disable domains | ||
Distinguished name | ou=domain2,ou=example,dc=in,dc=idoox,dc=com | Figure 38 |
User Properties | ||
Search Filter | objectClass=person | Figure 33 |
Search Base | ou=people,dc=in,dc=idoox,dc=com | Figure 33 |
Search Scope | Subtree Scope | Figure 33 |
Result Limit | 100 | Figure 33 |
telephoneNumber | phone | Figure 34 |
uid | loginName | Figure 34 |
cn | fullName | Figure 34 |
Figure 34 | ||
Group Properties | ||
Search Filter | objectClass=groupofuniquenames | Figure 35 |
Search Base | ou=groups,dc=in,dc=idoox,dc=com | Figure 35 |
Search Scope | Subtree Scope | Figure 35 |
Result Limit | 100 | Figure 35 |
creatorsName | owner | Figure 36 |
description | description | Figure 36 |
uniqueMember | member | Figure 36 |
cn | name | Figure 36 |
In this example, we show how to configure an Active Directory with a single search base. Figure 43 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 44.
Figure 45 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 44.
The following table shows how to configure BEA AquaLogic Service Registry using this scenario.
Config Property | Config value | See |
---|---|---|
Java naming provider URL | ldap://localhost:389 | Figure 31 |
Initial Naming Factory | com.sun.jndi.ldap.LdapCtxFactory | Figure 31 |
Security Principal | CN=userx,OU=root,DC=registry,DC=in,DC=mycompany,DC=com | Figure 31 |
Security Protocol | DIGEST-MD5 | Figure 31 |
User Properties | ||
Search Filter | objectClass=person | Figure 33 |
Search Base | ou=example,dc=registry,dc=in,dc=mycompany,dc=com | Figure 33 |
Search Scope | Subtree Scope | Figure 33 |
Result Limit | 100 | Figure 33 |
sAMAccountName | loginName | Figure 34 |
cn | fullName | Figure 34 |
Figure 34 | ||
telephoneNumber | phone | Figure 34 |
Group Properties | ||
Search Filter | objectClass=group | Figure 35 |
Search Base | ou=example,dc=registry,dc=in,dc=mycompany,dc=com | Figure 35 |
Search Scope | Subtree Scope | Figure 35 |
Result Limit | 100 | Figure 35 |
member | member | Figure 36 |
cn | name | Figure 36 |
uniqueMember | member | Figure 36 |
cn | name | Figure 36 |
Select External on the Advanced Account Settings panel.
External accounts require implementation of the interface org.systinet.uddi.account.ExternalBackendApi.