Asp.net MVC Authentication issue - asp.net

I created two different asp.net MVC application using the default template, and launches the two simultaneously, when I login with site a, and refresh site b, site b tries to use the login detail of site a. How do I stop it?

I suspect you are having an issue with the AntiForgery tokens. Something I add by default to my new MVC projects is this (add to Global.asax) :
AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.NameIdentifier;
I think this SO answer provides a fairly complete overview

Authentication is persisted via cookies and cookies are domain-bound. All cookies tied to the domain will be sent to a request to that domain, regardless of how many actual websites there are in the mix. Although you haven't specified, you're most likely in development and loading the sites under different localhost ports. It's important to know that a different port is not enough to prevent cookies from being shared. In all cases, when developing locally, the domain will be localhost and cookies will be shared between all sites running on localhost.
You have a couple of options. The simplest option is to simply customize the auth cookie name for each site. If you're using ASP.NET Identity, just add the following property to your cookie auth config:
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
...
CookieName = "foo",
});
If the two sites use different auth cookies (based on the name), it won't matter if they both receive both; they'll only look at the one that belongs to them.
The second option is to use something other than localhost. For example, you can make use of something like localtest.me. It's a domain that has been helpfully set up to redirect all subdomains to localhost. That way you can test your sites via something like site1.localtest.me:12345 and site2.localtest.met:54321 (notice that the ports will be the same as they were with just localhost). However, since these are now different domains, the cookies will no longer be shared. However, doing this requires making changes to IIS Express' ApplicationHost.config file, and you could potentially mess something up if you're not careful. It also will be confined to your specific machine, so any other developers would need to make the same change on their machines. Changing the cookie name will be universally applied.

Related

Sharing Session state between web applications on seperate servers

Is it possible to share Session state between web applications on separate servers? One of the web sites is using session state to maintain user credentials/info session state, the other is using forms authentication to maintain this information. Without modifications to the website using session storage, is it possible for the website using forms auth to read/access the session state on the other server? If not, which I assume is the answer, would it be possible if they ran on the same server? (i.e. the same app pool)?
Note: Both applications are under the same domain name (one of them will be a sub-domain)
As a note, the reason this is being asked is because a client is requesting a "single sign-on" approach between two websites. We're using forms authentication and the other site (which we cannot modify at this moment) is maintaining credentials/logon information in session
ASP.NET 4
IIS 7.5
Assuming the latter, you could try something like this:
first, make sure all the appliations are running in the same domain. If not, all bets are off. I don't know if there's a simple way to configure the domain property of the session cookie yet, so you may have to do it yourself, by setting the cookie domain property to the domain:
Response.Cookies["ASP.NET_SessionId"].Domain = ".mydomain.com";
you'll need to make sure that each application is configured to use either a common state server, or a db-backed session.
please follow the link : How to share session state across subdomains

Creating a cookie using ASP.net

I have a sharepoint webpart where I have links to go to different web sites to which login is required. Therefore, I think i need to log the users on before redirect them into deep pages in that site, therefore I think i need to set up a cookie to that web site when the web part is loaded (by using the user credentials of the user's active directory information).
How can I achieve this requirement with out opening up a new browser window? (Though I have used a client side script, it pops up a new browser window)
Any help is highly appreciable...
Thanks
If you are referring to "different web sites" as sites having completely different URL's, then it's probably not possible without SSO system.
The reason is that it's impossible to read/write cookies from other domain in web environment, i.e. pre-login the users like you are saying.
If all the sites are inside same domain, like mycompany.com for example, and different sites are in abc.mycompany.com or mycompany.com/subsite, then yes, you can set the cookie. See top section here http://www.15seconds.com/issue/971108.htm
A simple way to implement SSO is by implementing method described later on in same article.
in the "Requesting Cookie from Another Domain". This is not a very secure method though, but can be done if you restrict it properly to specific slave domains. And obviously all the slave sites have to be modified, as with any SSO implementation.

ASP.NET multi-Tenant Application

I have an Asp.net application 3.5. I want to be able to allow multiple/ different clients to access the same application but using different URL's. I have already managed to configure the database to allow this.
So here's the main part.
I want to host my application in a domain say...
wwww.myapplication.com
then allow different client to access the same application using
1) www.clientOne.myapplication.com
2) www.clientTwo.myapplication.com
Also the client subdomains i.e(clientone.myapplication.com and clienttwo.myapplication.com)
should be autocreated by the client upon registration.
How can I achieve this..Your help will be greatly appreciated
A good example of how I want my application to work is
www.quickschools.com
I finally found out the solution that I wanted, so I thought I would share with you my finding. It turns out I needed to create a web application from another running Asp.net web application (From C# Code)
This tutorial by Robbe Morris was really helpful if you need to get started on this.
Another article you might want to check out is this one.
To have different url's using the same application, i would use "301 redirect" subdomains. I'm not really sure how to have a webapp create these subdomains.
I think the way to do this is to make the website the default website on the server i.e. configure so all requests to the servers IP hit this website (unless the header matches another website that explicitly looks for it). You do this just by not specifying a header on the IIS settings (only an IP address and a port number) - you can only do this for one site per IP address/port combination on the server.
Then look at the request url in the website to determine which domain was requested.
This way there is no need to 'create' subdomains... but you do need to reject all request to a domain that you don't want to recognize.
If you can't do this then you would need to adjust the IIS metabase from the application - not impossible - but a very risky and probably a bad idea.
The common case is that you'll have to configure a new virtual site for each of your new tenants during account provisioning. See Creating a New Virtual Server on how to achieve this programatically. Some though argue (with convincing arguments...) that spinning up an appdomain for each tenant is a waste of resources and one should use routing in the application that inspect the HOST header, see Multi-tenant ASP.NET MVC – Introduction.
Configuring IIS/ASP to respond to your tenant sub-dmains is the easy part. The real problem will be to configure DNS for your tenants, and that depends on your DNS solution.

ASP.NET Cross-Domain Cookies & Facebook Connect

I have a website which i integrate with Facebook (via FBML - JavaScript API).
I have setup the application on Facebook as per normal, specifying the "Connect URL" to be the domain of my website.
However, my application has multiple bindings in IIS for the same website.
Such as:
www.bar.com.au
foo.com.au
The domains are completely different, no relationship in the name whatsoever - so a regex-style rule is not possible (ie base domain). The domains were made different due to a combination of localization and marketing. Keep in mind these domains are baked in to an already live website, in other words i cannot change this architecture.
Is there a way i can specify BOTH of these domain's in the ONE Facebook Application settings for the "Connect URL"? Or will i have to create multiple applications?
Of course i cannot use the "Base Domain" setting as the bindings are not on the same sub-domain.
I actually have around 7 bindings in my website - so i'd rather not have to create 7 seperate Facebook applications - because this means maintaining 7 sets of API key/secret pairs in my application.
alt text http://www.freeimagehosting.net/uploads/268b234e2f.png
What's happening of course is when im on foobar.com.au, the Facebook cookies are not available to the domain.
For the meantime, i will try and create multiple ApiKey's - but i think i might run into issues. I'm going to have to go: "If domain is this, use this ApiKey", then the same logic in every single call to the Graph API. Messy stuff.
So i guess my problem/question isn't really caused by Facebook Connect, its the nature of HTTP Cookies by design.
How can i easily access these cookies cross domain? Will i need to setup a third website and direct all cookie logic to there?
If you want *.foobar.com.au to be allowed, then setup your Base Domain to foobar.com.au.
Could you set one of them up as your "Facebook Authentication" site, and direct all FB Auth-related traffic there, and then use one of a large number of cross-site communication tricks to send the token over to the original site?
In other words, regardless of the site they come in from, you'll use .foobar.com.au (for example) as the redirect URI. Then when they come in to that site with you having noted that they came from .foo.bar.com.au, you'll redirect them back where they came from passing along the access token in some cross-domain fashion (querystring, post vars, etc.)
In my current situation, timeframes have stopped me from doing the proper solution, which is what #Yuliy has highlighted.
For now, i have created multiple Facebook applications. But to keep it DRY, i have abstracted all that away behind exposed properties:
private static string _ApiToken_Site1, _ApiToken_Site2;
public static string ApiToken
{
get
{
if (Site1) return _ApiToken_Site1;
else if (Site2) return _ApiToken_Site2;
}
}
Not exactly clean, but the main thing is i did not have to touch my existing code at all, the smarts to work out which Api Key to use is in that property.
For our next project release, i'll be scrapping this and most likely implementing a WCF/ASMX web service which handles authentication from the one place (ie seperate web service on seperate domain).

Sharing ASP.NET authentication between sites

We are launching a new web site using a sub-domain and need to ensure that users logging in to the original (main domain) site, are also authenticated in the new site.
I believe I need to ensure all related web.config settings (forms authentication, cookie names etc) are the same in both applications and also manually set the machineKey validationKey/decryptionKeys (again, the same in both apps).
My question is, if I now manually set theses keys in my main app, will it break the existing logins?
We are using the "hashed" format for passwords.
Depends what you mean by "break". If you modify the machineKeys/encryptiong keys people might have to log back in but the login functionality will continue to work as before.
You also need to make sure that the domain for your cookie are set to domain.com in both places (without the www) or the authentication cookies will not be shard correctly between the sites.

Resources