Let me describe my setup a little before I get into the problem. I have two web servers (www.mydomain.com and www2.mydomain.com) using Forms Authentication. On each web server I have a main application for authentication and numerous sub-apps. It looks kind of like this:
www.mydomain.com
|__MainApp (.Net 2.0)
|__SubApp1 (.Net 1.1)
|__SubApp2 (.Net 2.0)
|__SubApp3 (.Net 2.0)
www2.mydomain.com
|__MainApp (.Net 2.0)
|__SubApp1 (.Net 1.1)
|__SubApp2 (.Net 2.0)
|__SubApp3 (.Net 2.0)
As you can see, I'm running a mix of .Net 1.1 and 2.0 applications on the same server. Now I've been trying to come up with a Single Sign- On (SSO) solution that works with this setup and I've partially succeeded. Because the domain attribute in the tag is incompatible with .Net 1.1 (it causes the apps to throw an exception), I decided to programmatically set the domain of the forms authentication cookie generated. This works fine and I can navigate between the two servers without having to login again. The problem occurs when the server tries to reissue/renew the cookie and update its expiration with slidingExpiration enabled. The cookie I generate gets created with "mydomain.com" as the domain, but when the server tries to reissue it with a new expiration, it can't find it and generates a brand new cookie with "www.mydomain.com" as the domain.
Is there anyway to have the server properly reissue the original cookie with the custom domain?
We have an almost identical setup (two web servers, a mix of 1.1, 2.0 and 3.5 app's) and SSO using forms authentication. And we've got it working with sliding expiration with no problem.
The one difference is that our two web servers are setup as a web farm (using the MS Clustering in Server 2k3 if I remember correctly). This means that both machines are assigned to the same domain. Can you switch your two servers to be a web farm?
If we were to go that route, it would be more of a long-term solution. In the short term, I was just hoping to see if anyone knew why the framework is unable to find and reissue the existing cookie.
My solution was to add the Forms Authentication domain attribute to the global Web.config for the .Net 2.0 framework (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\Web.config). It doesn't fix the issue for my .Net 1.1 apps, but the majority of my apps are on 2.0. I'll probably just use an HTTPModule to handle the sliding expiration for the .Net 1.1 apps.
Related
I am working on a .NET 6 ASP.NET website and looking at implementing authentication using the identity framework. I understand this is technically working as a middleware and is independent of the subsequent IIS deployment authentication setting (only anonymous needs enabling).
On the IIS authentication setting I can various authentication options, one of which is called Forms Authentication.
I want to ask whether there is any relation between .NET Web Forms (or Windows Forms) project and the IIS Forms authentication? Or is it just a co-incidence that they both have the Forms keyword? I am confused because - like Web Forms project, even older ASP.NET MVC project required the Form Authentication enabled upon deployment to IIS. Where as newer .NET MVC project don't require this IIS deployment setting if they are using the Identity framework.
The latest authentication mechanism is called Identity framework. What was the older authentication mechanism technically called? Forms auth framework?
want to ask whether there is any relation between .NET Web Forms (or Windows Forms) project and the IIS Forms authentication?
Don't bring windows forms into this!!
But, yes, so called FBA (forms based aunthetiicaion) is not really realited to web forms in any speical way. They just happen to both have the name "forms" in their name - nothing more, and nothing less. So, using FBA in web forms applciations was a long time common choice.
Is there a relationship bettween FBA and IIS? yes, because if you adopt FBA, then your web site security is managed using that security provider. This useally means you have the "role" provider and FBA provider.
so, then each folder of the web site can then be secuired using web.config. You can either secuire those pages to require a valid logon (based on FBA), and you can also pick and choose what roles (so, some parts of the site say can only be used with say a role of "Sales" group.
However, while the web forms site can adopt FBA, the valuable informtion is that IIS will respect that that authneticaion provider - and thus IIS "knows" and "respects" that secuirty provider choice. That means say if you hit a web page that requires logon, then IIS will automatic intercept that page - send you to the logon page, and after you logon, you can continue on to that secured web page.
However, you don't have to use FBA with IIS, there are of course other secuirty and logon providers you can use. However, you do want to use a supported and started one, since then you can use the built-in asp.net logon controls etc, and they will just work.
What was the older authentication mechanism technically called?
FBA -- Forms based authentication. As I stated, the fact of "forms" in that name FBA has no specials meaning in regards to web forms, or using web form applications.
You are thus as noted are free to adopt newer security providers - web forms are of course not limited to using FBA as the security provider.
even older ASP.NET MVC project required the Form Authentication enabled upon deployment to IIS.
Hum, did they? I don't think that is the case. If you don't want or need web site logons or security then I do not believe that FBA was any kind of requirement to be enabled at all to deploy a web site that does not have nor use security.
First off, I'm completely new to Shibboleth and SAML. We have a ..net web application which uses the .net membership provider functionality for forms authentication. We need to keep the .net mode of authenticating. However, we've now been asked to add the ability to authenticate a user coming from another web application which uses Shibboleth.
My question is, and I apologize if it sounds stupid, but can a .net web application implement both the 'default' asp membership and shibboleth authentication, or does it have to be one or the other?
Our web app is a .net 4.5 written in vb.net and hosted on Windows server. The other is a web app written in PHP (if I'm not mistaken) uses Shibboleth and is on a Linux server.
Thanks!
I have an older ASP.NET (.NET 1.0) web application that is using Windows authentication. We want to remove the Windows authentication since the AD server for this particular web application needs to be decommission. We want to keep some type of authentication for this older web-application. I am thinking this leaves us with Forms and Passport authentication modes (but not sure of support in a .NET 1.0). I am trying to avoid a major rewrite since the web-application is not being used much anymore (only being used by one user). Any idea of a quick and simple solution to remove Windows authentication to something else for authentication?
If the domain controller is to be decommissioned I take it the entire office will reverted back to a domain-less workgroup environment. I also take it all workstations will be configured to leave the domain prior to destroying the domain controller once and for all.
Since it's only down to one user for a web application that has little value in enhancement, you may be able to get away by creating the very same user account with the same password on the web server. That way when s/he accesses the web app on that server, the Windows authentication mechanism will attempt to negotiate as SERVER\username in the local SAM store instead of relying on the previous DOMAIN\username account.
I'm currently underway in migrating a collection of ASP.Net web forms projects to ASP.Net MVC 5. The web forms projects are all hosted on the same machine and share forms authentication (You log into one, you're logged into them all). The old apps use Page.User.Identity. As a first step I'm migrating just one site to MVC 5 using UserManager/IAuthenticationManager with cookies. As expected, this new authentication system does not work with the other apps in our environment. The MVC5 project has the same machineKey configuration as the other projects and I've tried adding a call to FormsAuthentication.SetAuthCookie but it does not work. How can I setup authentication to work across both types of environments using the newer authentication scheme but with minimal changes to the old projects to make this work?
I'm not 100% sure because this project ended up going a very different direction, but we encountered similar problems with web forms cookies. The solution was to set the compatibilityMode property on the machine key to "Framework45". This all systems configured this way to see the same cookie and behave as intended. I would be willing to bet that this would have solved my original problem.
We have two server running .NET 4.5.1 and one running .NET 4.0. Before updating the first two, our SSO for forms authentication worked fine. Now, a user will appear authenticated on those first two servers, but not authenticated on the .NET 4.0 box.
All machine keys, decryption keys, cookie domains, etc, are all the same. No code was modified. We simply applied the 4.5.1 update to those two servers.
I've noticed for the 4.0 server, while our authentication cookie IS being passed up, it's not being recognized by the code (I threw a test page on the site and outputted some variables).
Has machine key encryption changed between 4.0 and 4.5.1? Do I need to apply some patch? Thanks.
The encryption APIs have changed in 4.5 see this blog post for more detail - http://blogs.msdn.com/b/webdev/archive/2012/10/23/cryptographic-improvements-in-asp-net-4-5-pt-2.aspx
According to MS simply upgrading to 4.5 wouldn't affect the apps unless the web.configs have changed to target 4.5 which seems odd in your case. You can try adding this attribute to each web.config to force .NET 2.0 compatibility-
<machineKey compatibilityMode="Framework20SP1" />