This article will show you how to introduce different scenarios, the WebSphere Portal V6.1 configuration for different user registry (United user registry, a single isolated registry), as well as multi-user domains and virtual portal to meet business needs.
INTRODUCTION
Through to the WebSphere Portal user registry configuration, you can prevent unauthorized users access to your WebSphere Portal Server. In WebSphere Portal V6.1 to support multiple types of user registry, an arbitrary configuration can be reached to prevent unauthorized users the purpose of the visit. This article will introduce you to different scenes, how to configure WebSphere Portal V6.1 for different user registry (United user registry, a single isolated registry) to meet this demand.
We know, WebSphere Application Server V6.1 introduced a joint user registry function, will be able to multiple storage library user mapped to a virtual storage pool, which makes our repository management more flexible. It is based on WebSphere Portal Server V6.1 has also received the same functionality and make the corresponding expansion. Let us first look at the WebSphere Portal Server types supported by the registry What has changed now (Table 1).
Table 1 WebSphere Portal Server support registry
Registry types
Prior to version 6.1 Version 6.1
Isolated a single Lightweight Directory Access Protocol (LDAP) registry √
√
A single isolated database registry
√
--
Custom user registry interface of a single implementation
√
√
United user registry (document repository)
--
√
United user registry (LDAP repository)
--
√
United user registry (database repository)
--
√
As can be seen from the table, WebSphere Portal Server V6.1 provides a registry of joint user group support, and remove the isolation of a single registry database support.
We can see from Figure 1 that under the WebSphere Portal Server V6.1 supports the type of registry, as well as how the corresponding ConfigEngine mission at a different type of switch between the registry.
ConfigEngine
At version of WebSphere Portal Server V6.1, the introduction of a new configuration framework (ConfigEngine) to replace the previous configuration commands (WPSconfig). ConfigEngine on the Portal provides a component-based management features so that it can on the new plug-and-play components, and from each component to manage their own configuration related tasks, from ConfigEngine to deal with dependencies between components . At
Figure 1. WebSphere Portal Server V6.1 registry type and relationship diagram
From the chart we can see that we can provide the corresponding ConfigEngine mission (the figure above the A, B, C) to achieve
Between different types of registry switch. At the same time, ConfigEngine user registry for the United provides extra mission to add more than one LDAP repository (wp-create-ldap) and the database repository (wp-create-db), we will be at the back of these chapters in detail.
United User Registry
United are a user registry by configuring VMM (virtual user management) to more than one repository of user mapped to a virtual repository approach. United registry is a tree structure, by one or more domain (Realm), each domain by one or more basic items (Base Entry), each corresponding to the basic items of a separate repository (Repository ). To sum up, the user registry can be seen as United by one or several domains consisting of a virtual repository. United about the details of the user registry, see the reference.
Figure 2. Domain / basic items / store the relationship between
Figure 2 shows an example domain, the basic items and the relationship between the repository. In the example, a domain that contains three basic items, corresponding to two of the three repository subtree.
Introduction From the above we can see that the use of United after the user registry can support multiple storage library, and allows you at any time in accordance with business needs to add or delete repositories. In previous versions of this feature to complete all necessary to achieve the user's own custom registry, and now provided by United V6.1 default user registry is no doubt greatly enhance ease of use, at the same time this is WebSphere Portal Server V6. one default user registry type.
Here we look at United under the common user registry function:
• Query the current repository list
• Add LDAP repository
• Add database repository
• Delete repository
• Set default repository
Query the current repository list
WebSphere Portal Server V6.1 using the default user registry is United, and contains a document repository (InternalFileRepository). Note that because it is a local file-based repository of lightweight, should not be used for the cluster environment, and once removed only through the WebSphere Application Server related commands to be re-added back.
Query the current repository
ConfigEngine mission of the wp-qurey-repository can be used to query the current configuration for the Portal repository of all information.
[root @ pvcent107 ConfigEngine] #. / ConfigEngine.sh wp-query-repository
......
[wplc-query-federated-repository] Existing Federated Repositories
[wplc-query-federated-repository] Repository Name: (Details)
[wplc-query-federated-repository] *******************************
[wplc-query-federated-repository] InternalFileRepository:
(repositoryType = File, host = LocalHost)
[wplc-query-federated-repository] Status = Complete
......
From the above we can see that the default Bahrain Portal users after the United registry will contain a file repository, the repository ID for the "InternalFileRepository", type "document", host to "the local host." Query the current repository list do not need extra parameters can be run.
Add LDAP repository
wkplc.properties
wkplc.properties are ConfigEngine the main configuration file, at
Here we look at how to add a LDAP repository. At this point we need to file to tell wkplc.properties Edit ConfigEngine related parameters. Here we simply introduce a few important parameters, a detailed list of parameters please see the WebSphere Portal Server V6.1 Information Center.
wkplc.properties
• federated.ldap.id = RepositoryID_pvcent49.cn.ibm.com: 389
o The id used to uniquely identify this repository
• federated.ldap.baseDN = dc = ids601, dc = com
o Basic items (Base Entry) to indicate that this unique identifier and a repository subtree or all mapped to the virtual storage Curitiba
• federated.ldap.ldapServerType = IDS6
o Used to specify the type of LDAP
Edit is complete, you can through the implementation of the relevant ConfigEngine mission wp-create-ldap to add LDAP repository.
Add LDAP repository
[root @ pvcent107 ConfigEngine] #. / ConfigEngine.sh wp-create-ldap
......
wp-create-ldap:
Wed Apr 30 07:10:36 CST 2008
validate-federated-ldap:
Wed Apr 30 07:10:37 CST 2008
[echo] LDAPHostName federated.ldap.host = pvcent49.cn.ibm.com
[echo] LDAPPort federated.ldap.port = 389
[echo] LDAPAdminUId federated.ldap.bindDN = cn = root
......
BUILD SUCCESSFUL
Total time: 31 seconds
[root @ pvcent107 ConfigEngine] #
It is worth noting that this command of the execution time of just 31 seconds, the speed compared to the previous version has greatly improved. Now, let us look at the current repository list:
Query the current repository
[root @ pvcent107 ConfigEngine] #. / ConfigEngine.sh wp-query-repository
......
[wplc-query-federated-repository] Existing Federated Repositories
[wplc-query-federated-repository] Repository Name: (Details)
[wplc-query-federated-repository] *******************************
[wplc-query-federated-repository] RepositoryID_pvcent49.cn.ibm.com: 389:
(specificRepositoryType = IDS6, repositoryType = LDAP, host = pvcent49.cn.ibm.com)
[wplc-query-federated-repository] InternalFileRepository:
(repositoryType = File, host = LocalHost)
[wplc-query-federated-repository] Status = Complete
......
[root @ pvcent107 ConfigEngine] #
Can be seen, LDAP repository has been added to the joint user registry. In this way, we can further analyze the domain / basic item / repository of how all three are at Portal security configuration files stored. They are stored in the wimocnfig.xml file. This document contains the Portal related to VMM configuration information, you can
wimconfig.xml
id = "InternalFileRepository" supportPaging = "false" messageDigestAlgorithm = "SHA-1">
......
id = "RepositoryID_pvcent49.cn.ibm.com: 389"
ldapServerType = "IDS6" translateRDN = "false">
connectionPool = "true" connectTimeout = "0" derefAliases = "always"
referal = "ignore" sslEnabled = "false">
......
......
......
We are here to extract the fragment consists of three parts, the first two in order to "
Add database repository
Add a database repository of the steps and add the LDAP repository process of basically the same, we can put JDBC accessible database also added to the United users table, same wkplc.properties Edit and fill out the required parameters, and then through the implementation of ConfigEngine.sh wp -create-db to complete this configuration. Not here to start the introduction.
Delete repository
When we no longer need a repository, we can at any time to delete it, delete at this time what actually includes two steps. The first step is to this repository in the domain corresponding to the basic items removed from the domain, and the second step is to completely delete repository. In fact, from our analysis above wimconfig.xml document, the first step is to modify the domain configuration information, remove the corresponding items included in the basic, and the second step is to delete the configuration information repository. In the WebSphere Portal Server V6.1 to provide a mission (wp-delete-repository) to a one-time to complete these two steps. This mission includes two configuration parameters:
wkplc.properties
• federated.delete.baseentry = o = defaultWIMFileBasedRealm
o Remove from the domain used to specify the basic items
• federated.delete.id = InternalFileRepository
o Required to delete the specified repository ID
It is worth noting that, if the repository contains the current administrator is using the ID, the user will be required to change the Portal administrator ID repository for other users can then delete this repository. In addition, if the repository at the same time be included in the other domain, the user first of its required basic items removed from other domain then delete after. How to delete the domain from other basic items please see "multi-user domains and virtual portal."
Set default repository
When the United user registry contains multiple storage library, the newly created user will be stored in a single repository as well? How do I change the default repository then? In fact, all these could be through the analysis of wimconfig.xml to get an answer.
wimconfig.xml
... ...
We can see the new default user and group will be saved at o = defaultWIMFileBasedRealm this basic item, which is the default file repository. We can ConfigEngine by running the mission (wp-update-entitytypes) to complete on the default repository configuration. For example:
wkplc.properties
• personAccountParent = cn = users, dc = ids601, dc = com
o The user's default parent node
• groupParent = cn = groups, dc = ids601, dc = com
o Group's default parent node
End of mission, after running through the Portal, we created a new user will be stored in LDAP storage Curitiba, rather than the previous document repository, the user ID will be automatically added on the "cn = users, dc = ids601, dc = com" suffix. The newly created group is the same truth. After running, the new document wimconfig.xml relevant content as shown below.
Running wp-update-entitytypes after wimconfig.xml
......
User Registry United limitations
• DN (Distinguished Name) in the same domain for all to be the sole repository. For example, if at LDAP1 repository including uid = wpsadmin, o = youco, then stored at other libraries can no longer include this user.
• Short name (for example: wpsadmin) must also be in the same repository for all domain only.
• At the same domain all the repository corresponding to the basic items should not overlap. For example, if LDAP1 repository of basic items for the c = us, o = youco, then LDAP2 repository of basic items should not for the o = youco
• VMM because of the restrictions, if any United registry in one repository to stop running, the user will not be able to authenticate, even if the user is stored in the other normal job at this time repository too.
A single isolated registry
In the WebSphere Portal Server V6.1, the single isolated not recommend the use of the registry. If your system there must be some substantial historical legacy applications support only a single isolated registry, or to take into account other factors, including systems integration, you can choose to use the user registry.
Isolated in a single user registry with the registry to switch between the United
We note that in the WebSphere Application Server V6.1, we can configure the user registry or a single United isolation registry, and when necessary and then set the current selection. In other words, the WebSphere Application Server V6.1, the two parts of the configuration information is an independent co-existence, non-interfering. However, in WebSphere Portal Server V6.1 Medium is not the case. Whatever the underlying reason is that Portal is used to isolate a single user registry registry or United have been taken directly read by VMM, so isolated in a single registry, when it must also treat it as a joint user registry to treat same at wimconfig.xml create a domain / basic item / repository, but at this point the domain to include only the sole repository of.
Need to pay attention to is that when users switch from United to a single user registry registry isolation, it will first delete all of the basic items at this time / repository, and then isolated for a single registry key and create a basic repository, that is to say not like WebSphere Application Server as the configuration information to maintain their independent co-existence, non-interfering. Similarly, when a user registry from a single isolation switch to the joint user registry, it will only have to change the look easy name, and the original registry directly as a single isolated United user registry in a repository will no longer need to re-add it.
Isolated a single Lightweight Directory Access Protocol (LDAP) registry.
Let us look at the registry from the United users to switch to a single isolated Lightweight Directory Access Protocol (LDAP) registry process. In our current environment, the United user registry now includes two storage libraries, are separately document repository and has been newly added LDAP repository (LDAP is located in the host pvcent49) is now required to switch to a single isolated LDAP registry on (LDAP is located in the host pvcent76). First of all, still wkplc.properties are modified files, which are required to pay special attention to the following parameters:
wkplc.properties
• standalone.ldap.realm = Realm_pvcent76.cn.ibm.com: 389
o Domain (Realm) Name
• standalone.ldap.id = RepositoryID_pvcent76.cn.ibm.com: 389
o Repository ID
• standalone.ldap.baseDN = dc = ids5201, dc = com
o Repository corresponding to the basic items (BaseEntry)
User Registry from the United isolation switch to a single registry (LDAP)
[root @ pvcent107 ConfigEngine] #. / ConfigEngine.sh wp-modify-ldap-security
......
[wplc-create-realm] Realm Realm_pvcent76.cn.ibm.com: 389 was created successfully.
......
[wplc-cleanup-repositories] Deleteing realm defaultWIMFileBasedRealm
[wplc-cleanup-repositories] Deleteing repository RepositoryID_pvcent49.cn.ibm.com: 389
[wplc-cleanup-repositories] Repository
[wplc-cleanup-repositories] Deleteing repository InternalFileRepository
[wplc-cleanup-repositories] Status = Complete
......
wp-create-wimconfig-ldap:
[wplc-create-federated-ldap-repository]
id = "RepositoryID_pvcent76.cn.ibm.com: 389"
[wplc-create-federated-ldap-repository] Status = Complete
......
wp-create-base-entry:
[echo] id = RepositoryID_pvcent76.cn.ibm.com: 389
[echo] baseDN = dc = ids5201, dc = com
[echo] nameInRepository = dc = ids5201, dc = com
......
BUILD SUCCESSFUL
Total time: 1 minute 36 seconds
[root @ pvcent107 ConfigEngine] #
Configuration process can be seen at first created a new domain, to be followed to delete the old domain as well as two storage library, and then create a new LDAP repository as well as basic items.
Wimconfig.xml are in fact not check to determine the current types of registry Portal, we can security.xml by examining the registry to get the current type.
security.xml
......
......
registryClassName = "com.ibm.ws.wim.registry.WIMUserRegistry" />
At security.xml can be seen, the currently selected user registry ID are "LDAPUserRegistry_1", are the corresponding LDAP user registry. If we are in the configuration of the joint when the user registry to view the file, you will find here the values are "WIMUserRegistry_1", corresponds to the user registry of the United.
Multi-user domains and virtual portal
Multi-user domain (multiple realms), and virtual portal (virtual portal) concept has a long history, first appeared in the WebSphere Portal V5.1 Medium. In this article we will not elaborate on the two concepts, only focuses on WebSphere Portal V6.1 give us what the new changes. First of all, we first briefly give the user domains and virtual portals in WebSphere Portal V6.1 definition of the concept.
• User domain: are one or more users in the user repository to re-mix to form a new user group. It is a logical concept.
• Virtual portal: are in a single, common WebSphere Portal environment, the portal of resources (including pages, user groups and so on) to carry out the demarcation of logic.
Multi-user domains and the links between virtual portals can be used to express the next Figure 3
Figure 3. Multi-user domains and virtual gateway to the link between
As can be seen, from the concepts and the linkages between, the multi-user domains and virtual portals in WebSphere Portal V6.1 Medium Nothing changes. However, WebSphere Portal V6.1 through ConfigEngine greatly simplifies the multi-user domain of the configuration process, avoiding the previous need for portal security configuration files directly modify and greatly enhance the user experience.
WebSphere Portal V6.1 to provide the following ConfigEngine the mission used to configure the gateway to the multi-user domain support:
Table 1. ConfigEngine task list
ConfigEngine multi-user domain profile mission Role
wp-create-realm
The use of designated basic items to create a user domain
wp-add-realm-baseentry
Will specify the basic items to add to the user domain
wp-delete-realm-baseentry
The basic items of the specified domain from the user delete
wp-query-realm-baseentry
Query the user domain of basic items
wp-default-realm
Set the default user domain **
Note: If the original WebSphere Portal Server and WebSphere Application Server administrator account is not a new default user domain, you need to call wp-change-was-admin-user and the wp-change-portal-admin-user to modify the two In the server administrator account. Please refer to the specific product documentation for WebSphere Portal V6.1.
Now we come to understand through an example of how to configure WebSphere Portal V6.1 multi-user domains and virtual portal support. In the previous introduction, we already know how to configure a gateway to United user registry. At multi-user domains and virtual portal example, we will use the WebSphere Portal in the three repositories to configure multi-user domain support. 3 LDAP repository separately from two different types of Directory Server IBM Directory Server 6.0.1 and Domino 8 LDAP, the specific configuration is as follows:
• Repository 1:
o federated.ldap.id = Repository1_pvcent64.cn.ibm.com: 389
o federated.ldap.baseDN = o = realm01
• Repository 2:
o federated.ldap.id = Repository2_pvcent64.cn.ibm.com: 389
o federated.ldap.baseDN = o = realm02
• Repository 3:
o federated.ldap.id = Repository3_pvcent49.cn.ibm.com: 389
o federated.ldap.baseDN = dc = ids601, dc = com
In the example below, we will put the three repository of basic items of three different distribution to the two users in the domain realm1 and reaml2, as shown in Figure 4. Realm1 repository contains one of the basic one of o = realm01 and repository of 3 basic dc = ids601, dc = com; realm2 repository will contain only 2 of the basic items of o = realm02.
Figure 4. Multi-user repository Examples of domain
Let us now running multi-user domain configured ConfigEngine its mission to experience it simple and quick.
First of all, to generate realm1. Wkplc.properties modify the document at the following parameters, then run the wp-create-realm mission.
wkplc.properties
• realmName = realm1
• securityUse = active
• delimiter = /
• addBaseEntry = o = realm01
Mission to run after the results are as follows:
wp-create-realm
[root @ pvcent107 ConfigEngine] #. / ConfigEngine.sh wp-create-realm
... ...
[wplc-create-realm] Instance attributes (Set 1 of 1):
[wplc-create-realm] addBaseEntry = "o = realm01"
[wplc-create-realm] name = "realm1"
[wplc-create-realm] ignoreDuplicateIDs = "false"
[wplc-create-realm] Base entry o = realm01 was created successfully.
[wplc-create-realm] Realm realm1 was created successfully.
[wplc-create-realm] Status = Complete
... ...
BUILD SUCCESSFUL
Total time: 16 seconds
At the same token wkplc.properties document amended to read as follows parameters, and then through the wp-create-realm mission to create realm2.
wkplc.properties
• realmName = realm2
• securityUse = active
• delimiter = /
• addBaseEntry = o = realm02
Next, we document wkplc.properties parameters amended to read as follows, and then through the wp-add-realm-baseentry mission to be the repository of 3 basic dc = ids601, dc = com add in realm2.
wkplc.properties
• realmName = realm2
• addBaseEntry = dc = ids601, dc = com
Operation results are as follows:
wp-add-realm-baseentry
[root @ pvcent107 ConfigEngine] #. / ConfigEngine.sh wp-add-realm-baseentry
... ...
wp-add-realm-baseentry:
... ...
[wplc-add-realm-baseentry] Instance attributes (Set 1 of 1):
[wplc-add-realm-baseentry] addBaseEntry = "dc = ids601, dc = com"
[wplc-add-realm-baseentry] name = "realm2"
[wplc-add-realm-baseentry] Base entry dc = ids601, dc = com was added successfully.
[wplc-add-realm-baseentry] Status = Complete
... ...
BUILD SUCCESSFUL
Total time: 8 seconds
Multi-user domain in accordance with the way we expected to complete the configuration. Restart the WebSphere Portal, we can use the following user domain to create two virtual portal - a "virtual portal 1" and "Virtual Portal 2." The figure below shows the adoption of management are to create a virtual portal process. Realm1 see from the chart has been designated to the "virtual portal 1"; realm2 empathy will be assigned to a "virtual portal 2." This realm1 user can only access the "virtual portal 1"; and realm2 user can only access the "virtual portal 2."
Figure 5. To create a virtual portal
Apart from the above two tasks used, ConfigEngine also provides convenient multi-user domain of the mission management, such as mission can delete and query the user domain of the basic items, switch the default user domain and so on. These tasks use and similar to previous example, you can see the WebSphere Portal V6.1 documents use.
Concluding remarks
So far, we have introduced the WebSphere Portal Server V6.1 in a single isolated user registry / United users multi-user domain registry, as well as related applications, the joint user registry allows you flexible and be able to Add / Remove repository, a single isolated user register Table can better the original system compatible, while the multi-user domains and virtual portal configuration process at this greatly simplified version, more easy to use.
