Single Sign On across multiple domains

92,510

Solution 1

The SSO solution that I've implemented here works as follows:

  1. There is a master domain, login.mydomain.example with the script master_login.php that manages the logins.
  2. Each client domain has the script client_login.php
  3. All the domains have a shared user session database.
  4. When the client domain requires the user to be logged in, it redirects to the master domain (login.mydomain.example/master_login.php). If the user has not signed in to the master it requests authentication from the user (ie. display login page). After the user is authenticated it creates a session in a database. If the user is already authenticated it looks up their session id in the database.
  5. The master domain returns to the client domain (client.mydomain.example/client_login.php) passing the session id.
  6. The client domain creates a cookie storing the session id from the master. The client can find out the logged in user by querying the shared database using the session id.

Notes:

  • The session id is a unique global identifier generated with algorithm from RFC 4122
  • The master_login.php will only redirect to domains in its whitelist
  • The master and clients can be in different top level domains. Eg. client1.abc.example, client2.xyz.example, login.mydomain.example

Solution 2

Don't re-invent the wheel. There are a number of open source cross-domain SSO packages such as JOSSO, OpenSSO, CAS, Shibboleth and others. If you're using Microsoft Technology throughout (IIS, AD), you can use microsoft federation (ADFS) instead.

Solution 3

How different are the host names?

These hosts can share cookies:

  • mail.xyz.example
  • www.xyz.example
  • logon.xyz.example

But these cannot:

  • abc.example
  • xyz.example
  • www.tre.example

In the former case you can bang out a cookie-based solution. Think GUID and a database session table.

Solution 4

If you use Active Directory you could have each app use AD for authentication, login could then be seamless.

Otherwise, if the applications can talk to each other behind the scenes, you could use sessionids and have one app handling id generation serving all of your other applications.

Share:
92,510

Related videos on Youtube

Pascal
Author by

Pascal

Technology enthusiast Programmer (Multiple languages) Geek

Updated on July 08, 2022

Comments

  • Pascal
    Pascal almost 2 years

    Our company has multiple domains set up with one website hosted on each of the domains. At this time, each domain has its own authentication which is done via cookies.

    When someone logged on to one domain needs to access anything from the other, the user needs to log in again using different credentials on the other website, located on the other domain.

    I was thinking of moving towards single sign on (SSO), so that this hassle can be eliminated. I would appreciate any ideas on how this could be achieved, as I do not have any experience in this regard.

    Thanks.

    Edit: The websites are mix of internet (external) and intranet (internal-used within the company) sites.

    • Neall
      Neall almost 16 years
      This sounds like a job for OpenID - but only allow IDs from your sign-in domain.
    • Binar Web
      Binar Web about 6 years
      @Will This question might not be for this website in the SE network, but is definitely constructive.
    • Admin
      Admin about 6 years
      @BinarWeb Close reasons have evolved since 2008. Back then, this was the most applicable choice.
  • Jon M
    Jon M over 14 years
    This looks like a good solution grom. What do you store in the databse? Is it (session_id, username, hashed_password)?
  • jjxtra
    jjxtra over 13 years
    How do you handle the case whare the master domain login.mydomain.com goes down? Is login impossible at that point?
  • Admin
    Admin about 12 years
    Absolutely - I've have seen too many people roll their own security solutions only to discover that they are vulnerable to replay, XSRF or other attacks
  • Wowbagger and his liquid lunch
    Wowbagger and his liquid lunch about 12 years
    +1 You should [almost] never reinvent the security wheel.
  • Joshua F. Rountree
    Joshua F. Rountree about 12 years
    Any body produced any code examples or a github repo?
  • cweiske
    cweiske about 12 years
    This is what nearly all SSO protocols (e.g. SAML) specify, but with more security against replay attacks and so.
  • stuckedoverflow
    stuckedoverflow over 9 years
    What if they don't share user database? Each partner web app has its own user base. How do we encounter this?
  • grom
    grom over 9 years
    @Halim it doesn't have to be a shared user database, but the client domains will have to have some way of querying user session information. There are other solutions too, this comment is just presenting a solution where logins are routed through a central login server.
  • HaBo
    HaBo about 9 years
    isn't user still have to enter username and password on domain1.com and domain2.com and domain3.com when he lands on those sites first time for this session?
  • OneHoopyFrood
    OneHoopyFrood about 9 years
    OpenSSO is dead and JOSSO and CAS are JAVA solutions. Just an FYI
  • csharpforevermore
    csharpforevermore over 2 years
    Those are on the same DOMAIN. How do I do it for different domains?