RE: Best way to provide security when need a WindowsIdentity


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

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.

"David Thielen" wrote:


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 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.


thanks - dave