views:

827

answers:

2

My supervisor at the office tells me that he saw a demonstration with a pre-release version of Microsoft "Geneva" (now Windows Identity Foundation) where a developer did the following:

  1. He set up some sort of ASP.net web application where a user could log in using a customized log-on system. Behind the scenes, the web application logs the user in as a user in an Active Directory.

  2. The user logs in.

  3. Once the user is logged in, the the ASP.net web application thread runs as the logged in user for the duration of the user's session and can access resources on the network (such as running SQL queries on tables whose access is controlled Active Directory)

Steps 2) and 3) are exactly the same as using the "Integrated Windows Authentication" setting in the "Directory Security" tab of the web site settings in IIS. Step 1) is different because we are using a custom log-on system as opposed to the Kerberos authentication.

We want to set up one of our applications to operate exactly as described in 1), 2), and 3). However, all the documentation that I've seen regarding Windows Identify Foundation is about Cardspace and Federated Security. We have zero interest in using either of these technologies right now.

We just want to be able to log users in to Active Directory Accounts behind the scenes.

Yes, we've tried the ActiveDirectoryMembershipProvider with Forms Authentication, but it's a complete kludge to actually access resources on the network requiring impersonation on every page!

UPDATE Jan 7, 2010. Okay, I've been working at this for a while, and everything I've managed to come up falls short of what I want to achieve. Perhaps the functionality I want is not in the release version of WIF.

Here's where I'm at now. I've found some documentation on MSDN that indicates that there are three different identities used in ASP.net: the identity specified by HttpContext.Current.User, the identity specified by Thread.CurrentPrincipal, and finally the identity specified by WindowsIdentity.GetCurrent. link

In one example of where I want to use the process I'm looking to design, I want to perform a SQL query as the logged in user. In my debugger, I see that I easily set the HttpContext and Thread users to the logged in user. However, when I connect to the SQL server using Windows Authentication, it always always always connects as the WindowsIdentity.GetCurrent user and that user is always always always the identity of the ASP.net process unless I'm using Windows Authentication with impersonation. I absolutely cannot use Windows Authentication with my application because my users must log in by playing a magic flute song and Windows Authentication has no support for logging in with magic flute songs.

To clarify, there is no trouble with obtaining a WindowsIdentity representing the logged in user (who logged in with a magic flute song). The problem is that I cannot use that WindowsIdentity to perform SQL queries for my user.

+5  A: 

WIF allows you to configure it so a claims based identity maps to an AD account, the claim may either be a federated identity claim, or delivered via an information card. c2WTS performs this function.

Even when it does map because of delegation you're always going to have to delegate if you want to use the AD identity IIS is impersonating - that's just how it works, unless you setup Kerberos delegation for IIS

blowdart
My supervisor is very specific that he does not want to use impersonation. Also, the end-user will be logging in by playing a song on a magic flute. If the song is correct, then the user is programmatically logged in using an AD account.I have absolutely no way around the fact that the user logs in by playing a song on the magic flute.What I need is some way to make the program behave as if they are logged in with Windows Authentication once they play the magic flute song correctly.
Rice Flour Cookies
No, you're asking the impossible. Windows Authentication uses impersonation, if your supervisor says you can't use it, then you can't mimic Windows Authentication.
blowdart
Thanks, blowdart. I must correct myself. What I meant is that when you use Windows Authentication with IIS, the web server transparently impersonates the logged in user. With Forms Authentication, I have to do impersonation programmatically, which we desire to avoid; the AdMembershipProvider doesn't help me with this at all, it seems. I cannot impersonate with a Forms Authentication cookie.My sup. says that he saw a demo where Geneva was somehow used to make it so that a user is logged in with an AD account automatically even though the user logs in with his magic flute song.
Rice Flour Cookies
Also, blowdart, to clarify what I meant about AdMembershipProvider not helping me with the impersonation; I mean that I have to manually call the Win32 LogonUser function and use the token it returns to impersonate the logged in user. What a kludge! There must be a better way.
Rice Flour Cookies
Well Windows Auth impersonates to a point. However, then back to the original answer WIF can map tokens to particular users and impersonate them.
blowdart
I believe that I may have confused the issue with the talk about impersonation.What I need is to log my user in with the magic flute song and have it just the same as if the user had logged in with Windows Authentication.
Rice Flour Cookies
Like I said originally yes it's possible. All your nonsense about magic flutes is confusing the issue more than anything else.
blowdart
+1  A: 

You can achieve the same using Identity Impersonation in ASP.net. Also you need to enable windows integrated authentication for you web app. This will solve the purpose. If the logged in user does not have the required rights to access resources you will get security exceptions which you will have to handle.

Hemanshu Bhojak