[keycloak-user] Question about the javascript-adapter and the check-sso option with a confidential client

[Marek Posolda]

On 28/06/16 00:20, Tomás García wrote:
> On 06/27/2016 01:07 PM, Marek Posolda wrote:
>> I think your possibilities are either:
>> - Use different client for keycloak.js (public client) and different 
>> client for your confidential servlet application
>
> I thought about it, but at the moment I thought about what is the 
> point of having the confidential client if the public one is needed, I 
> discarded that option. Since the autologin affects the same website, 
> there's no point to have two clients attacking the same resource. The 
> public client is the weakest link of the chain, so having a secret key 
> doesn't add anything to security; only for accountability, maybe.
>
>> - Don't use keycloak.js at all, but instead do some HTTP Filter to 
>> deal with "autologin" . You will manually try to redirect to keycloak 
>> with "prompt=none" . If user is not logged, keycloak will redirect 
>> back to the callback redirect_uri, where you recognize if there is 
>> "code" or "error" parameter and based on that, you know if user is 
>> logged or not. If user is logged, you can redirect to secured URL to 
>> properly trigger authentication process (maybe you can optimize this 
>> step by reuse the "code", which you already have and directly open 
>> the secured URI with it, but I am not 100% sure if it works with 
>> considering that you also need correct "state" etc.) Otherwise, you 
>> can set some state or something, to recognize that autologin has been 
>> already unsuccessfully tried.
>
> Oh well, it's a website made in PHP, not a servlet, but the same idea 
> can be applied. But I had to discard that option too due to technical 
> reasons: I'm not exactly in control of the whole website, since I'm 
> adding the autologin to a project I didn't work on in the past, which 
> isn't as well engineered for extensibility as Keycloak :).
If you don't have control under the web-app, then I am not seeing much 
other possibilities then using some other "helper" client. Doesn't 
matter if it's public or not. The only purpose of helper client will be 
to check "prompt=none" and then either redirect to secured URI of real 
client (if logged) or public URI of real client (if not logged).

Sorry, no better ideas atm :/

Marek
>>
>> Maybe you can create JIRA to request support "autologin" for other 
>> types of clients then public keycloak.js clients.
>
> Thanks, Marek. I'll think about it. It's very likely that I'll open a 
> JIRA issue to discuss this further.
>
>>
>> Marek
>>
>> On 25/06/16 11:44, Tomás García wrote:
>>>
>>> Hi,
>>>
>>>  I wonder if it's possible to just check the SSO state with a 
>>> confidential client. My use case is the following one:
>>>
>>> - I have a website which uses a confidential client to login with 
>>> Keycloak.
>>>
>>> - I want to add autologin to this website.
>>>
>>> - So I use the javascript adapter with the following option object 
>>> for the init method: { onLoad: 'check-sso' }. The javascript adapter 
>>> is built without the secret key in its constructor (obviously if I 
>>> put the secret key in there, there's no point to use a confidential 
>>> client at all).
>>>
>>> But Keycloak fails with a "type=CODE_TO_TOKEN_ERROR, 
>>> error=invalid_client_credentials" error.
>>>
>>> So I don't know how feasible or secure is to just check that the 
>>> Keycloak session inside the cookie of the user's browser is still 
>>> valid. In my case, the browser doesn't need to get the user info, 
>>> access token, etc, because what I'll do is redirect the user to the 
>>> Keycloak login page with the confidential client afterwards is the 
>>> operation is successful. Since the Keycloak session is valid, 
>>> Keycloak should redirect back with the authentication code without 
>>> asking credentials to the user.
>>>
>>> Additional note: the CORS header isn't added to 400 responses in 
>>> Keycloak, so it was a bit confusing looking at the JS console in the 
>>> browser, because it complained about CORS but it was just Keycloak 
>>> giving the 400 response without the allow-origin header.
>>>
>>> Thanks.
>>>
>>> -- 
>>>
>>> *Tomás García Pérez
>>> *
>>>
>>> *Software Developer*
>>>
>>> *Intra**House***
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
> -- 
>
> *Tomás García Pérez
> *
>
> *Software Developer*
>
> *Intra**House***
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160628/03f6aaa2/attachment.html