Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Single Sign On [SSO] across different domains using Java

Tags:

We are implementing Single Sign On [SSO] across multiple applications, which are hosted on different domains and different servers.

enter image description here

Now as shown in the picture, We are introducing a Authenticate Server which actually interacts with LDAP and authenticate the users. The applications, which will be used/talk to Authenticate Server are hosted across different Servers and domains.

for SSO, I can't use session variables, as there are different servers and different applications, different domains, a domain level cookie/session variable is not helpful.

I am looking a better solution which can be used for SSO across them. Any demonstrated implementation is existing? If so, please post it or point me in the right direction for this.

like image 281
RaceBase Avatar asked Aug 08 '13 08:08

RaceBase


People also ask

How SSO works with different domain?

About multi-domain support for SSO Users can access back-end applications through multiple domains or through multiple hosts within a single domain, eliminating additional credential requests when they go through those multiple domains.

What is SSO authentication in Java?

A single sign-on solution lets users authenticate themselves just once to access information on any of several systems. This is done using JAAS for authentication and authorization and Java GSS-API to establish a secure context for communication with a peer application.

What is cross domain authentication?

Cross-domain authentication is a common approach in identity management that authenticates users for sites that run on different domains. ReachFive handles this even for browsers that block third-party cookies. Cross-domain authentication is much more streamlined when using SSO.


1 Answers

You can achieve this by having all your log-ins happen on the auth server. The other applications can communicate to the auth server through a back channel. The general principle is like this:

  1. User accesses application 1.
  2. Application 1 needs the user to sign on, so it sends a token to the auth server through the back channel. Application 1 then redirects the user to the log in page on the auth server with the token as a parameter on the request.
  3. User logs in to auth server. Auth server sets a cookie, flags the token as authenticated and associates the user details with it. Auth server then redirects user back to application 1.
  4. Application 1 gets request from user and calls auth server over back channel to check if the token is OK. Auth server response with user details.
  5. Application 1 now knows that the user is authorised and has some basic user details.

Now this is where the SSO bit comes in:

  1. User accesses application 2.
  2. Application 2 needs the user to sign on, so it sends a token to the auth server through the back channel. Application 2 then redirects the user to the login page on the auth server with the token as a parameter on the request.
  3. Auth server sees that there is a valid log in cookie, so it can tell that the user is already authenticated, and knows who they are. Auth server flags the token as authenticated and associates the user details with it. Auth server then redirects user back to application 2.
  4. Application 2 gets request from user and calls auth server over back channel to check if the token is OK. Auth server response with user details.
  5. Application 2 now knows that the user is authorised and has some basic user details.

There are some existing implementations of this method, for example CAS (Central Authentication Service). Note that CAS is supported out of the box in Spring Security. I would advise you look at using an existing implementation, as writing your own will be hard. I have simplified things in my answer and there is a lot of potential for introducing security holes if you're new to this.

like image 131
Qwerky Avatar answered Nov 26 '22 09:11

Qwerky