views:

1960

answers:

8

Lets say that you have websites www.xyz.com and www.abc.com.

Lets say that a user goes to www.abc.com and they get authenticated through the normal ASP .NET membership provider.

Then, from that site, they get sent to (redirection, linked, whatever works) site www.xyz.com, and the intent of site www.abc.com was to pass that user to the other site as the status of isAuthenticated, so that the site www.xyz.com does not ask for the credentials of said user again.

What would be needed for this to work? I have some constraints on this though, the user databases are completely separate, it is not internal to an organization, in all regards, it is like passing from stackoverflow.com to google as authenticated, it is that separate in nature. A link to a relevant article will suffice.

A: 

Not sure what you'd use for .NET but ordinarily I'd use memcached in a LAMP stack.

Marc Gear
A: 

The resolution depends on the type of application and environment in which it is running. E.g. on intranet with NT Domain you can use NTLM to pass windows credentials directly to servers in intranet perimeter without any need to duplicate sessions.

The approach how to do this is generally named single sign-on (see Wikipedia).

Matej
+1  A: 

If you store user sessions in the database, you could simply check the existance of the Guid in the session table, if it exists, then the user already authenticated on the other domain. For this to work, you would have to included the session guid in the URL when you redirect the user over to the other website.

public static
A: 

If you are using the built in membership system you can do cross sub-domain authentication with forms auth by using some like this in each web.config.

<authentication mode="Forms">
    <forms name=".ASPXAUTH" loginUrl="~/Login.aspx" path="/" 
                  protection="All" 
                  domain="datasharp.co.uk" 
                  enableCrossAppRedirects="true" />

</authentication>

Make sure that name, path, protection and domain are the same in all web.configs. If the sites are on different machines you will also need to ensure that the machineKey and validation and encryption keys are the same.

Adam Pope
A: 

There are multiple approaches to this problem, which is described as "Cross-domain Single Sign On". The wikipedia article pointed to by Matej is particularly helpful if you're looking for an open source solution - however - in a windows environment I belive you're best off with one of 2 approaches:

  1. Buy a commercial SSO product (like SiteMinder or PingIdentity)
  2. Use MicroSoft's cross-domain SSO solution, called ADFS - Active Direcctory Federation Services. (federation is the term for coordinating the behavior of multiple domains)

I have used SiteMinder and it works well, but it's expensive. If you're in an all MicroSoft environment I think ADFS is your best bet. Start with this ADFS whitepaper.

Markc
A: 

Alternatively if you want to roll your own and the sites in question are not on the same servers or don't have access to a shared database (in which case see the above responses) then you could place a web beacon on each of the sites which would refer back to the other site.

Place a single pixel image (web beacon) on site A which would call site B passing through the users ID (encrypted & time stamped). This would then create a new user session on site B for the user which would be set as logged in. Then when the user visited site B they would already be logged in.

To minimise calls you could only place the web beacon on the home page and or log in confirmation pages. I've used this successfully in the past to pass information between partner sites.

Toby Mills
This sounds infinitely hackable.
Lucas Oman
+2  A: 

I had this issue last night with an application I was working on. I'm using FormAuthentication and set the web.config authentication section like so:

<authentication mode="Forms">
  <forms name=".ASPXAUTH" requireSSL="true" 
      protection="All" 
      enableCrossAppRedirects="true" />
</authentication>

I got the machine key and encryption key from this generator.

When posting to the other application I passed the authentication ticket as hidden field. While read the post from the first app, the second app will read the encrypted ticket and authenticate the user. Here's an example of the page that passes that posts the field:

.aspx:

<form id="form1" runat="server">
  <div>
    <p><asp:Button ID="btnTransfer" runat="server" Text="Go" PostBackUrl="http://otherapp/" /></p>
    <input id="hdnStreetCred" runat="server" type="hidden" />
  </div>
</form>

code-behind:

protected void Page_Load(object sender, EventArgs e)
{
    FormsIdentity cIdentity = Page.User.Identity as FormsIdentity;
    if (cIdentity != null)
    {
        this.hdnStreetCred.ID = FormsAuthentication.FormsCookieName;
        this.hdnStreetCred.Value = FormsAuthentication.Encrypt(((FormsIdentity)User.Identity).Ticket);
    }
}

I was inspired by the cross app form authentication section in Chapter 5 of this book from Wrox. It recommends answers like the ones above in addition to providing a homebrew SSO solution. If you've got 4.99, you can get just the chapter on-demand.

Hope that helps...

craigmoliver
A: 

I would user something like CAS:

[1]: http://www.ja-sig.org/products/cas/ CAS

This is a solved problem and wouldn't recommend rolling your own.