[keycloak-user] Login works sometimes, sometimes doesn't

[Jesse Chahal]

>From what I can tell we don't have a filter adding caching to HTTP302
calls. I did not update the distributed-cache settings to have more
then one owner. I made the update after the fact and restarted
keycloak. This did not fix the problem and I still end up with the
same stracktraces I sent out in the original email. This setting is a
bit worrying to me as I would have to hardcode the cache to distribute
to a specific number of nodes rather then distribute the cache to all
nodes within the cluster. We will be doing doing elastic load
balancing to dynamically increase and decrease the number of keycloak
nodes into the cluster. It seems once we have ended up in this state
it is impossible to undo? There might have been something persisted to
the database that made this issue permanent? We definitely had
keycloak 1.9.1 working before we switched from running a single
instance without HA mode to HA mode. HA mode did appear to work for
awhile until we had terminated one of the nodes in the cluster. We
enabled HA mode based on some comments made by others on the user
distribution list. I believe the thread was on
http://lists.jboss.org/pipermail/keycloak-user/2016-April/005667.html
. It was on the same version of keycloak as us but was running on ECS
(docker) instead of EC2.

Preferably I would like to turn the cache off entirely as we are not
currently restricted to performance issues right now. Is there a way
to completely turn off cache so I could run multiple keycloak
instances without needing to run in HA mode? I did see some keycloak
PR's that had added sections to the keycloak-server.json which set
session cache to true/enabled. Couldn't I simply set it to
false/disabled to achieve the desired result?


Thanks,
Jesse


> Date: Wed, 13 Apr 2016 23:13:46 -0400
> From: Bill Burke <bburke at redhat.com>
> Subject: Re: [keycloak-user] Login works sometimes, sometimes doesn't
> To: keycloak-user at lists.jboss.org
> Message-ID: <570F0AEA.9010102 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> These problems only happen when a cluster node dies?  If so:
>
> How are you setting up the distributed cache for user sessions?  If you
> have only 1 owner, then the session is only replicated on one node.
> This is the default behavior.
>
> <distributed-cache name="sessions" mode="SYNC" owners="1"/>
>
> 302 redirects should not be cached by the browser unless a Cache-Control
> header is set.  Do you have a filter doing this?
>
> http://stackoverflow.com/questions/12212839/how-long-is-a-302-redirect-saved-in-browser
>
>
>
> On 4/13/2016 9:53 PM, Jesse Chahal wrote:
>> Hi,
>>
>> So it looks like the previous fix to the logout URL did the trick.
>> I've now run into a much harder to solve problem (and harder to
>> describe). We are inconsistently able to login to our client
>> applications using keycloak for authentication. Trying the same
>> username+password has about an 80% chance of logging you in correctly.
>> It has a 15% chance of logging you in correctly if a keycloak node
>> within a keycloak cluster dies. I made up the %'s but its based on
>> what we are observing. So a user is actually able to login in the
>> sense of putting in a username+password and getting redirected to the
>> client applications, after that things may or may not go wrong. Often
>> times they will access the client application with the correct role
>> and everything will work ok. Sometimes though if something goes wrong
>> they will be redirected back to the client and will not be able to
>> access the client correctly. The below stacktraces usually show up in
>> those cases. I think it might be related to keycloak cache + browser
>> cache having weird issues as the only way to I've seen to resolve this
>> issues is to destroy the session cache within keycloak and get rid of
>> the browser cache (browser cache is more of a fault of the client app
>> probably). Even with this it can take multiple attempts before a user
>> regains the ability to go to the keycloak admin page and still may or
>> may not lead to a successful redirect to the client with a correctly
>> authenticated account (could start this whole weird loop again with
>> the stracktraces below). I don't know if anyone has come into an issue
>> like this. I was also hoping to find examples of client applications
>> that have their own accounts which somehow get mapped to keycloak
>> accounts but I haven't seen any.
>>
>>
>> Environment
>> ------------------------
>> - keycloak 1.9.1.Final
>> - running using standalone-HA.xml
>> - using JGroups+JDBC_Ping
>> - postgres database
>> - on AWS
>> - some global roles (set on user accounts)
>>
>> Client
>> ------------
>> - running on Wildfly10
>> - using keycloak subsystem
>> - client protocol = openid-connect
>> - access type = confidential
>> - standard flow enabled
>> - client authenticator = client id and secret
>>
>>
>> Keycloak 1.9.1 server error
>> -------------------------------------------
>> 2016-04-14 01:20:11,112 WARN  [org.keycloak.events] (default task-17)
>> type=CODE_TO_TOKEN_ERROR, realmId=1234-5678-9012-3456-7890,
>> clientId=some_wildfly_client, userId=null, ipAddress=123.456.789.0,
>> error=invalid_code, grant_type=authorization_code,
>> code_id=b2744ba1-7f74-4849-8077-b17659af3095,
>> client_auth_method=client-secret
>> 2016-04-14 01:29:27,402 WARN  [org.keycloak.events] (default task-2)
>> type=CODE_TO_TOKEN_ERROR, realmId=1234-5678-9012-3456-7890, clientId=
>> some_wildfly_client, userId=null, ipAddress=123.456.789.0,
>> error=invalid_code, grant_type=authorization_code,
>> code_id=58a57076-1f8e-404e-813b-13c31abe8efb,
>> client_auth_method=client-secret
>> 2016-04-14 01:29:27,402 WARN  [org.keycloak.events] (default task-2)
>> type=CODE_TO_TOKEN_ERROR, realmId=1234-5678-9012-3456-7890, clientId=
>> some_wildfly_client, userId=null, ipAddress=123.456.789.0,
>> error=invalid_code, grant_type=authorization_code,
>> code_id=58a57076-1f8e-404e-813b-13c31abe8efb,
>> client_auth_method=client-secret
>>
>>
>>
>> Wildfly 10 client server error:
>> -----------------------------------------
>> 01:29:27,410 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
>> (default task-13) [gwt_pc3q14cr_101 blah at example.com ] failed to turn
>> code into token
>> 01:29:27,410 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
>> (default task-13) [gwt_pc3q14cr_101 blah at example.com ] status from
>> server: 400
>> 01:29:27,410 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
>> (default task-13) [gwt_pc3q14cr_101 blah at example.com ]
>> {"error_description":"Code not found","error":"invalid_grant"}