Network Groups

Network groups are the entry point of all client requests handled by the Sun OpenDS Standard Edition proxy.

The network groups handle all client interactions and dispatch them to workflows, based on:

• Criteria

  Criteria can include security authentication level, port number, client IP mask, client bind DN, domain name, and other criteria.

• Quality Of Service (QOS) policies

  QOS policies can include LDAP referral policy, request filtering, client connection affinity, and resource limits.

Within the Sun OpenDS Standard Edition proxy, you can have more than one network group defined, each with different properties and different priorities. However, the incoming client connection can only be attached to one network group at a time. An incoming client connection is attached to the first network group for which a client connection complies with the criteria defined for that network group.

The client connection is assessed by each network group, in order of priority, until it complies with all the criteria of that network group. As illustrated in Figure 4-2, the request is first sent to the network group with the highest priority: Network Group 1. Network Group 1 assesses if the request matches all the required criteria. If it does not match all of the criteria, it forwards the request to the next network group in the list: Network Group 2.

If the request matches all the properties of a network group, the network group assesses if the client connection matches the QOS policies of that network group. If it matches the QOS policies, it is routed to the associated workflow.

Figure 4-2

Network Group Selection

A network group can be associated with one or more workflows, each workflow corresponding to a different naming context. For more information of workflows, see Workflows. However, if the client connection matches the criteria of a network group, but not the QOS policies of that network group, the connection is not forwarded to the workflow, nor is it sent to the next network group. You will get an error message indicating the QOS policy that causes an error.

The Sun OpenDS Standard Edition proxy comes with a default network group. If a client connection does not match any of the network groups in your deployment, it is attached to this default network group. However, this network group does not have any workflows attached to it, so your request will not be treated. You will get an error message indicating: No such entry.

For information on managing network groups, see Configuring Network Groups in Sun OpenDS Standard Edition 2.2 Administration Guide.

Example 4-1

Using Network Group Criteria to Route to Different Workflows

For example, if a Sun OpenDS Standard Edition proxy has the following network groups:

• Network Group 1: criteria set with bind DN **,dc=example,dc=com

  This network group is associated to Workflow 1, with naming context dc=example,dc=com

• Network Group 2: criteria set with bind DN **,dc=test,dc=com

  This network group is associated to Workflow 2, with naming context dc=test,dc=com

Depending on your bind DN, your search would be routed through Network Group 1 or Network Group 2. For example, if your bind DN is uid=user.1,dc=test,dc=com, your request is not accepted by Network Group 1, but forwarded to and accepted by Network Group 2, and forwarded to Workflow 2.

Example 4-2

Using Network Group QOS Policy to Filter Requests

For example, if a Sun OpenDS Standard Edition proxy has the following network groups:

• Network Group 1: criteria set with bind DN **,ou=admin,dc=example,dc=com

  QOS policy set with resource limits size limit=0, time limit=0. Therefore, for admin group, there are no limits.

  This network group is associated to Workflow 1, with naming context dc=example,dc=com.

• Network Group 2: criteria set with bind DN **,dc=example,dc=com

  QOS policy set with resource limits size limit=100, time limit=30 s. Therefore, for all connections other than admin group, there are limits set on the resources used.

  This network group is also associated to Workflow 1, with naming context dc=example,dc=com.

Therefore, as long as the bind DN is dc=example,dc=com, the requests will be forwarded to Workflow 1. The QOS policy set for Network Group 2 gives restricted access to Workflow 1, for anyone that is not admin. Anyone who binds as admin will access Workflow 1 through Network Group 1, and will have no limitations on resource limits.