Re: Best way to provide security when need a WindowsIdentity
- From: "Michael Randrup" <michael_randrup@xxxxxxxxxxx>
- Date: Mon, 27 Mar 2006 18:56:32 +0200
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
"Dominick Baier [DevelopMentor]" <dbaier@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
wrote in message news:4580be63198a8f8c81c03dc44ac93@xxxxxxxxxxxxxxxxxxxxx
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
http://www.leastprivilege.com
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:
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.
???
--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com
.
- References:
- RE: Best way to provide security when need a WindowsIdentity
- From: Dominick Baier [DevelopMentor]
- RE: Best way to provide security when need a WindowsIdentity
- Prev by Date: Re: StrongNameIdentityPermission
- Next by Date: Going from anonymous security to Windows Security in an ASP.NET application
- Previous by thread: RE: Best way to provide security when need a WindowsIdentity
- Next by thread: ADAM and AuthorizationStoreRoleProvider
- Index(es):
Relevant Pages
|