DCEMAP OBJECT SAMPLE EXPLANATION
(316GR 15-Jan-1998)

The dcemap object can optionally set a login context as the per-thread default login context for a thread, although it is not mandatory. We've added per-thread login contexts to our PC-DCE for Windows NT/95 to get around a limitation that DCE has with delegation and the default login context.

In pure DCE, a second-tier server can become a delegate for a client; that is, it can obtain a DCE login context that shows it is acting on behalf of the client. This server can then use that login context to access other services available on the network. However, some DCE applications implement a standard API with DCE plugged-in transparently underneath (for example, Oracle ANO and OHI's Connection). They implement the ODBC API and use DCE to secure the link between the client and the database.

Since ODBC has no concept of a login context, there is no way to pass the delegated login handle down through the ODBC API to the underlying DCE-enabled database client. So, these applications do the next best thing and call sec_login_get_current_context() which gets them the default login context. However, the default login context (set via a call to sec_login_set_context()) sets the process-wide default login context. This presents a problem with delegation because the middle tier is actually a multi-threaded server acting on behalf of many clients. To use sec_login_set_context(), you would need to mutex-protect the default login context and all client requests would effectively be single-threaded through the second tier.

PC-DCE gets around this problem by adding the equivalent of sec_login_set_context() which operates on a per-thread basis. For example, this allows a given executor thread to set a default login context for itself and then issue calls to the ODBC layer. When the ODBC layer calls sec_login_get_current_context(), PC-DCE detects the fact that this thread has a per-thread default context and will return it. Otherwise, it will fall back to the per-process default context and return that accordingly. This allows the multi-thread use of delegation for APIs that don't accept DCE login contexts. This is critical in the WebCrusader environment where the Web server is considered the second tier and uses delegated login credentials to access downstream services from Web applications.

Once you get a login context, you can retrieve the user's name using DCE API calls. Although the DCEMap ActiveX object does not export a method to do this, you can use sec_login_get_initiator() to grab the initiators EPAC and extract the user's UUID. You can then call sec_id_gen_name() to map it to the user's name.