I have 2 servers with 2 web sites that look exactly the same but contain different forms.
They are linked together in the menu of the sites and the users have no idea that it is actually 2 different servers.
This strange situation is because my company has split all new development off from the old development (by giving me a new server), but still needs access to some of the old forms.
Both use the same LDAP lookup to log in through AD.
the problem is, users must sign into both individually. so they log into one, then immediately log into the second. as you can guess, this is a huge complaint.
I would like to know how to make it so no matter which server they log into, the other will allow them to access its forms.
Both sites are .NET, both servers are using IIS.
Thank you.
To complete this question for anyone else looking, here is how I solved this issue;
I added DNS reverse lookup urls that made them look like they had the same domain, changed all the linking urls to the new ones and used the auth cookie for that domain.
I also had to turn off IIS encryption and authentications as the two servers did not share this. The cookie does not send plain text so I assume there is still AD encryption.
Related
I have a single solution with multiple C# ASP.NET Web Forms projects. I want a way to identify a given browser so that each website can identifier that same browser. I need to do this from the C# Code-Behind code (not with the client code, like JavaScript). I also cannot use the Session because it isn't shared across websites. I don't think cookies are either.
For example, if a user logs onto Website1 and then logs onto Website2 with the same browser on the same computer, I want to be able to identify that. But if a user logs onto Website1 with Chrome and then Website1 with FireFox (regardless of whether it's on the same computer or not), I want to detect that as well.
If it makes any difference, I am using Azure to publish my web projects. So all websites will have similar domains (eg website1.azurewebsites.net and website2.azurewebsites.net).
If you want to track someone using the same browser on the same computer then use a cookie. If the websites have different domains you'll need to be clever because modern browsers have a lot of protection against what they see as tracking cookies. One option is using a hidden interstitial page as described here.
Your second scenario, a user accessing same site with different browsers, I suggest storing the user agent string (one of the request headers) and adding this to a login audit so you can build up a collection of different user agents used by a given user. There are libraries available for parsing user agent strings and extracting name, version, engine etc.
Between these two techniques and a bit of business logic you should get what you need. If you would like me to clarify any of this, let me know and I'll provide more detail.
We have two servers that run on the same machine under the same domain.
Both written in ASP.NET and uses the Identity framework.
I need to implement Single Sign-On (and single sign out) between them.
Actual sign-in is done in AJAX (I POST the username and password, the server authenticate the user and sets the session, then sends the redirect data URL to the client).
I found overwhelming amount of information about OWIN, the Identity framework, Claims, etc.
I found tutorials explaining how to create projects using just about any modal dialog and any Wizard there is in Visual Studio, which I tried to understand but really is useless to me, as I already have authentication system up and running.
I even found some demos claiming to implement SSO in all kinds of ways, and some Stackoverflow questions that said to simply put this and that values in the web.config and you're done, which seemed strange to me and I figured out I'm missing some basic understanding of how it works.
Still, I can't understand how SSO works in ASP.NET Identity.
Can someone please explain it to me in a simple manner, or refer me to some kind of such explanation?
Again: I have two authentication systems up and running. What code and/or configuration changes I need to make to get Single Sign-On working?
First, if you want them to share authentication, they need to be working on the same user store. In other words, you should factor out the Identity initialization code (ApplicationUser, ApplicationDbContext, ApplicationUserManager, and ApplicationSignInManager) into a class library that both applications share. Trying to mantain and share two separate databases with user data is going to be an impossible and insurmountable task.
Then, you need only ensure that both applications utilize the same machine key. The auth cookie is encrypted, and since the encryption is based on the machine key, both applications need to use the same key to encrypt/decrypt that cookie.
Since you've already stated that they will both be hosted on the same domain, that's all there is to it.
I am Working in asp.net and C# .
I have an application where user logs in to enter the application,if a user opens the application in a browser and logs in,and if user opens the application in some other browser in the same system they should be logged in as well.The same should happen within the same browser in different tabs and also in the different instance of same browser in which user was Previously logged in.please give me Your suggesions.....
You can't share session between multiple browsers.
But session between multiple tabs of a same browser instance is already shared.
The answer is, as stated above, that you can't share Sessions between 2 different browsers as each browser will necessarily start a new session.
If you want a way to allow the user to log in once and stay signed in even if he opens a different browser, then you would have to rely on his IP address since this is the ONLY indicator that the user that logged in Chrome 2 secs ago, may be the same user that's logging in from Firefox now. This is just to give you an example but this is obviously flawed because different users behind the same gateway will all have the same IP.
What you want to do would work only if the application you develop is inside an Intranet and you know for sure that every user will have a unique internal IP address but then the whole point of authenticating users may be achieved through more efficient ways, like Integrated Windows Auth, etc.
You can share session between two browsers ,we have implemented such a project couple of years back .
The technique used was to write a custom browser which instead of storing cookies in local machine stored it in a in a public server
so that when one guy logs in the cookie & other local data associated with the session is shared with the server and thus with all browser instances ,browsers instances cookie is modified to match with the server details ,So it behaves as if the session is shared .
some websites have issue with using different ip that could be solved by using a common proxy server .
but if you can't use custom browsers then it will be difficult but could still try with plugins that follow the above mentioned method
Hope this helps
Our operator has implemented a Round Robin load balancer on our web portal and it seems to be causing some problems I can't get to the bottom of.
I'm able to identify which server we're on and as we navigate around the site we stay on server A. If I leave it for 5 minutes and try another page I'll get pushed to server B, logged out and shown the log in page.
I've got them to make sure the MachineKey in the machine.config is the same on both servers and I've tested locally that the session isn't being used - I can turn the session off completely locally and it still works. I've verified on both servers it is creating an ASPXAUTH cookie on the domain so we should be classed as authenticated on both servers - but keep loosing my authentication every time I change server.
Any ideas on what could be causing the logging out? I'm guessing it's my misunderstanding about how ASPXAUTH works.
Sessions are handled separately from Forms Authentication. There is a good explanation of this here.
The most common reason for Forms Authentication failures on load-balanced environments is lack of synchronization of the MachineKey element. You've stated that you've got the server operators to ensure that the MachineKey is synchronized, but have you verified this yourself in some way? Is this the case on ALL the web servers? From previous dealings with a couple of commercial web hosts, I've found that it is (unfortunately) difficult to take their assurances at face value.
Another thing to check is if the FormsAuthentication configuration (timeout, path, name, etc.) is the same on all of the hosts.
Are the patch levels the same on all of the hosts? You might want to see if the compatibility switch mentioned here is applicable in your situation.
Assuming that the hosting setup is correct, maybe you have initialization code on the page that logs you out if some condition is not fulfilled?
Try to take a look at the server logs and trace the sequence of HTTP requests involved during a failed page request. That might produce a clue.
Edit: This guide to troubleshooting Forms Authentication problems is detailed, and quite helpful: Troubleshooting Forms Authentication
Check for any other application functionality which depends on cookies. The web server on Server B will not recognize cookies that came from Server A. If any part of your authentication depends on cookies being populated, then that could cause your problem.
You have probably already ensured that the domain used for cookies is the same on all of the load balanced servers, but I thought I'd mention that. If the domains aren't compatible, then the browser will simply not send cookies to the server.
My website can be access from many domain (a my own blog engine). So, how i can cross authentication?
I'm using: IIS7, C#, asp.net membership, form authentication.
If you are using Active Directory (assuming that is what you refer to as domains), you can simply configure multiple ActiveDirectoryMembershipProvider sections and use the asp:Login control templates, add a dropdown for the domains you want to authenticate against, and on the OnAuthenticate event of the Login control, set the selected AD membership provider.
For different providers like SQL Server membership provider, I'm not sure I understand what the issue is. Can you elaborate?
I'm going to take a guess here after having tried to read your question a couple of times again. If with 'multiple domains' you mean you have multiple websites (multiple fully qualified domain names), and you want to use the same SQL Server datastore to authenticate users against, and run the same website, the solution would be to point the appropriate DNS A record to the IP address of the original hosting server.
Any decent domain registrar should allow you to change the DNS record.
However, Forms Auth creates a cookie, and you will not be able to read the cookie from a different domain than that you are on because of obvious security issues, so in that case you're stuck.
The only possibility I can see is that you're passing some encrypted identity in a querystring, but that is very, very dodgy, as you would want to make sure there's a minimal validity time limit on it as it opens up a right can of worms (security holes). Probably not recommended.
Crikey, that's a long way of saying "No, you can't - securely."
If are talking about sub domains and not about different top level domains, then you can actually do it, see this post.