Previous Topic: Example: Configure Role-Based Access Control in a Router DSA

Next Topic: Configure Access Controls

How Secure Proxies Work with Access Controls

The secure proxy feature lets an authorized user (or process) impersonate a user or role for whom it has responsibility, and bind to a DSA to elicit access control decisions, for example, a web server using a directory as an authorization engine.

The proxy binds to a DSA using certificate-based authentication. Those users permitted to proxy (impersonate someone else) are identified to a DSA as a list of distinguished names held in the trust-sasl-proxy list.

When using a proxy, impersonating usera can never obtain more power than they already have. In other words, in assuming the identity of another user, they may not obtain all the privileges of that user.

Once bound to a DSA, the proxy may change identity by changing the value of dxProxyUser in the entry cn=roles to the distinguished name of the new identity. This has the effect of evaluating the roles for the new identity. An exception is where the proxy also changes the value of dxProxyRole in cn=roles. In this case, roles are taken directly from the attribute value, not by accessing role entries in the directory.

The entry cn=roles is an operational entry, which means that it does not appear in the directory information tree, and it is never returned in any query results.

To permit the proxy to impersonate users not in the directory (external users), the proxy replaces the value of the dxProxyUser attribute in the operational entry with the distinguished name of the new identity, and at the same time replaces the value of the dxProxyRole attribute with the roles of the new identity. In this instance, the roles provided in the replace operation are used directly, if the following command is set:

set ssl-auth-bypass-entry-check = true;