Sun Java System Directory Server Enterprise Edition 6.1 Reference

Forwarding Request From Directory Proxy Server to Backend LDAP Servers

Client requests can be forwarded from Directory Proxy Server to backend LDAP servers with different levels of authorization and authentication, and with or without the identity of the client. The configuration of the data source determines the way in which a request is forwarded. For information about proxy authorization in client requests, see Directory Proxy Server Configured for Proxy Authorization. For information about how to configure proxy authorization in client requests, see Proxy Authorization in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

When client requests contain a proxy authorization control, the control is always forwarded with the request, irrespective of how Directory Proxy Server forwards the request. The use case where Directory Proxy Server is configured for proxy authorization and the client request itself contains a proxy authorization control is described in Directory Proxy Server Configured for Proxy Authorization and the Client Request Does Contain a Proxy Authorization.

For information about how client requests are forwarded from Directory Proxy Server to backend LDAP servers, see the following sections:

Directory Proxy Server Configured for BIND Replay

Directory Proxy Server forwards a BIND request from a client and the credentials of the client to an LDAP server. If the BIND is successful, all subsequent requests from the client to that LDAP server are processed with the authorization of the client.

In BIND replay, if the client makes a subsequent request that is forwarded to another LDAP server, the Directory Proxy Server uses the credentials already provided by the client to BIND to the other LDAP server before forwarding the request.

If a client request contains a proxy authorization control, Directory Proxy Server forwards the control to the backend server.

The following figure shows client identity and credentials being used for authorization by BIND replay.

Figure 19–1 Authentication in BIND Replay

Figure shows the client identity and credentials being
used for authorization by BIND replay.

When Directory Proxy Server is initiated, it opens a connection to each LDAP server. When a client connects to Directory Proxy Server it makes requests in the following stages:

  1. The client requests a BIND, and provides a DN and a password.

  2. Directory Proxy Server authenticates the client to LDAP server 1 by using the client's credentials. An entry for the client exists in LDAP server 1 and the BIND request is granted.

  3. The client issues a SEARCH request that is targeted at LDAP server 1.

  4. Directory Proxy Server forwards the SEARCH request to LDAP server 1, reusing connection 2.

    The SEARCH request is performed with the authorization of the client. If the client request contains a proxy authorization control, the request is processed with authorization of the user specified in the proxy authorization control.

    If the client sends more SEARCH requests that are targeted at LDAP server 1, the Directory Proxy Server forwards the request without performing additional binds.

  5. The client sends a SEARCH request targeted at LDAP server 2

  6. The Directory Proxy Server authenticates the client to LDAP server 2 by using the client's credentials obtained in Step 1. An entry for the client exists in LDAP server 2 and the BIND request is granted.

  7. The Directory Proxy Server forwards the SEARCH request to LDAP server 2, reusing connection 3.

If the client is not authenticated to Directory Proxy Server, the BIND request is forwarded as anonymous.

If the client identity is mapped onto another identity, Directory Proxy Server uses the mapped identity to bind to the LDAP server. All requests on that connection are processed with the authorization for the mapped identity. For information about user mapping, see Directory Proxy Server Configured to Forward Requests As an Alternate User.

When Directory Proxy Server is configured for BIND replay, authentication by SASL external bind cannot be used . In BIND replay, Directory Proxy Server authenticates the client to a backend LDAP server by using the client DN and password. In SASL external bind, no password is provided by the client. Furthermore, the password that is stored in the user entry cannot be read in clear text.

For performance reasons, you should configure Directory Proxy Server to use BIND replay only when the extra configuration required for proxy authorization is not feasible, or where proxy authorization is not supported. For information about proxy authorization, see Directory Proxy Server Configured for Proxy Authorization

Directory Proxy Server Configured for Proxy Authorization

When Directory Proxy Server is configured for proxy authorization, Directory Proxy Server can add a proxy authorization control to a client request. The client request is then forwarded with the authorization of the specified in the proxy authorization control.

To simplify the configuration of ACIs, Directory Proxy Server can be configured to allow anonymous reads and to apply proxy authorization for write operations.

If Directory Proxy Server is configured for proxy authorization and the client request contains its own proxy authorization control, Directory Proxy Server does not add a proxy authorization control. In this case, Directory Proxy Server checks with the backend LDAP server that the client has the right to use its proxy authorization control. If the client has the right to use its proxy authorization control, Directory Proxy Server forwards the request with the authorization specified in the client's proxy authorization control.

For information about how to configure proxy authorization in Directory Proxy Server, see Forwarding Requests With Proxy Authorization in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide

Connections When Directory Proxy Server Is Configured for Proxy Authorization

When Directory Proxy Server is configured for proxy authorization, a client is usually authenticated to the Directory Proxy Server by a non-anonymous BIND or by a SASL external BIND, however, clients can also be anonymous. Directory Proxy Server is usually bound to the data sources by using an administrative identity.

Figure 19–2 shows the connections between a client, Directory Proxy Server, and backend LDAP servers, when Directory Proxy Server is configured for proxy authorization.

Figure 19–2 Connections for Proxy Authorization

Figure shows the connections for proxy authorization.

The connections for proxy authorization are made in the following stages:

  1. When Directory Proxy Server is initiated, it opens a connection to each LDAP server. Directory Proxy Server binds to LDAP server 1 and LDAP server 2 by providing its DN and password, DPSbindDN and DPSbindPW.

    An entry for DPSbindDN exists in both the LDAP servers and the BIND requests are granted. Directory Proxy Server is bound to the LDAP servers, on connection 2 and connection 3.

  2. When a client connects to Directory Proxy Server, the client binds by providing its DN and a password, clientDN and clientPW.

  3. The Directory Proxy Server authenticates the client to LDAP server 1 by using the client's credentials and by reusing connection 2.

    An entry for the client exists in LDAP server 1 and the BIND request is granted. The client is bound to Directory Proxy Server on connection 1.

Directory Proxy Server Configured for Proxy Authorization and the Client Request Does Not Contain a Proxy Authorization

Figure 19–3 shows the flow of information when Directory Proxy Server is configured for proxy authorization. The client in Figure 19–2 makes, and Directory Proxy Server adds a proxy authorization control.

Figure 19–3 Information Flow When Proxy Authorization Control Is Added by Directory Proxy Server

Figure shows the flow of information when a client request
does not contain a proxy authorization control.

  1. The client sends a SEARCH request SEARCH 1, that does not contain a proxy authorization control. The request is targeted at LDAP server 1.

  2. Directory Proxy Server adds a proxy authorization control to the request and forwards the SEARCH operation to LDAP server 1, reusing connection 2.

    The SEARCH operation is performed with the authorization of the user specified in the proxy authorization control. That authorization is defined in the RW ACIs on the LDAP server for the user specified in the proxy authorization control.

  3. The client sends a second SEARCH request, SEARCH 2, that does not contain a proxy authorization control. The request is targeted at LDAP server 2.

  4. The Directory Proxy Server forwards the SEARCH operation to LDAP server 2, reusing connection 3.

    Notice that it is not necessary for the client to bind to LDAP server 2 before the request can be processed, and it is not necessary for the LDAP server to contain an entry for the client.

Directory Proxy Server Configured for Proxy Authorization and the Client Request Does Contain a Proxy Authorization

Figure 19–3 shows the flow of information when the client in Figure 19–2 makes a request that does contain a proxy authorization control. Directory Proxy Server verifies that the client has the right to use its proxy authorization control.

Figure 19–4 Information Flow When Proxy Authorization Control Is Contained in the Client Request

Figure shows the flow of information when a proxy authorization
control is contained in a client request.

  1. The client sends a SEARCH request SEARCH 1, that contains a proxy authorization control. The request is targeted at LDAP server 1.

  2. Directory Proxy Server verifies that the clientDN has the right to use a proxy authorization control on LDAP server 1, by getting the effective rights of the client on LDAP server 1. For information about how to get effective rights, see Viewing Effective Rights in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide

  3. Directory Proxy Server forwards the SEARCH operation to LDAP server 1, reusing connection 2.

    The SEARCH operation is performed with the authorization of the user specified in the proxy authorization control. The authorization is defined in the RW ACIs on the LDAP server.

  4. The client sends a second SEARCH request, SEARCH 2, that contains a proxy authorization control. The request is targeted at LDAP server 2.

  5. Directory Proxy Server verifies that the clientDN has the right to use a proxy authorization control on LDAP server 2, by getting the effective rights of the client on LDAP server 2.

  6. The Directory Proxy Server forwards the SEARCH operation to LDAP server 2, reusing connection 3.

    Notice that it is not necessary for the client to bind to LDAP server 2 before the request is processed, and it is not necessary for the LDAP server to contain an entry for the client.

Security Issues When Directory Proxy Server Is Configured for Proxy Authorization

Consider the following security risks before configuring Directory Proxy Server for proxy authorization:

Directory Proxy Server Configured to Forward Requests Without the Client Identity

In some deployment scenarios, it is not necessary to maintain the identity of a client when the client makes request. Directory Proxy Server can be configured to forward requests to LDAP servers without the client identity. The LDAP servers process the requests with the identity and authorization of the Directory Proxy Server.

Directory Proxy Server Configured to Forward Requests As an Alternate User

Client requests can be performed with the identity of an alternate user by using the feature called user mapping. In user mapping, the client identity is mapped to the identity of an alternate user. After a BIND operation, the Directory Proxy Server submits subsequent operations as the alternate user.

When a client identity is mapped to another identity, requests from that client can be forwarded to the backend LDAP servers by using BIND replay or by using proxy authorization.

Client identities can be mapped to alternate identities either locally on the Directory Proxy Server or remotely on an LDAP server. Figure 19–5 and Figure 19–6 illustrate local mapping and remote mapping.

Figure 19–5 Local Mapping of a Client Identity to an Alternate Identity

Figure shows local mapping of client ID to alternate
ID

Figure 19–6 Remote Mapping of Client Identity to an Alternate Identity

Figure shows a client identity being mapped to an alternate
identity.

In local mapping, the identity mapping is configured in the Directory Proxy Server. The configuration cannot be changed without reconfiguring the Directory Proxy Server. Local mapping can be configured for unauthenticated clients, authenticated clients, and for clients authenticated by proxy.

In remote mapping, the identity mapping is configured in an entry in the remote LDAP server. The mapping can be changed by modifying the entry in the remote LDAP server. It is not necessary to reconfigure the Directory Proxy Server to change the mapping. Remote mapping can be configured for unauthenticated clients and for clients authenticated by proxy.

Remote mapping must not be used for data sources configured for BIND replay. In BIND replay, the Directory Proxy Server forwards a client request by using the authentication provided in the BIND operation. However, in remote mapping the client DN and password provided in the BIND operation are mapped to an alternate DN and password. The client's password cannot be retrieved from the backend LDAP sever.

If the user mapping is enabled but the mapping fails, the client identity is mapped to a default identity. A user mapping can fail when a client identity is mapped to a non-existent alternative identity or when there has been a configuration error.

For information about how to configure user mapping, see Forwarding Requests as an Alternate User in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide