How to do redirect-less SSO across subdomains?

Securing applications
1

I want to implement redirect-less SSO (by reusing the session cookies or some other way) across two applications in different subdomains of the same domain.

The way I am currently doing this in my legacy IDP is by setting a session cookie in .domain.com and the two apps would sit at app1.domain.com and app2.domain.com. They check with the idp (custom) whether the session is valid etc.

How can I implement this or another type of redirection-less SSO in Keycloak?
For technical reasons the http client accessing app1 and app2 cannot get redirected to the IDP, but supports cookies.

2

IMHO there is no OIDC or SAML native flow, which will cover this requirement. You may use some (or extend Keycloak code to fit your needs), but there will be many “buts”, e.g. but you will have to hack app code for this use case, but you will have to still manage legacy code, …

1 Like
3

Hello @jangaraj .

Thanks for the response.

Can you suggest a general idea of how something like this could be built?
If OIDC or SAML wouldn’t cut it, how can I instead set keycloak’s session cookie at .domain.com so that I can reuse it?

Or if I had to write my own keycloak extension, how would I be able to set/remove a cookie on login/logout? Any general guidelines?

Thanks,

4

One from many bad/good designs:

“IDP” app3 will be sitting on domain.com - it will use direct access grant flow (yes, less secure, but you have to sacrificy security, because obscure “redirect-less” requirement) and it will set cookie at .domain.com - e.g. id/access token (now it is a good time to google discussions why token shouldn’t be saved in the cookie). app1/app2 will use cookie and they validates tokens - but what will happens if they detect invalid/expired token (remember you can’t redirect to “IDP” app3) - you can use refresh token - but where you save it? In the cookie. But refresh token is equivalent of user password = so you have to encrypt it. But app1/2 need to decrypt it, so you have to use symmetric encryption. So which symetric encryption should be used? And so on. You will have to very carefull to design it properly and it still be legacy. You will benefit if you can use standards.

5

So Keycloak is not capable of setting a session cookie at .domain.com instead of keycloak.domain.com?

That’s a shame. Using a third custom app is undesirable and would break the standard login/recover etc flow which is not what I want, thus keycloak becomes a lot less useful. I just want the capability of reusing the login flow that already happened by trusting all subdomains implicitly (which is a standard cookie capability employed by google and many others).

Sounds like I might need to investigate an alternative.

6

I

I didn’t say that. Keycloak is based on the SSO standard OIDC/SAML. And those standards really don’t use cross domain cookie as I know, so I would say you have wrong expectations from the Keycloak.

1 Like
7

Hi @Fidelix, did you solve this? I’m trying to do pretty much the same.

8

Unfortunately I was not able to solve it.

@jangaraj mentioned that keycloak is based on OIDC/SAML, but there is nothing stopping keycloak from adding this optional functionality. It’s just not there, and you’d need to change things in the core to implement that.

So as he said, if this is an absolute must for you, look elsewhere (some of the competition does have solutions for this use case).

9

Thank you for the reply! Could you point me to the competition you’re talking about?