impersonation for file & DB access

[David Thielen]

Hi;

I thought I asked this before - but I can't find it. So apologies if I did.

I need to access both files (opening/reading) and databases (connect using
SSPI) impersonating the client user. THere are two modes for this:

1) Windows authentication - we use the credentials from the client to
impersonate. How do I do this?

2) AspNetSqlMembershipProvider - I prompt them for their Windows username &
password and use that to impersonate them. Once I have the username/password,
how do I set up the impersonation?

 

[David Thielen]

ps - I don't want everything to run impersonating the client user - I just
want to impersonate for short periods in the code on the server side. (Yes
more fo a pain, but I think more secure for what we are doing.)

 

[Dominick Baier [DevelopMentor]]

with Windows auth you have the option to impersonate for the whole length
of the request with <identity impersonate="true" />.

Or you grab Context.User.Identity and call Impersonate() to impersonate temporarily.

with forms auth you can use the uname and pwd to call Win32 LogonUser. This
implies that you have to store the password for the user (bad) or that you
create a WindowsIdentity and cache it.

 

[Steven Cheng[MSFT]]

Thanks a lot for Dominick's informative suggestion.

Hi Dave,

As Dominick has mentioned, in ASP.NET web application, we can perform
impersonation both declaratively(in web.config) or programmatically(in
application/page's code). The difference is that when using web.config
(<idenitity impersonate="true" >) , the whole worker request is
impersonated and running under the impersonate account from start to end.
While programmatically impersonate can let us control when to
impersonate(may be we just want to execute the code under the particular
account in certain period , such as when accessing a certain database....).


In addition, here are some good msdn articles describing the impersonation
in ASP.NET and how to use windows authentication:

#How to implement impersonation in an ASP.NET application
http://support.microsoft.com/?id=306158

#How To: Use Impersonation and Delegation in ASP.NET 2.0
http://msdn.microsoft.com/library/en-us/dnpag2/html/paght000023.asp?frame=tr
ue


#How To: Use Windows Authentication in ASP.NET 2.0
http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000025.asp?frame=tr
ue

hope this helps.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[David Thielen]

Hi;

Thank you and I would NEVER store the uname/password in our database. As it
is I'm very very nervous that I prompt them for it and have it in memory long
enough to create a WindowsIdentity.

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

 

[Joe Kaplan \(MVP - ADSI\)]

The thing I'm confused about is that if the backend of your app requires
Windows authentication features, why use anything but Windows
authentication? It seems to me like you end up at cross purposes if you are
trying to use SQL membership and roles if you still needs Windows security
features to drive important parts of your app.

Can you elaborate on this?

Joe K.

 

[David Thielen]

I would be happy to elaborate - this whole thing has me nervous that we will
end up with a bigger security exposure than necessary.

We are creating a reporting portal. It's an extension of
http://www.windwardreports.com where no programmer is required. So they go in
and upload a report template and define datasources. Datasources are xml
files (or urls) and/or sql databases.

If the company using the portal has all users as domain users, then windows
authentication works great - except for sql databases other than Sql Server.
Other databases don't have SSPI login so we must have a username/password.

If the company is not on a domain, or will have people accessing the portal
that are not domain users, then we are stuck with forms authentication. I can
see this happening: 1) Big company, small group using it - they can't get our
4 required groups added to the domain; 2) Small company, not on a domain
server; 3) Some of the users are not domain users.

I don't want to have us handling access rights to files and databases for
two big reasons. First, if we screw it up, we've let people in and we're
responsible for the security breach. Second, a company has already put in the
effort to set access rights for users to files and databases. It's additional
work for them to duplicate it in our system.

So I want to impersonate, then open a data file or sql database connection.
And in the case of not Sql Server, use the client user's uname/pw in the
connection string.

We are giving the user's the option of we store their uname/pw in our
database or we prompt them the first time and store it in memory, prompting
again if the session expires.

What do you think?

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

 

[Joe Kaplan \(MVP - ADSI\)]

Ok, I think I can see what you are trying to accomplish. When you get
outside of the pure Windows domain environment, it will get tricky to pull
this off. The Windows domain environment will also have additional
challenges with impersonation as you will have delegation scenarios there if
you are accessing remote resources.

It sounds like you are on the right track with what you are doing. When
someone defines a source, they'll need to tell you how they want to access
it. If they choose to use Windows auth, then there will be a fair number of
options there.

I like Dominick's suggestion of not storing the credentials and caching the
WindowsIdentity you use for impersonation. If that isn't available in the
cache, then you may need to reprompt for credentials. All in all, it might
be a little painful for the users, but you will be more secure if you don't
store their plaintext credentials. Ideally, you will never have them in the
first place.

Best of luck with this this. It is going to be tricky for sure getting all
of the scenarios working.

Joe K.

 

[David Thielen]

You said it. That's why I'm asking so many questions - by definition we will
have security weeaknesses and I'm trying to keep them to the absolute minimum.

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com


:
....

 

[David Thielen]

Hi;

I think the answer to this is no... but it can't hurt to ask.

Can I get the user's uname/pw, create a WindowsIdentity from that, and then
store that WindowsIdentity in my database? Then when they later need to
access the datasource, I have their WindowsIdentity to use, but I didn't
store their pw in my database.

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

 

[Dominick Baier [DevelopMentor]]

no but you could cache the WindowsIdentity and use it at a later point for
impersonation - you could write some logic to sync the caching to FormsAuth
timeouts...

 

[David Thielen]

BTW - this is working great. I'm a little nervous about what some customers
may do but I think I have this as secure as can be for the requirements some
will have.

I do wish LogonUser/CloseHandle had a .NET equivilent - this is our first
non managed code calls in the entire program (yuck).

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

 

[Joe Kaplan \(MVP - ADSI\)]

Agree. It would be nice. I'm guessing they made a specific decision not to
support this too as they definitely put a fair amount of effort in to
support S4U login with WindowsIdentity.

I don't know any inside details though.

Joe K.