Re: Impersonation

From: William Stacey [MVP] (staceywREMOVE_at_mvps.org)
Date: 02/26/05 

Date: Sat, 26 Feb 2005 10:43:06 -0500

Not exactly sure what your issue is from the text. You might review why
you need impersonation - you may not. Once you get a UsernameToken or
SecurityContextToken (holding a UT), you can then just use Code Access
Security and verify roles for any secure method. If can factor your
methods in such a way where you don't need to mess with windows
impersonation, unless you actually need to be userX for some file operation,
etc. I also wonder why folks always talk about using a seperate account DB.
Why not just use AD or SAM for your account DB and leverage all user/group
tools? 

-- 
William Stacey, MVP
http://mvp.support.microsoft.com
"Viorel Ghilas" <vghilas@hotmail.com> wrote in message
news:ucrXyiwGFHA.2736@TK2MSFTNGP09.phx.gbl...
> Hi Martin
>
>     I know the diference between IIS and WSE authentication mecanism. I
have
> made some systems that use impersonation mecanism, that is great (I create
> only one user account and set it directly in IIS not in machine confige,
> it's secure nobody can't see the password and no need encryption mecanism
> all are based on windows security). I hear a lot about WSE and I try to
use
> it. From client I send user name and hash on the server I need to check
the
> the passwor in UsernameTokenManager derivede class, for this I need to
> access DB, so I thought that I could use impersonation for trusted SPPI
> connection but it's fail and I use connection string with the same user
name
> and password in encrypted form, but it's not so cool, because I use every
> where in all applications trusted connection. The problem is that ASPNET
> impersonate my account more late :(, but why. Request come to IIS and then
> to ASPNET, and if in config <identity impersonate="true" /> framework must
> run all process from this account, why not?
>
>
> "Martin Kulov" <kulov@bezbokluk.abv.bg> wrote in message
> news:eu$ANDtGFHA.3484@TK2MSFTNGP12.phx.gbl...
> > Hi Viorel,
> >
> >
> >
> > These are completely different things. The authentication to IIS and
> > impersonation in WSE are separate from each other and you must make the
> > difference. When you need to connect to IIS to access specific web
service
> > you are most likely use anonymous authentication, because your web
service
> > must be called from different sources. However if your case requires
> windows
> > authentication, the client must authenticate to IIS and show valid
> > credentials. These credentials are separate to the ones that you pass to
> WSE
> > in the next step. Suppose that you authenticate to IIS and you call the
> web
> > service. The web service will run under preconfigured account for
ASP.NET
> > service which is ASPNET in Windows XP or NETWORK SERVICE in Windows
2003.
> > This account could be set up in machine.config file in <processModel>
tag.
> > So finally you sent a packet containing your WSE credentials for
accessing
> > the web service protected by WSE. WSE will then check if the provided
> > username and password exist in the local machine or domain and will
either
> > accept or reject your request.
> >
> > So what you need to do is go and configure the ASP.NET service to run
> under
> > account that has access to your SQL server (preferably a domain
account).
> In
> > Windows 2003 this is handled very nicely by creating a separate
> application
> > pool i.e. no need to change the .config file. Then you need to send WSE
> > UsernameToken with specific username and password. AFAIK there is no way
> to
> > use impersonated account in WSE. This account will be used to
authenticate
> > your call in WSE and then the WSE will be running in the domain account
> that
> > you have specified in the previous step. So it will be able to connect
to
> > SQL database. The only drawback is that you have to send plain text
> password
> > to WSE service. You can either user SecureConversation with server
> > certificate or you can use Willam's solution [1] to encrypt the token
> > without having to create X509 server certificate.
> >
> >
> >
> >
> >
> > [1]
> >
>
http://www.codeattest.com/blogs/martin/2005/01/stacey-finds-missing-piece-in
> -wse.html
> >
> >
> >
> >
> > --
> > Martin Kulov
> > http://www.codeattest.com/blogs/martin
> >
> > MCAD Charter Member
> > MCSD.NET Early Achiever
> > MCSD
> >
> >
> >
> >
> >
> > "Viorel Ghilas" <vghilas@hotmail.com> wrote in message
> > news:e96c5noGFHA.2976@TK2MSFTNGP15.phx.gbl...
> >
> > > Hi all
> > >
> > >     I have webserver that share common services and i set in web
config
> > > <identity impersonate="true" /> and on IIS I set specific user account
> > that
> > > will be used. The main problem that when the IIS start applicaton and
> > > execute the methods from Global.asax.cs it use ASPNET account but not
> my,
> > > after that it switch to impersonate account. But in my situation I use
> > WSE2
> > > where I need to check password in UsernameTokenManager for that I need
> to
> > > connect to DB, but I use SSPI connection (with user from impersonate)
> that
> > > fail. How to solve this problem, I need trusted connection that use my
> > user
> > > from IIS. I need only one user everywhere, how to do that in
> > > UsernameTokenManager.AuthenticateToken(UsernameToken token) to use
> > > impersonate account ?
> > >
> > > with best reagrd
> > > Viorel
> > >
> > >
> >
>
>

Relevant Pages

  • Re: Impersonation
    ... I hear a lot about WSE and I try to use ... so I thought that I could use impersonation for trusted SPPI ... impersonate my account more late:(, ... Request come to IIS and then ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: SetPassword access denied
    ... safely invoke SetPassword etc..... ... impersonation or using the process token without impersonation) is NOT ... account that is used for performing remote activities in the directory. ... Co-author of "The .NET Developer's Guide to Directory Services ...
    (microsoft.public.windows.server.active_directory)
  • Re: VS.NET 2005 and the "allowDefinition=MachineToApplication" error
    ... Your description of impersonation is great. ... If you want to use the default configured account, eliminate that entry, or configure it as: ... The easiest way to assign correct permissions to all required directories is to run: ... I re-started IIS and tried to access my ASPX page again -- same ...
    (microsoft.public.dotnet.framework.aspnet)
  • RE: ASP.Net not impersonating for WSE 2.0
    ... WSE ... I have all my usernames and passwords in a database table called users. ... This query is also run with Integrated Security. ... The big difference is that it is *not* using Impersonation like the rest of ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • [Full-disclosure] Maybe nothing so shady; depends on the motive.
    ... There may be no impersonation going on. ... attempted use of a disabled account would produce messages about "account foo login fail" ... SecureWorks was still reading email addressed to David Maynor. ...
    (Full-Disclosure)