Best way to provide security when need a WindowsIdentity

[David Thielen]

Hi;

Suggestions please. This is for a portal that we will ship to multiple
customers so we need to make security as painless as possible while still
protecting them. This portal does reporting and therefore needs to read files
(xml) and databases (select only).

I see it falling into 3 categories:

1) All users are in the domain and all use IE as a browser. We can then use
windows authentication and all access of files and SSPI database queries is
done under the WindowsIdentity of the user. SingleSignOn and uses the
existing domain permissions - life is good.

2) Not all users are in ActiveDirectory - they may not even be on a domain.
In this case we use the asp.net user database and sign-on is via forms. For
reading a file (we only read) we give them the option of: a) anything the
server can read, b) they must enter a username/password each time and we
create that Windows user and then read, c) They store a username/password
with the filename as a datasource in our database and we use that to create a
user to read. For DB access we do the same thing using %user% and %pass% in
the connection string. This is by definition a less secure world but I don't
see what else we can do.

3) All users are in active directory but some do not use IE and therefore we
can't require windows authentication. I believe we can allow both windows and
forms authentication so we are still in group (1) for those using IE. But for
the rest, it seems to me we have two approaches when reading files/databases.
a) We store the username & password in memory (do not save anywhere!!!) and
create a WindowsIdentity to read. b) we run like item (2) above where we are
saving and/or prompting for a username/password for accessing data. It seems
to me the safer of these two is (a) because we are storing the password in
memory only. But choice (b) can be user/pass that have very limited
permissions so in that case, while they could be saved in our database, they
are not a user's credentials.

???

 

[Luke Zhang [MSFT]]

Hello,

I won't suggest store the user name and password in database. The user may
change their password periodly, and you need additional work to mantain the
database. The database security also need be considered seriously since
some may got all of your password once he get into the database.

Luke Zhang
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.)

 

[Joe Kaplan \(MVP - ADSI\)]

You also can't get a WindowsIdentity with users that are not Windows users,
so that rules out non-Windows user stores like SQL and ADAM.

However, if it is possible to use a more generalized concept for security
with the IPrincipal interface instead of specifically requiring
WindowsPrincipal (or perhaps using the role provider model in 2.0), then
you'll have more flexibility.

Joe K.

 

[Dominick Baier [DevelopMentor]]

for 2)

if you have to store the credentials - i would not recommend storing them
in a db - use caching in the web server to cache them for a short period
of time - don't cache the credentials in clear text.

for 3)

btw - you cannot have authentication mode=Forms AND Windows in the same application
- keep that in mind.

 

[David Thielen]

Ok, for choice (3) it's store credentials in memory on the server (encrypted)
and create a WindowsPrincipal as needed.

Question - can I create a WindowsPrincipal, attach it to the session, throw
away the username/password, and use that principal from then on in the
session?

For choice (2) we're going to ask our customers. I don't even know if anyone
will fall into this category.

 

[Dominick Baier [DevelopMentor]]

Hi,

session will not work very well - WindowsPrincipal/Identity is not serializable
- which is not a big problem when session is in-proc - but when you want
to switch at some point to StateServer or SqlServer - this will not work.

Cache will work - just sync the expiration time to your formsauth timeout
settings.

 

[Dominick Baier [DevelopMentor]]

even better would be to use protocol transition - this doesn't require to
store/cache any credentials at all.

but works only on w2k3 in w2k3 domains.

 

[David Thielen]

Hi;

I'm on vacation next week and because of you're guys feedback I'm taking the
..NET 2.0 security book. I don't know if I should thank you or ... <g>.

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

even better would be to use protocol transition - this doesn't require to
store/cache any credentials at all.

but works only on w2k3 in w2k3 domains.

 

[Michael Randrup]

Hi,

I have somewhat the same problem and I hope you can help me (Also posted
as a separate thread)

1) We have to validate extranet users on an anonymous-website using a custom
login page.
2) From this login page we redirect them to an extranet site, which shows
them sharepoint information, etc. e.g. from this point on their web requests
should be performed with their impersonated identities.

For them to use the sharepoint functionality we need to impersonate a
windows user that have the correct access to sharepoint. I have gotten so
far as to do the impersonation:

imp = New ImpersonationWrapper

imp.ImpersonateUser("username", "password", "domain")

Me.Context.User = New
System.Security.Principal.WindowsPrincipal(imp.NewId)


This sets the request context to the correct windows user, using a small
wrapper class around the Win32 LogonUser() API. I can now cache the
IPrincipal and set the context in each form_load() from this point on.

My problem is that when I for example, loads the sharepoint page in an
IFRAME on the page, it is not using my impersonated user?!?!

Do any of you have a good approach for doing this?!

Thanks in advance!

Michael