Single Sign On across multiple domains [closed]

Question

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.

Psychro

This sounds like a job for OpenID - but only allow IDs from your sign-in domain. – Janniejanos

@Will This question might not be for this website in the SE network, but is definitely constructive. – Impregnable

@BinarWeb Close reasons have evolved since 2008. Back then, this was the most applicable choice. – Moisesmoishe

Answer 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

Crocus

This looks like a good solution grom. What do you store in the databse? Is it (session_id, username, hashed_password)? – Polypody

How do you handle the case whare the master domain login.mydomain.com goes down? Is login impossible at that point? – Sequent

Any body produced any code examples or a github repo? – Guitar

This is what nearly all SSO protocols (e.g. SAML) specify, but with more security against replay attacks and so. – Flyn

What if they don't share user database? Each partner web app has its own user base. How do we encounter this? – Portis

@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. – Crocus

Those are on the same DOMAIN. How do I do it for different domains? – Sultana

Answer 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.

Bellinger

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 – Touchy

+1 You should [almost] never reinvent the security wheel. – Nitpicking

OpenSSO is dead and JOSSO and CAS are JAVA solutions. Just an FYI – Kuwait

Answer 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.

Deacon

Answer 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.

Interplay

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? – Erme