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

[Bill Burke]

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