I have a parent application in IIS7 which uses Forms authentication. Within that app, I have another application (not virtual directory) which I would like to inherit the parents forms authentication settings.
The authentication in the child app is not working, when i call System.Web.Security.Membership.GetUser() it returns null.
Both the web.configs have the same authentication sections, both are set to have the same machine key and both are using the same app pool. Does anyone else have any more ideas?
Thanks
Without a proper look at the applications its difficult to see what could be happening, however, I do have a suggestion. Previously, I've written a class the encrypts the username in a cookie using something like a session id as a hash.
The next app can then check for the cookie, decrypt the username and authenticate the user.
The only issue with this is the cookie access. It only works for apps with the same parent domain. E.g. A cookie of domain.com would be accessible to www.domain.com, app1.domain.com and app2.domain.com.
Another solution, that would get around the domain issue, would be a Shibboleth implementation.
Related
After we have moved to Azure farm, I have implied Azure Session State Provider (redis) to my asp.net mvc application, But some Authorized pages redirect me to login page !!
Is that because I use User.Identity.Name or User.Identity.IsAuthenticated in some actions!!
Do I have to replace the User.Identity.Name with :
// instead of below line
//Boolean usern = User.Identity.IsAuthenticated;
// is below lines :
Boolean usern = "";
object objValue = Session["usersession"];
if (objValue != null)
{ usern = true;}
else {usern = false;}
Is that right, if not why users redirect to login again sometimes !!!
This is probably not a session issue but rather an authentication cookie/ticket issue. Azure most likely has their servers load balanced, even if you are only using a single instance/role(this gives them reliability %). Meaning that your application actually exists on more than one server at a time.
The MachineKey in a .NET app is what is responsible for encrypting and decrypting your authentication cookie. In your web.config, if you are not properly defining the <machineKey> attribute, then IIS makes up a machine key for you. Each server running the application will make their own machine key if it is not defined by you. As a result, one server is able to decrypt and read your authentication ticket, while the next request goes to another server which cannot decrypt the authentication ticket because it was encrypted with a different key and this server thinks that you are not logged in.
To address this issue, open your web.config file and define your <machineKey> attribute and redeploy. Once you login with the newly deployed application, you should see this issue disappear.
Forms authentication and Machine Key information on MSDN
Machine Key Generator
I don't think the session management would do this, regardless of Azure Redis or otherwise. If you are using asp.net authentication cookies you need to make changes to support multiple roles.
I know this is an old article but if you look through Moving Applications to Microsoft Azure Cloud Services you will see this:
There is one further change to the application that potentially
affects the authentication process. If you were to run the aExpense
application on more than one web role instance in Azure, the default
cookie encryption mechanism (which uses DPAPI) is not appropriate
because each instance has a different key. This would mean that a
cookie created by one web role instance would not be readable by
another web role instance. To solve this problem you should use a
cookie encryption mechanism that uses a key shared by all the web role
instances. The following code from the Global.asax file shows how to
replace the default SessionSecurityHandler object and configure it to
use the RsaEncryptionCookieTransform class.
essentially if this is happening the redirects to the login page are because you are bouncing to a different instance and it could not read the asp.net auth cookie and just assumed the user was not authenticated as a result.
We have several web applications. When we run anyone of them we enter username and password and some cookies (user id) have been sent to client computer. When we run some another application, we should be able to check if we already logged on in some of our applications and if so, we automatically logged on to other applications without entering username and password.
It seems we should search for cookies in other applications to check if they exist. As I know cookies exist in context of particular web application and I'm not sure if we can check their existence in other applications.
How to resolve this?
If your web applications are being hosted in sub-domains of the same domain (e.g. exchange.contoso.com and mail.contoso.com), then you can easily exchange cookies between sub-domains by setting the "Domain" property of the HttpCookie object to .contoso.com:
Response.Cookies["auth"].Domain = ".contoso.com";
Hope this helps.
I'm writing an internal web application right now (with ASP.Net Web Forms), and it presents an odd problem. I have to be able to impersonate the currently logged in windows user, and execute a command based on their Windows Authentication to log in.. AND ... if they don't have Windows Authentication set up in the application I have to use to log them in, I have to be able to accept a user name and password. I also have to write the application in .Net 4.0, and secure it as much as possible. I got this to work by NOT utilizing Windows Authentication or Forms Authentication in the web.config, and instead setting session variables to guard against user accessing pages in the web app other that the log in. I did this by creating an oddly name session variable with a value based on their user name (windows auth or not), and then a secret session variable. The secret variable is in the web.config as a 256bit encrypted string, in which I decrypt, and set as the session secret. In order for the page to load, the first session variable can't be blank, and the second variable has to equal the decrypted key value... if the variables don't pass inspection, it redirects them to the login page. I set this up on every page, generic handler, and webservice method in the web app. I make the session timeout after a few minutes of no activity, and on log out, I set all session variables to nothing, and expire all cookies. (I also disable all cache).
My question is... Does this offer comparable security to that of Forms authentication? I have always used Forms authentication, but can't use it here. If I did, the users would have to reconfigure settings in IIS and in he web.config to toggle login procedures (From my knowledge, you can't use both Forms authentication, and windows authentication to manage the security of your pages and other web resources). With the method described above, I can accomplish the best of both worlds, but am curious about the security of my methods. Is there anything else I can implement here to assure the utmost security other that using forms authentication? Is it possible to accomplish the same level of security of Forms authentication without using it?
Thank you for any insight in advance!
Does this offer comparable security to that of Forms authentication?
No
The first rule when it comes to security is don't reinvent the wheel unless you absolutely have to. Any home baked solution you come up with has the potential to be as secure as a provided one like Windows or Forms Authentication. The problem is that home-grown solutions rarely reach that potential. They may test okay, but subtle bugs can remain. You don't want to find out a year later that you were hacked six months ago. Existing solutions have already been tested and used in millions of applications, whereas yours will be used in one application and tested by a handful of people at most.
A quick search suggests that it is possible to implement both Windows and Forms Authentication in the same application, so I'd pursue it further.
Mixing Forms and Windows Security in ASP.NET
I'm looking for a way to pass some sort of credentials or Authorization token from a VB.Net Client to an ASP.Net web application that allows the Client to auto-login to our Forms-Authenticated website. If a user is logged into a local application, I want them to be able to view some web pages without having to login to the website as well. The credentials are not the same between the apps, but I would just like to pass some sort of encrypted token or key to the web page so I know they are coming from the desktop application. Is this possible without requiring a username and password login?
I also need to make sure this URL that is used cannot be simply copied and used from another location, so I'll need to include some sort of information in the encrypted value to know where it's coming from.
I know how to login the user with Forms Authentication and all that, just need to figure out the best way to secure this. Thanks!
OAuth is commonly used to allow desktop applications to access a user's private data on a web site. Since you're using .NET, I suggest you check out DotNetOpenAuth which includes sample OAuth web sites and client applications. It allows for this secure token to be passed that can tell your web site that the desktop app is the one making the requests and (usually) whose data is being accessed.
The best part about the OAuth solution is your desktop app never has to ask for the user's credentials. No credentials are in the URL. And if the desktop application is ever compromised (perhaps by the computer being stolen), the web site can kill the secure token the desktop app was using to cut off access without requiring the user to change their password.
You might want to look into issuing client-side certificates for these applications. Basically, you generate a certificate that you install with the client application and then on the server side, you check the ClientCertificate property of the HttpRequest instance exposed by the Request property on the current context.
Note that what you are doing is really a very bad idea, in that applications should never be assigned identity, only users. To that end, you should be authenticating each and every user that is using your app, not considering the application to be the identity. It's commonly considered a bad practice to do such a thing.
You can share credentials between the applications using ASP.NET Client Application Services.
Here are some resources:
Client Application Services
Client Application Services with Visual Studio 2008
Is your desktop app running on machines that are in the same domain as your web server (i.e. all in the same company)? If so, Integrated Windows Authentication is your easiest solution.
I think its best idea to use a web browser control inside the desktop application .
Then use the WebBrowser1.Document most probably
WebBrowser1.Document.Cookie
get if the user is singed in.
I also need to make sure this URL that
is used cannot be simply copied and
used from another location, so I'll
need to include some sort of
information in the encrypted value to
know where it's coming from.
If you store the encrypted value in a cookie or as a field in a form (POST request), then the credential is no longer in the URL and so it can't be easily copied (note that I said "easily").
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