Single Sign On across multiple domains
Solution 1
The SSO solution that I've implemented here works as follows:
- There is a master domain,
login.mydomain.example
with the scriptmaster_login.php
that manages the logins. - Each client domain has the script
client_login.php
- All the domains have a shared user session database.
- 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. - The master domain returns to the client domain (
client.mydomain.example/client_login.php
) passing the session id. - 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.
Related videos on Youtube
Pascal
Technology enthusiast Programmer (Multiple languages) Geek
Updated on July 08, 2022Comments
-
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 almost 16 yearsThis sounds like a job for OpenID - but only allow IDs from your sign-in domain.
-
Binar Web about 6 years@Will This question might not be for this website in the SE network, but is definitely constructive.
-
Admin about 6 years@BinarWeb Close reasons have evolved since 2008. Back then, this was the most applicable choice.
-
-
Jon M over 14 yearsThis looks like a good solution grom. What do you store in the databse? Is it (session_id, username, hashed_password)?
-
jjxtra over 13 yearsHow do you handle the case whare the master domain login.mydomain.com goes down? Is login impossible at that point?
-
Admin about 12 yearsAbsolutely - 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 about 12 years+1 You should [almost] never reinvent the security wheel.
-
Joshua F. Rountree about 12 yearsAny body produced any code examples or a github repo?
-
cweiske about 12 yearsThis is what nearly all SSO protocols (e.g. SAML) specify, but with more security against replay attacks and so.
-
stuckedoverflow over 9 yearsWhat if they don't share user database? Each partner web app has its own user base. How do we encounter this?
-
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 about 9 yearsisn'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 about 9 yearsOpenSSO is dead and JOSSO and CAS are JAVA solutions. Just an FYI
-
csharpforevermore over 2 yearsThose are on the same DOMAIN. How do I do it for different domains?