Re: Under which credentials COM makes calls from another process?
From: Antonio (antoniopassado_at_hotmail.com)
Date: 07/13/04
- Next message: Walter Donavan: "VIRUS"
- Previous message: Antonio: "Re: How to check from destructor whether it was called due to exception or normal exit from the scope?"
- Maybe in reply to: Antonio: "Under which credentials COM makes calls from another process?"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 13 Jul 2004 15:14:33 +0200
Hi, Jo
Thank you very much for your answer. Our application is out-of-process
server. There are two ways our server application (server here is not
limited to the meaning of DCOM server, but to server in general) is
accessed: from another process on the same machine (this process is IIS/ASP
and we access it via DCOM) and from any computer on the Internet via our own
communication protocol. Passwords do not travel over the wire,- those
clients that connect over the Internet by mean of our own protocol
authenticate via SSPI. As a result of this, on the server-side we get a
security context, which is used later to impersonate thread on the server
each time when server receives a request from given client, connected over
the Internet (via our protocol, not over DCOM). These security contexts
together with some other information are kept on the server inside Session
objects, which can also be accessed over DCOM. Basically over DCOM ASP/IIS
can get some properties of these objects: client IP address and port, User
name under which user authenticated (NO password), time of last and first
interaction with the server etc.
When requests to the server are sent over our protocol, we properly
impersonate thread (by looking up appropriate Session object and calling
Impersonate() on it), making sure that request is executed with appropriate
token. Quite often however we need to make some calls from ASP (IIS). This
might happen for example in those cases when our client ActiveX control is
instantiated inside HTML page generated from ASP. In those cases we
basically have two connections to the server computer: one over our own
protocol to our server application and one over HTTP to the web server under
IIS. The problem is, that thread under which IIS accesses our server is not
impersonated with the token of the client (connected via our own protocol)
but with standard IUSR_<machinename>. For various reasons we can not use
neither basic authentication nor challenge/response authentication proposed
by Internet explorer. So to avoid transfer of passwords over the wire we
either need somehow get token from our server's process inside process that
runs web server or to authenticate second time by mean of SSPI (getting as a
result security context in the process that runs IIS). Lack of knowledge in
the area of Windows security doesn't let us succeed with the first approach.
At the same time if we go for the second approach we need to implement some
kind of in-process object that will run inside ASP and communicate on one
side with our server application (over DCOM) and on another with the client
(over data sent via HTTP). This is a bit clumsy in my opinion but if there
are no other solutions we'll have to go for it. Can you give some advises on
how we can approach this situation properly? We need somehow get security
context of authenticated client inside process that runs ASP to be able to
impersonate thread there, which in turn should let DCOM make calls to our
server under appropriate account. Calling Impersonate() on our Session
object from the IIS process impersonates a thread from COM's thread pool,
which is not what we need. As I understand from your explanation we really
need to impersonate thread inside IIS before making call over DCOM to make
this work as we want it to.
Thanks in advance,
Antonio
----------------------------------------------------------------------------
-
"Jo Siffert" <jo.siffert@gmx.net> wrote in message
news:edhFq3MaEHA.2816@TK2MSFTNGP11.phx.gbl...
> Hi.
>
> > We are trying to access some objects hosted by our service application
from
> > ASP (IIS). Is it possible somehow to execute all the methods under
specific
> > user account? NOTE: We can not put impersonation code into each method,
we
> This depends on if you are using In-Process or Out-of-process servers.
> If you use the latter, you can use dcomcnfg (Tab 'Identity') to
> configure which user should be used to run the process. All methods
> called upon this server will use this account, unless impersonation is
used.
> If you use in-proc and use an MTA/TNA, the call will always be
> dispatched using the callers token. If you use an STA, you could
> impersonate the thread before entering the message pump.
>
> (For the following, I assume your server is out-of-process)
>
> > want to be able to impersonate once in ASP, call required methods on
> > required objects and then revert if needed. How can this be implemented?
> If you want the same identity for all calls, use the technique described
> above. Use impersonation if you want to dynamically switch identities
> between calls.
>
> > In our service application we also have access to objects that represent
> > clients connections authenticated via SSPI. Those objects have methods
> > Impersonate() and Revert() (accessible from ASP) which impersonate
current
> You are circumventing DCOM's built-in impersonation technique then. This
> also means that your passwords travel over the wire when calling
> Impersonate(), right?
>
> > thread with the credentials of particular authenticated client and
revert
> > this impersonation appropriately. Can we use these methods somehow for
> > described above scenario? It seems that when we just call Impersonate()
we
> > impersonate a thread inside our application's process but we can not be
sure
> > that the next call will be executed in exactly the same thread.
Therefore we
> > see that sometimes following calls are executed under SYSTEM account and
> > sometimes under authenticated one.
> If you configure CoInitializeSecuirity (or CoSetBlanket) to use
> impersonation or delegation (with static or dynamic cloaking, depending
> on your needs), you would not have these problems - it is sure that the
> correct credentials will be used fo each call - no matter which actual
> thread dispatches the call on the server side.
>
> > A relative question: when COM marshals call from one process to another,
> > does it also save somehow information under whose credentials this call
was
> > made? Can we for example impersonate thread inside ASP and make a COM
call
> > from it?
> If you use impersonation with dynamic cloaking, COM does right that.
>
> /Jo
----------------------------------------------------------------------------
-
Hello everybody,
We are trying to access some objects hosted by our service application from
ASP (IIS). Is it possible somehow to execute all the methods under specific
user account? NOTE: We can not put impersonation code into each method, we
want to be able to impersonate once in ASP, call required methods on
required objects and then revert if needed. How can this be implemented?
In our service application we also have access to objects that represent
clients connections authenticated via SSPI. Those objects have methods
Impersonate() and Revert() (accessible from ASP) which impersonate current
thread with the credentials of particular authenticated client and revert
this impersonation appropriately. Can we use these methods somehow for
described above scenario? It seems that when we just call Impersonate() we
impersonate a thread inside our application's process but we can not be sure
that the next call will be executed in exactly the same thread. Therefore we
see that sometimes following calls are executed under SYSTEM account and
sometimes under authenticated one.
A relative question: when COM marshals call from one process to another,
does it also save somehow information under whose credentials this call was
made? Can we for example impersonate thread inside ASP and make a COM call
from it?
Thanks in advance,
Antonio
- Next message: Walter Donavan: "VIRUS"
- Previous message: Antonio: "Re: How to check from destructor whether it was called due to exception or normal exit from the scope?"
- Maybe in reply to: Antonio: "Under which credentials COM makes calls from another process?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
