There seems to be plenty of examples of how to migrate from 3.5 to 4.5 but I'm struggling with a particular scenario.
I have several existing asp.net sites that are using WIF 3.5 to implement federated identity with an adfs 2.0 server.
Single sign in, and passive single sign out (wscleanup1.0) is all working fine.
No we are developing a new asp.net site and seeing as it's a new project we thought we should use WIF 4.5.
Single sign in is still working fine across all these apps. It doesn't matter which one you sign into first all of the others recognise the token and can read the claims.
We are, however, seeing an issue with single sign out.
If I initiate the signout from the site using WIF 4.5 everything works as expected. You're signed out of every app you have used during that session.
If, however, I initiate the signout from one of the sites using WIF 3.5 all of the sites using WIF 3.5 sign out as expected but the site using WIF 4.5 remains logged in.
Is this something that should be possible or are there incompatibilities between the versions which means it will never work?
I read here that the format of the cookie had changed but that's a year old now so I was looking for a more current answer.
Unable to decrypt claims cookie from .NET 4.5 to .NET 3.5
Related
I oddly do not find any documentation around how to setup ASP.NET CORE with ADFS 3.0, but enough about other providers. How can I set this up in ASP.NET CORE, as my company only uses ADFS 3.0 as SSO solution.
I've seen a (paid) solution called Auth0, but I first want to try without any 3rd party paid options.
I understand ADFS 3.0 has removed the need for IIS and that it's run directly out of HTTP.SYS now.
So does this mean it's not even possible to add IIS back so one could implement a custom FormsAuth (web forms) type integration as you used to be able to do under ADFS 2.0?
Or is it all Shibboleth these days?
Edit: We've been able to successfully deploy our own custom authentication provider in ADFS 3.0 (adjacent to Active Directory) and use it to SSO into Office 365 so this is no longer required. See Implementing Office 365 single sign-on using custom authentication/claims provider in ADFS 3.0 (RE: AADSTS90019)
You can as long as the SSL bindings and routing for anything under /adfs, /federationmetadata remains the same. We've seen cases where this has not happened and resulted in the most painful of troubleshooting.
Thanks //Sam
If you mean can you install IIS on Server 2012 R2 to run apps., yes you can.
If you mean can you customise ADFS aspx pages as you used to be able to do, the answer is no but you can do some stuff with Javascript.
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.
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" />
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.