RpcImpersonateNamedPipeClient

[Seiichi Tatsukawa]

| oo... ok, so... dce api server application writers chose to
| implement their own security context?  (not dce/rpc itself, that's
| different).

DCE/RPC is the middle-ware. (It is the tool to make it easier to write the
distributed applications without knowing, say, the socket programing.) It
doesn't enforce the policy in this regard.

The RPC client, written by the application writers, makes its own decision
whether to use the authenticated RPC or not, the level of the protection
(you have seen these 6 levels in which pkt_privacy isn't expotable from
US) if the authenticated RPC is used.

The RPC server, again written by the application writers, makes its own
decision whether to accept the un-authenticated RPC or not, what is the
lowest acceptable protection level, who can execute this function (i.e.,
authorization check), etc.

(It's not different from what you do with the opaque_auth field of ONC
RPC.)

Just because the server knows the client's security context, it doesn't
mean it always wants to impersonate the client. It may use it for the
authorization only.

You could argue that it simplifies the application development if DCE/RPC
runtime took care of the security context. However, not all distributed
applications want the security. (Silly, huh? People are still using ONC
RPC without Kerberos. OMG's first CORBA spec. had no security, at all,
when Kerberos, DCE, etc., were already available.) Well, Microsoft offers
help for simplifying the application development. That's DCOM, which
isolates the application writers from these details (e.g., calling
RpcBindingSetAuthInfo(), RpcBindingInqAuthClient(), etc.).

---  Seiichi