Please explain impersonation for non-technical users.Then please explain it in the context of ASP.NET. Is Impersonation good or evil? Do we use it in the case of Forms-based Authentication?
You should check out Keith Brown's description of impersonation. It is really a Windows concept.
When you have an application using forms authentication (FA) the IIS process is running under the credentials of a specific user setup in IIS.
Example: If you have a user called Bob logged on using FA and IIS setup to run as Network Service. Bob accesses a page which makes a web service call to another computer, the other computer will see the IIS user and not Bob. You can use impersonation to allow Bob to access the web service as a real Windows user and not Network Service.
Impersonation is not evil but it can be misused. You really need to understand the impact on your overall security model. It is also something that creates a lot of work for a developer to debug. This is especially the case if you do not have admin rights to the resource (eg. web service) you are trying to access.
Web applications run through a web server. That web server runs as a user with different permissions than yourself. Impersonation allows the application to run as you (or any other user with different priveledges on the cmoputer), as if you were logged in to the computer running it itself.
It actually makes things quite good. It allows you another way to grant/restrict access to protected files on the computer.
And yes, you can apply it using Forms Authentication (but you don't have to).
ASP.NET applications can execute with the Windows identity (user account) of the user making the request. Impersonation is commonly used in applications that rely on Microsoft Internet Information Services (IIS) to authenticate the user.
ASP.NET impersonation is disabled by default. If impersonation is enabled for an ASP.NET application, that application runs in the context of the identity whose access token IIS passes to ASP.NET. That token can be either an authenticated user token, such as a token for a logged-in Windows user, or the token that IIS provides for anonymous users (typically, the IUSR_MACHINENAME identity).
Related
I have three asp.net applications. Only one of them has a forms authentication login. I redirect anonymous users to that one login page for all three applications to login. Once they log in, they automatically redirected back to the application and page they were attempting to access.
I enabled this functionality by setting the same MachineKey in all three applications.
Is there a way to do this for ADFS 3.0 WIF authentication as well? It doesn't seem to work the same in my testing. When I log into the application that is wired up to ADFS, I still can't access the other two.
WIF and ADFS don't work the same way as traditional forms authentication. These technologies rely on issuing access tokens, and require that dependent applications (also known as Relying Parties, or RPs) configure a trust relationship with the token provider (AKA Identity Provider, or IP). You can't share the cookie with MachineKey between apps that have not directly authenticated with an IP, and to be quite honest you don't want to.
The typical web scenario (also known as Passive Federation) is to have a separate application that functions as a Security Token Service (STS). This application houses the Login.aspx page and is protected with Forms or Windows Authentication like you would find in a classic ASP.NET scenario. When you attempt to access a web application that requires authentication, it needs to be set up to redirect you to the STS website, rather than handling it by itself. Once you log into the central STS, it will issue you a token that you then provide to applications to gain access. If you use WIF properly, this is all handled behind the scenes and is just a matter of configuration.
Each of your three web applications should be configured with a trust relationship to your IP. You said that you have a web application wired up to ADFS already, if that's via the proper trust relationship, then you should simply have to replicate that set up to your other 2 applications.
This is a similar question to many that I have seen before but I have not found a clear answer yet so I will try to be very specific here to avoid duplication.
We are running IIS7.5 on 2008R2 with only windows authentication turned on (no anonymous) and no impersonation. There is a network account specified for the application pool user.
When I check the WindowsIdentity.GetCurrent() of the currently executing page I get the expected (App-pool) user based on our configuration.
http://www.mikeobrien.net/blog/identities-for-different-iis7/
This matches the expectations nicely. However, it appears that NTFS folder permissions on our application are being checked against the identity of the authenticated user.
This seems to contradict most of the documentation I have found. The above link as well as
http://msdn.microsoft.com/en-us/library/kwzs111e(v=vs.100).aspx
http://msdn.microsoft.com/en-us/library/3yfs7yc7(v=vs.100).aspx
http://msdn.microsoft.com/en-us/library/gg703322%28v=vs.98%29.aspx
How is IIS checking the authenticated user's identity in folder ACLs when .Net is clearly indicating that the WindowsIdentity in play is that of the App-Pool?
The only theory I have so far is that the file authorization module is utilized with integrated authentication automatically and it is explicitly checking this... but it still seems to go against the documented expectation.
http://msdn.microsoft.com/en-us/library/gg703322%28v=vs.98%29.aspx
This article, for example, seems to document both expectations.
When Windows authentication is enabled but impersonation is disabled, ASP.NET performs file access checks in the file authorization module using the credentials that are sent from the browser. Impersonation does not need to be enabled, because the FileAuthorizationModule module ensures that the requesting user is allowed read access or write access to the resource, depending on the request verb (for example, GET or POST) before executing the request.
Followed a few lines later by
Windows authentication without impersonation. This is the default setting. ASP.NET performs operations and accesses resources by using your application's process identity, which by default is the application pool identity on Windows 7 and Windows 2008 R2. For more information, see Application Pool Identities.
Windows authentication with impersonation. With this approach, the Web application impersonates the authenticated user and uses that identity to perform operations and access local resources. When you configure your application for impersonation, an impersonation token for the authenticated user is attached to the Web request thread. As a result, all local resource access is performed using the caller's identity.
My question:
What identity should be used when file system ACL checks are performed? (My understanding was App-Pool when impersonation = off) and what settings might affect which identity is used outside of impersonation?
This is very similar to this question:
Does an IIS 7.5 web app with windows authentication require end users to have file permissions?
The marked answer on this question does not address my concern. Authorizing 'authenticated users' group should not be required as the identity being used should not rely on the set of end-users being authorized. My question is much more specifically, which identity and how is this controlled?
"NEW IN IIS 7.5
IIS 7.5 added the authenticatedUserOverride attribute to the element, which configures whether the IIS 7 server runtime will provide the authenticated user's identity or the worker process identity in the IHttpUser::GetPrimaryToken and IHttpUser::GetImpersonationToken methods. This attribute can be set to UseAuthenticatedUser or UseWorkerProcessUser, and these values respectively specify whether the IIS 7 server runtime will provide the authenticated user's identity or the worker process identity for any module that is using impersonation."
Source
This will probably turn out to be a doozie.
I'm developing an application in ASP.NET to be put on our company's intranet site. I've been handed a specification in regards to security and have no idea how to do it.
First part: The application is to use Windows Authentication. This part seems easy enough; I opened IIS in Administrative Tools, right clicked the node of my website, properties and checked 'Integrate Windows Authentication'. However, I have no idea how I will govern which people have access to my site. I'm thinking this should be taken care of at the database level. This is Q#1
Second part -- I have to implement a process for the following scenario: User 'Jane' can log in to our network, but does not have rights to my application. User 'Bob' does have rights to use my application. Bob needs to be able to sit at Jane's computer (under her network account), but be able to enter his credentials into my application and use it (even though Jane is logged into the local machine and network). This is Q#2
Any help, general direction, or advice would be appreciated. The winning lottery numbers would be appreciated even more.
Thanks,
Jason
You're looking for Windows Authentication and Authorization in ASP.NET
How To Use Windows Auth in ASP.NET
Authentication/Authorization Explained
How To Implement Windows Auth in ASP.NET
Part 2...you're right, that's tough. You'll need to roll your own custom security provider.
You'll have a login page, then check that against Active Directory yourself. From MSDN
ASP.NET also supports custom solutions
for using Windows authentication,
which bypasses IIS authentication. For
example, you can write a custom ISAPI
filter that checks the user's
credentials against Active Directory.
With this approach you must manually
create a WindowsPrincipal object.
You've got requirements around authentication and authorization here.
Authentication: The act of confirming identity
Authorization: The act of correlating an identity to a privilege (eg Read/Write/Delete)
Windows Authentication is useful if you want "auto-signon" capability. The site will "know" the user by ID without them having to sign in.
The need for users to login from multiple locations means that you must implement a login page. This would fulfill your requirement in which one user may sit at another's workstation and log in.
You will want to authenticate users against the Windows domain. This can be done with a custom membership provider. Here's a walkthrough:
http://msdn.microsoft.com/en-us/library/ms180890(v=vs.80).aspx
This will allow you to present a login page that will authenticate users with their domain username and password. This will authenticate users- the identity of the user will be stored in the HttpContext.User. You can then also maintain a user list in a database to store authorization data.
Also found this -- a pretty good resource for anybody out there who's in the same boat:
Mixing Forms and Windows Security in ASP.NET
http://msdn.microsoft.com/en-us/library/ms972958.aspx
I was wondering when using Windows Authentication mode in a connection string from a web application. Application itself is using Windows Authentication for authorization. Which account will be used to login to SQL Server.
Is't the web application pool account?
User account who logged in to web application using windows auth?
Any other account?
Application is running under Win Ser 2008 64 bit and IIS 7. Application pool account is Network Service.
It depends on how you configure it. From http://msdn.microsoft.com/en-us/library/ms998292.aspx and http://msdn.microsoft.com/en-us/library/bsz5788z.aspx ...
ASP.NET applications do not impersonate by default. As a result, when they use Windows authentication to connect to SQL Server, they use the Web application's process identity. With this approach, your front-end Web application authenticates and authorizes its users and then uses a trusted identity to access the database. The database trusts the application's identity and trusts the application to properly authenticate and authorize callers. This approach is referred to as the trusted subsystem model.
The alternative model referred to as the impersonation/delegation model uses the original caller's Windows identity to access the database. This approach requires that your ASP.NET application is configured to use impersonation. See the section "Impersonation / Delegation vs. Trusted Subsystem" in this document.
So depending on how you have configured it, it could use either the app pool account (not when not using impersonation) or the account of the logged-in user that is using the web application (when using impersonation).
See http://msdn.microsoft.com/en-us/library/134ec8tc.aspx for impersonation information.
It's the application pool user who connects to the database, if you specified Integrated Security in your connection string.
The problem that i was having was that my application pool account in SQL Server needed to be set to the db_owner role before it worked. I spent a long time trying to figure this out.
I was using Windows Authentication, Windows 7 home premium, and IIS all on the same computer. I'm posting this in case someone else run into a similar problem. The book i used did not say to use db_owner but the reader and writer accounts instead.
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:
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.
The user logs in.
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.
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
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.