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.
Related
I have a requirement to integrate an ASP.NET web application with active directory - basically they want to be able authenticate and authorize with AD.
I realise this is relatively simple, but what I want to know is how I can simulate the AD for developing and testing against. I don't have AD available to me (right now) and don't cherish the thought of setting it up even if I had hardware available to run it on.
What other options are available to me? I've seen ADAM mentioned in a couple of places but this doesn't seem to provide the federation services I need (and seems a little out dated). Would it be possible to use Azure for this? I want to keep costs (time-wise as well as money) to a minimum.
I have managed to set up an active directory environment suitable for development using a Microsoft Azure VM.
A brief summary of the steps I went through to get this working are below. Although it sounds scary setting up AD and ADFS, the windows server 2012 interface makes it incredibly easier, barring a few gotcha's I mention below - it takes a while for them to install as well.
Create a new azure windows server 2012 VM and add endpoints for http and https.
Install the AD role on the VM
Install the ADFS role on the VM
Create an ASP.NET MVC 4 app (on your dev machine) and verify it is working correctly.
Run the app through IIS (not IIS express - this just makes SSL etc easier).
Ensure the site has a https binding set up
Install the Identity and Access tool for VS2012
Right click your project to select the identity and access tool.
The path to the STS meta document will be https://<your VM url>/FederationMetadata/2007-06/FederationMetadata.xml (you may need to download this file manually if your certificates are self signed).
Back on your VM, in ADFS create a relying party trust for your application.
Run your MVC app again and you should be redirected to your VM for authentication and then back to your app again (but this time using https).
If you are using the default MVC template, in the top right corner assuming you have set up the claims correctly, you should see Hi, <user>#<domain>
The main articles that I followed to achieve this are as follows:
http://blogs.rondewit.com/post/MVC-2b-ADFS-20-Federated-Authentication.aspx
http://garymcallisteronline.blogspot.co.uk/2013/01/aspnet-mvc-4-adfs-20-and-3rd-party-sts.html
Below is a list of gotcha's that I hit (in no particular order).
When setting up the relying party trust enter the data manually and ensure you set the Relying part WS-Federation Passive protocol URL and the relying party trust identifiers correctly. The first is simply the https url that ADFS will redirect back to after authentication has completed - https://localhost for example. The second is an identifier used to identify the application that is trying to authenticate. One of the identifiers entered must match the realm attribute of the wsFederation node in your MVC 4 apps web.config.
When logging in the username should be of the form <domain>\<username>
I couldn't get Windows Authentication to work with any browser other than IE. For this set up to work with Chrome I had to change the order of the local authentication types in the web.config of the adfs/ls application so that forms authentication appeared first. To get to this, open up IIS manager on your VM, expand default web site/adfs/ls, right click ls and select explore.
At the time of writing I haven't been able to login with an AD user I created myself - I've probably just not set it up correctly. When setting this up initially, I'd suggest trying to connect with the admin user you created through the azure portal when you created the VM.
Once I finally managed to authenticate correctly AntiForgeryToken html helper started throwing an exception, talking about missing claims. Ensure that you have added a claim rule to your relying party trust, that sets either the name or name id claim. Then in Application_Start do the following: AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name; as explained here.
It is also worth noting that the Identity and Access tool allows you to setup authentication with Azure ACS and more noteworthy, a development STS. For my requirements, I need to be able to integrate with ADFS, but if you're just experimenting with claims based authentication, one of these may be a better option than the process that I have gone through above.
Consider ADFS and ws-federation.
Ws-federation is an enterprise sso protocol that gives you cross domain authentication/authorization in a sso manner. Adfs is a free implementation of the protocol that sits on top of the active directory. It is relatively easy to set up.
But having a client application that expects a ws-federation identity provider, you can substitute the provider with any compliant provider, your own or the identityserver which is another free implementation but can use a membership provider. The completely custom implementation on the other hand would give you a chance to set up and serve an
arbitrary identities.
The is a small learning curve for this approach but benetifs are:
cross domain sso
support for multiple browsers for free (kerberos/ntlm based ad authentication could be unsupported on some browsers)
works in an intranet and the internet
support for advanced scenarios like for example you can set up your cloud Office365 to authenticate against your local adfs
adfs 2.0 is free component dowloadable from msdn
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
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).
I have a website with a large user base configured with asp.net 2.0 forms authentication. Before the user logs in via forms authentication is it possible to retrieve the windows login name/user account name on the machine they are using?
Many thanks
It certainly is possible--by adding another web application to your system. Here's roughly how I have done it:
Your primary web app uses Forms authentication. On the forms login page, any user that is determined to be on the local LAN (check IP address), redirect them to another app that uses Windows authentication. In this second app, you can determine the user (assuming the browser is configured to send credentials automatically to the zone in which your app resides), then set a cookie which your first app can read, and redirect the user back to the original app.
This does work.
This would only be possible if you were using Windows Authentication in your web application and then only if the user had logged in.
The kind of information you are after is not sent as part of the web request (quite rightly) and is therefore unknown to the web server.
Unfortunately no - if the user has not logged on, they are browsing anonymously, and are therefore unknown to the server. There is no way to identify them.
Once they're logged on, if you're using impersonation use WindowsIdentity.GetCurrent().Name. However, for forms authentication there's no direct way to ask the browser for their Windows credentials as they may not even be running Windows!
Not BEFORE no (not from the server).
Depending on the type of Auth you use, though, and the way the site is configured, you CAN get them to log in with their windows details.
See Mixing Forms and Windows Security in ASP.NET on Microsoft's MSDN.
The main difference with #TheObjectGuy answer is that instead of using 2 websites, this does all in a single website by configuring IIS to use the Integrated Windows authentication just in a "single" page (WinLogin.aspx).
I am in the process of writing an application that will need multiple forms of authentication.
The application will need to support authentication to Active Directory, but be able to fail back to a SQL Membership Provider if the user is not in Active Directory. We can handle the failing to the SQL Provider in code based on the username provided because the username will be a different format than the Active Directory username.
Is this even possible? What I mean is, can I use membership and use both ActiveDirectoryMembershipProvider and SqlMembershipProvider together or will I have to roll my own?
Another additional added complexity is that I would like to automatically authenticate my internal users based of Windows Authentication back to AD, but use Forms Authentication for users not on our internal network, or users that are using the SQL Provider.
These will most likely be separate servers, one internal, and the other external so I have a lot of planning to do to figure out the data replication, and how I will authenticate the AD users if they hit the outside server etc.
I am wondering what thoughts are out there as I start down this road. Is what I am wanting to do even possible without me rolling my own, or is there a way to mesh these together?
Thanks for the reply.
The reason I asked originally was because I was able to get this specific senerio working about 7 years ago using IIS to authenticate and then passing back the credentials to a Lotus Domino Server Web App. If the user was not authenticated via the Windows Authentication/ISS then Domino would handle the authentication. This was what I was looking to do here, but really couldn't think of a way to make it work in IIS.
As for the rest of your reply, I think you are on to the way that I will need to take. I have thought this through and tossed it around in my head a lot. The application will be somewhat different on the two servers anyway since there is going to be limited access to the data on the external server anyway. The fact that so much is going to be different already I may just treat these as two applications, thus negating the need to use two types of authentication in the same application anyway.
I am playing around with the idea already of writing my own authentication/login window for the external server, and if the user trys to log in with their AD credentials on the external server I will be able to detect that and redirect them to the internal server. If they are not on the local network or VPN'd in they will simply not get access. This part still has some thought process to go though so I am not sure.
As an additional thought - is there a way to pull just enough of AD into a SQL database to allow me to authenticate users to the SQL database from the external server using their AD credentials, without creating any security issues? I hope I am clearly typing what I am thinking....
Thanks again!
Tim
This is the way I've handled a similar situation based on this info:
Configured the application to use Forms authentication.
Set the LoginUrl to a page called WinLogin.aspx.
In WinLogin.aspx, use Request.ServerVariables["LOGON_USER"] to get the username then call FormsAuthentication.RedirectFromLoginPage( authorizedUserName, false ) to log them in. I guess you can manually check Active Directory as this point as well.
Create an html page that redirects to a page called Login.aspx
Login.aspx is your standard username/password login.
In IIS, Enable Integrated Authentication and Anonymous on the entire site, but deny anonymous access to WinLogin.aspx.
In IIS, set your 401 errors to the page created in step 3.
What basically happens is that when an unauthenicated user hits the site, they're redirected to WinLogin.aspx. Since anonymous is turned off, integrated security makes a check. If that passes, your custom code in WinLogin can run. If the integrated security check fails, a 401 error occurs. Your custom 401 page redirects to Login.aspx where the user can log in using their username and password with the SQL provider.
As far as I know, Web Applications are configured to use either Windows Authentication or Forms Authentication, but not both. Therefore, I do not believe it is possible to automatically authenticate internal users while requiring others to enter a username / password.
You could authenticate to Active Directory or a SQL user store via Forms authentication by using a custom provider. However, the AD users would still need to enter their username and password. Although I've never combined these two methods, I have used Forms authentication to authenticate against both sources at one time or another.
With that said, I think you may want to consider reducing the "flexibility" of your system. If you have an external facing server and an internal facing server, you could simply change the provider configuration on each copy of the application to go against a different source. Then, you could configure the internal one to use Windows (automatic) authentication and the external one to use Forms authentication.
IMHO, I believe that internal users should not be using the external server to access the application. If they are, they should have a user account stored in SQL, completely separated from their AD account. Basically, when someone accesses the application externally, they are acting as an external user, irregardless of their physical location.
Well, it is possible to use ActiveDirectoryMembershipProvider and SqlMembershipProvider, but this requires you design your log on page with your own code instead of the Login controls.
About the mix authentication (Windows and Forms), as far as I know only IIS 7 makes it easy and clean. See this post for details,
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx