Re: Going from anonymous security to Windows Security in an ASP.NET application



Hello,

as I said in my previous post - there is no context on the client...

Your page.context exists purely on the server. Once the site has been sent
to your browser, all that is discarded.

Next step, your browser renders the bits from the server, encounters an
IFrame tag and then fetches the content the frame. That a second, complete
independent request.

You won't get a single-signon experience this way...

Greetings,
Henning Krause

"Michael Randrup" <michael_randrup@xxxxxxxxxxx> wrote in message
news:uE%23eIkdUGHA.2156@xxxxxxxxxxxxxxxxxxxxxxx
Hi Henning,

Thanks for your suggestion. Although it wouldnt work for me in the real
work, because the main site is actually a puclic website, so I have no
control over the browser settings, I just tried your suggestion with my
own browser.

Apearantly the IFRAME posts a second request, which is not in the same
context as the first request for which i am impersonating the
page.context.user object :-(

I would still be happy to hear any suggestions from people, on how it
"integrate" a public website, with a Windows Authenticated website, where
we need to have our own login page instead of the standard Windows logon
dialog.

Regards,
Michael



"Henning Krause [MVP]" <newsgroups.remove@xxxxxxxxxxxxxxxxx> wrote in
message news:%23EZhHecUGHA.328@xxxxxxxxxxxxxxxxxxxxxxx
Hello,

the Iframe is populated on the client, not on the server. Therefore, any
impersonation, which takes place on the server has no effect on page
loaded in an IFrame.

Internet Explorer does have a setting regarding windows authentication -
it's buried in the security settings for the
internet/intranet/trusted/restricted sites. If you set this to "Automatic
logon with current username and password", the user won't have to
identify themselves each time.

No other solution here, I'm afraid.

Greetings,
Henning Krause


"Michael Randrup" <michael_randrup@xxxxxxxxxxx> wrote in message
news:O8SROCcUGHA.5148@xxxxxxxxxxxxxxxxxxxxxxx
Hi,

I have the following problem:

1) We have to validate users on an anonymous/public-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 not
as anonymous users. The extranet sites uses Windows Integrated Security,
while the "main site" uses anonymous logins.

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)Me.Cache.Add("W",
Me.Context.User, Nothing, DateTime.MaxValue, New TimeSpan(0, 10, 0),
CacheItemPriority.High, Nothing)


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:

Me.Context.User = CType(Me.Cache("W"), IPrincipal)

My problem is that when I, for example, load the sharepoint page in an
IFRAME on the page, it is not using my impersonated user because the
sharepoint page is located in another web application or something?!?!

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

Thanks in advance!

Michael







.



Relevant Pages

  • Re: Kerberos delegation trauma
    ... Kerberos delegation won't solve this. ... > when the tool on my machine tries to access the server. ... On my machine I have set IE to have Enable Integrated Windows ... > my IIS for my web application directory and have impersonation set ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: no Access to Client-Files with "impersonate=true"
    ... This happens because you're using "Windows" authentification on IIS. ... Impersonation works fine on the server, ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: disable right click on icons
    ... > one of my server is a terminal server for application and my client ... > the server is a windows 2000 domain controller. ... > 5- Remove Windows Explorer's default context menu Enabled ...
    (microsoft.public.win2000.group_policy)
  • Re: RPC_C_IMP_LEVEL_IMPERSONATE does not work beyond machine boudaries
    ... First, impersonation ... This is new behavior in Windows ... able to impersonate a client to yet another server. ... realize that delegation is a serious responsibility. ...
    (microsoft.public.platformsdk.security)
  • Re: Authentication
    ... When you run an ASP.NET page it executes in the context of the ASPNET user, ... Give the ASPNET user propery rights to create/delete the file. ... different account on Windows 2003 server, ... > Using my own machine(not a server) using Windows athentication, ...
    (microsoft.public.dotnet.framework.aspnet)