[keycloak-dev] Automatically login user to application when logged into realm

[Bill Burke]

On 10/23/2013 12:50 PM, Stian Thorgersen wrote:
> I don't see how that would work. The server-side adapter doesn't set a cookie until after the user has logged in (the cookie is also specific to the application). The only thing that knows if a user is logged in to the SSO realm is Keycloak itself. At the moment there's no way for an application (client or server side) to check this without ending up showing the login form if it isn't!
>

You don't need to know if you are logged into the auth-server.  You just 
need to know if you are logged into the application.

> What you want to be able to do is to have users automatically logged in to applications (on different servers, with different application credentials) once a user has logged in to a single application.
>
> Either I've failed to explain the use-case properly, or there's something about what you're proposing I'm not understanding. Just to make sure I'm explaining the use-case properly, I'll try again:
>
> A company has an internal Keycloak server, they have a single realm with multiple internal applications. All applications are hosted on different servers. Let's imagine this company is called Red Hat. The user, let's call him Stian, first goes to the OrangeHRM to book some long overdue holiday. He's not currently logged in to the realm so is is shown an anonymous access screen instead with a login link. Stian presses login, fills in username and password and successfully logs in to the realm. Now Stian wants to go to docspace, again Stian has to press the Login link, but doesn't have to provide a username or password, but instead is simply redirected back to the application as a logged in user. Stian is actually a bit confused about this as he just logged in to an application without providing a username or password.
>

The demo currently works like this:

1. User access app1
2. User redirected to auth-server
3. Auth-server logs in sets cookie for auth-server.com
4. auth-server redirects back to app1
5. App1 gets access token
6. App1 does role mappings stores in HttpSession
7. App1 knows user is logged in because of HttpSession (standard Servlet 
stuff)
8. User visits app2
9. App2 redirects to auth-server
10. auth-server sees auth-server.com domain login cookie, redirects back 
to app2
11. user can access app2 right away without credentials.
12. user goes back to app1.  User is still logged in there because the 
HttpSession is still valid

Now add your HTML5 app.  HTML5 will also need to maintain a "session". 
I can do this via a session cookie for HTML5's domain

12. User visits HTML5, HTML5 looks for a session loggin cookie for 
HTML5's domain.  Doesn't find one, so it automatically redirects to 
auth-server
13. Auth-server sees user is already logged in, redirects back to HTML5 app
14. HTML5 app gets access token, sets a session loggin cookie
15. User goes back to App2.  App2 knows user is logged in because of 
App2 session cookie.
16. user goes back to HTML5.  HTML5 app knows user is logged in because 
of session cookie
15. HTML 5 app wants to logout and login as a different user
16. Logout action dumps the HTML5-domain session cookie
17. Logout action sends CORS HTTP request to auth-server to logout user 
cross-domain.  Auth-server invalidates auth-server session cookie on 
response.

HTML5 clients are allowed to set cookies.

The HTML5 app would work exactly the same as servlet security except the 
browser would handle all the authentication within javascript.  There's 
improvements we need to make with refresh tokens, but the core of the 
protocol is there.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com