Hi, I am trying to implement a remote user password change for the logged in user. This is a requirement for the protocol we are required to support which accepts xml formatted commands over a network port, one of which is a password change request. The user is logged in via a Direct Grant from the Remoting application and we have a full KeycloakPrincipal attached to each remote session. When I POST to the form at /realms/{realm}/account/password using a Bearer Auth the password does reset but I get a 500 status back from Keycloak. The issue is that it is trying to rebuild an html response from the ‘password.ftl’ template and it does not have a value for ‘stateChecker’. After reviewing the code on github I found that if you use Bearer Auth, AccountService.init() never initializes a value to stateChecker. So even though I passed one in as a cookie on the POST and inside the form itself it never gets read. The workaround is to use cookies only to handle the authentication mechanism; specifically KEYCLOAK_STATE_CHECKER and KEYCLOAK_IDENTITY and not include Bearer authentication at all. So there is a workaround and it requires the use of cookies only and not Bearer Auth. I know this is not really the intended use of the POST to this form (eg: using it like a REST endpoint), but if anyone else runs into this issue at least they can learn from what I found by searching the mailing list archives. So this leaves me with a couple of questions Why does using Bearer Auth not initialize some sort of value for stateChecker here (ie: Is this a bug)? When you use cookies it appears to even generate a value for stateChecker if none is found in the cookie. What is the purpose of embedding it as a hidden input on the password change form? It appears to never get read when the form is processed anyways. Thanks, Daniel _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Daniel Baxter" <daniel.baxter(a)cira.ca&gt; To: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org Sent: Wednesday, March 4, 2015 7:31:06 PM Subject: Re: [keycloak-dev] POST to /realms/{realm}/account/password results in server 500 Thanks for the reply Bill. Raised as https://issues.jboss.org/browse/KEYCLOAK-1081 -----Original Message----- From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Bill Burke Sent: Wednesday, March 04, 2015 12:00 PM To: keycloak-dev(a)lists.jboss.org Subject: Re: [keycloak-dev] POST to /realms/{realm}/account/password results in server 500 The stateChecker exists to protect against CSRF browser attacks. I think we can ignore this check if the request is bearer authenticated. Submit a JIRA please? On 3/4/2015 11:47 AM, Daniel Baxter wrote: > Hi, > > I am trying to implement a remote user password change for the logged > in user. This is a requirement for the protocol we are required to > support which accepts xml formatted commands over a network port, one > of which is a password change request. The user is logged in via a > Direct Grant from the Remoting application and we have a full > KeycloakPrincipal attached to each remote session. When I POST to the > form at /realms/{realm}/account/password using a Bearer Auth the > password does reset but I get a 500 status back from Keycloak. The > issue is that it is trying to rebuild an html response from the > 'password.ftl' template and it does not have a value for 'stateChecker'. > > After reviewing the code on github I found that if you use Bearer > Auth, > AccountService.init() never initializes a value to stateChecker. So > even though I passed one in as a cookie on the POST and inside the > form itself it never gets read. The workaround is to use cookies only > to handle the authentication mechanism; specifically > KEYCLOAK_STATE_CHECKER and KEYCLOAK_IDENTITY and not include Bearer > authentication at all. So there is a workaround and it requires the > use of cookies only and not Bearer Auth. I know this is not really the > intended use of the POST to this form (eg: using it like a REST > endpoint), but if anyone else runs into this issue at least they can > learn from what I found by searching the mailing list archives. > > So this leaves me with a couple of questions > > Why does using Bearer Auth not initialize some sort of value for > stateChecker here (ie: Is this a bug)? When you use cookies it appears > to even generate a value for stateChecker if none is found in the cookie. > > What is the purpose of embedding it as a hidden input on the password > change form? It appears to never get read when the form is processed > anyways. > > Thanks, > > Daniel > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev