Re: client impersonation

Hi Eric,

I don't think impersonation is the right way in this case.
Your TSP runs in a service under the local system account;
to impersonate a user you would need his credentials which
you don't have and I don't think it's a good idea to store them
anywhere.

In a single user scenario it shouldn't be too difficult to find out
which user is currently logged on. You can use the line number
and the user's login to check if the user is allowed to dial on
this line. No authentication would be necessary for this on the
web service.

In a multi-user (terminal services) scenario this won't work.
While you are able to retrieve the login names of all current
active sessions you will never know which call is made from
which session/user. You could still check if a line that is to be
opened matches one of the current active logins imposing the
risk that a logged in user could dial on a line of a different
user logged in to the same terminal server.

I still don't think that filtering the lines depending on the logged
in users is a good idea. TAPI provides a mechanism for dynamically
adding and removing lines during runtime, so this might be possible.
Though I'd rather try to partition the lines. If you are talking
about thousands of lines then we are surely not talking about
a single Windows domain but rather of a large forest. You could
partition the lines depending on the current domain. A machine
is usually member of a single domain, so you could filter the
lines depending on the domain the machine is member of.

Regarding line selection: Why not create a simple client autostart
tool that makes a request to the webservice with the user's login
name and retrieves the associated line name/number? The autostart
tool could then make the approppriate Outlook registry setting and
you're done. Even changes of these associations would be no problem
because it would be refreshed on each login.


Best regards,

Matthias Moetje
-------------------------------------
TERASENS GmbH
Augustenstraße 24
80333 Munich, GERMANY
-------------------------------------
Fon: +49 89 143370-0
Fax: +49 89 143370-22
e-mail: moetje at terasens dot com
www: www.terasens.com
-------------------------------------

"Eric" <bauersachs@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:e9nUOepcGHA.5116@xxxxxxxxxxxxxxxxxxxxxxx
Hi Matthias

Thanks for your answers.

why not present all available lines to the user?
On one customer site there are a few thousand lines. The very stupid users
probably don't know what to select there. Those lines look a bit like IP
addresses (only numbers), so even advanced users would have difficulties
to
select "their" phone line. And moreover: if a user selects a wrong line,
then later it would simply not work, because of an access denied error.
Our
TSP starts dialing through a webservice call. So for dialing it needs to
impersonate the client user to have the appropriate rights on the
webservice
(anonymous isn't allowed there, only to enumerate the lines).

I guess your scenario should also work for
multiple users which are logged in simultaneously?
Yes, it should, if possible. Although I expect this not to be an often
requested feature.
Your demur about the line owner is important for the future. But currently
we don't support hang up, so currently the TSP returns that the call has
ended although it's still going on. If multiple users would use the same
line you're right; this wouldn't work anymore. And because we want to
support hang up in future, this is no good idea. You're right.

dial prefix...
This is another good idea. But unfortunately it doesn't work either, for
two
reasons:
1. This would mean that we had to configure this somehow. And a client
rollout would be much more complicated. We don't want to configure this
for
every single user. This must be done somehow automatically. Ok, only a
difficulty, not a real problem.
2. Because the actual dialing is done on a server somewhere else, locally
there are other modem settings (which cannot be changed just for our TSP).
The users sometimes need these settings for their local modems, etc.

So these main problems remain:
- To start a call, the TSP must make an authentication on the webservice.
This can only be done when impersonating the TAPI client application user.
Ok, we could change the webservice authentication mode to anonymous and do
some other kind of authentication.
- Somehow we need to filter the lines list based on the actual TAPI client
application user to not confuse him with too many lines where he has no
access.
- When starting a call, the user may use only certain lines where he has
the
rights to do so.

Any ideas to solve these problems, especially the last one?

Regards,
Eric




.

Relevant Pages

  • Re: Webservice "verstecken"
    ... Ich habe in VB einen Webservice programmiert. ... Ich hätte gerne, dass die Methoden zwar vom Client aufrufbar sind, jedoch ... Dann wird das Authentication Ticket, ... Login zugewiesen wird, immer mit zu dem geschützten Webservice übertragen. ...
    (microsoft.public.de.german.entwickler.dotnet.asp)
  • Page redirection in webservices ?
    ... i have a webservice which has some methods and a login page.I 've ... use the webservice's login page. ... How can i redirect the client to go to the webservice's login page. ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • Re: Debugger not working in Vs.net 2003
    ... I check The "Impersonate a client after authentication" user right, aspnet ...
    (microsoft.public.vsnet.debugging)
  • Re: help on caller credentials !! :-(
    ... the back end SQL server maybe. ... In fact I simply try to flow the client user until the database level. ... Hosting my remote object in IIS would be much more simple but thi is not my ... under windows 2000 and prefer mode should be "Impersonate". ...
    (microsoft.public.dotnet.security)
  • Windows Authentication
    ... I'm not sure about VB6, but there is a mechanism in Win32 ... user for a username/password and use these to impersonate ... >I am using Windows Authentication in SQL so that I don't ... >are created as a single login. ...
    (microsoft.public.sqlserver.security)