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

Wed Oct 23 12:50:21 EDT 2013

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!

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.

Now imagine that docspace could figure out whether or not Stian was logged in to the realm already and simply automatically log Stian in. There's two options here in my opinion adding a isUserLogged in endpoint, the other is just piggybacking on the login mechanism we already have and simply add a do not show any forms option.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 22 October, 2013 7:37:21 PM
> Subject: Re: [keycloak-dev] Automatically login user to application when logged into realm
> 
> 
> 
> On 10/22/2013 12:46 PM, Stian Thorgersen wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 22 October, 2013 5:16:42 PM
> >> Subject: Re: [keycloak-dev] Automatically login user to application when
> >> logged into realm
> >>
> >> Ok, makes sense.
> >
> > I think this should be configurable and supported by all adaptors
> >
> >>
> >> Since this keycloak.js approach requires public client/application
> >> credentials we're going to have to review the attack vectors and code in
> >> fixes or recommendations as appropriate.
> >
> > keycloak.js could support both approaches. However, it would require access
> > to:
> >
> 
> Actually, I don't think you need the no-forms approach.  Just store a
> cookie.  The HTML5 app checks the cookie.  If it is set, grab the token
> from the cookie.  For logout, remove the cookie.  This is what the
> server-side adapter is doing already.
> 
> 
> > * Username
> > * User profile
> > * Roles
> > * ...
> >
> > With a pure HttpOnly cookie nothing is available unless users themselves
> > provide endpoints to retrieve this.
> >
> >>
> >> I also still think the current server-side approach is far superior for
> >> browser apps and should be the recommended approach.  As it is, you
> >> can't get around having server-side adapters, as they must at least be
> >> set up to handle bearer token authentication for secure REST invocations.
> >
> > I agree cookie with HttpOnly is the best approach. However, I think there's
> > situations where public credentials is the only option, for example:
> >
> 
> I'm talking about the whole redirect protocol to obtain an access token.
>   Its best driven by the server side then the client/application
> credentials don't have to be public.
> 
> > * Client-side web apps that consumes REST endpoints from multiple servers
> 
> See above.
> 
> > * Native mobile
> > * Desktop
> > * Devices (printers, game consoles, etc.)
> >
> > As MBaaS needs to support both client-side web apps and native mobile apps
> > the same approach could be used for both. If native mobile apps requires
> > public credentials, that has to be done securely.
> >
> 
> Native, desktop, and devices would be a tiny bit different as they can't
> rely on a browser to store information like cookies.  I think there
> would be 2 approaches for these types of things:
> 
> 1) oauth client with public credentials.  Going through OAuth Grant Page
> required on initial access. Device/mobile/desktop app obtains and stores
> a refresh token.
> 
> 2) Device registration.  User creates an oauth client on their account
> management page, configures the client for all permissions, then
> transfers the client_id/credentials to the device.
> 
> 
> 
> >>
> >> On 10/22/2013 11:47 AM, Stian Thorgersen wrote:
> >>> Right,
> >>>
> >>> Imagine this scenario:
> >>>
> >>> An application (this can be a JSF or JS, or whatever) has a menu-bar that
> >>> has options that should only be shown to certain users, it also displays
> >>> the username of the logged-in user. A user that is not logged in to the
> >>> SSO realm visits the application. The user then clicks on Login and is
> >>> redirected to the login form on the Keycloak server. The user logs in and
> >>> is redirected back to the application and can now see additional entries
> >>> in the menu.
> >>>
> >>> Later another user that is already logged in to the SSO realm visits the
> >>> same application. The application can't automatically log this user in,
> >>> as
> >>> that would require automatically redirecting the user to the login form
> >>> on
> >>> the Keycloak server. This would be fine for this user as the user is
> >>> already logged-in. However, that would break the previous case where a
> >>> user visited the application without being logged in to the SSO realm.
> >>>
> >>> Now, if there was an option to retrieve an access code (the proposal I've
> >>> commited) without showing the login form you could solve both cases. The
> >>> application can automatically log the user in to the application if
> >>> already logged in to the SSO realm, and wouldn't end up showing the login
> >>> form if the user was not logged in (instead the user would be redirected
> >>> back to the application without being logged in, and able to click on
> >>> Login when he/she chooses to).
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, 22 October, 2013 4:35:51 PM
> >>>> Subject: Re: [keycloak-dev] Automatically login user to application when
> >>>> logged into realm
> >>>>
> >>>>
> >>>> On 10/22/2013 11:22 AM, Stian Thorgersen wrote:
> >>>>> Let's see if I can manage to explain this properly.
> >>>>>
> >>>>> The flow is:
> >>>>>
> >>>>> 1. Application redirects to '../auth/request/login'
> >>>>> 1.1. If user is not logged in to realm display login form
> >>>>> 1.2. If application is not a KEYCLOAK_APPLICATION and doesn't already
> >>>>> have
> >>>>> grants display oauth grant page
> >>>>> 2. If successful redirect to application with authorization code
> >>>>> 3. Application retrieves access token from '../access/codes'
> >>>>>
> >>>>> With the current flow there is no way for an application to check if a
> >>>>> user
> >>>>> is already logged-in to the realm (+ grants given). So the only options
> >>>>> would be to either:
> >>>>>
> >>>>
> >>>> I don't get why the application needs to check if the user is already
> >>>> logged in.  Just start the oauth flow by redirecting to the auth-server.
> >>>>     If the user is already logged in, then, keycloak *already* will
> >>>>     create
> >>>> an access code and redirect back to the redirect URL immediately.
> >>>
> >>>
> >>>
> >>>>
> >>>> I do not think you approach is correct at the moment..  IMO, what you
> >>>> have to do is create a Javascript Application Adapter that can run in
> >>>> the browser.  It would work exactly like the JBoss Application adapter
> >>>> except it would run within the browser.
> >>>>
> >>>> ALl in all, IMO, you're still better off doing this flow on the server
> >>>> side like the examples do.  It is more secure as it doesn't require
> >>>> public client/application credentials.
> >>>>
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> JBoss, a division of Red Hat
> >>>> http://bill.burkecentral.com
> >>>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 