Use an embedded web view and problem solved ;)
On 30 August 2016 at 13:22, Christopher Davies <
The redirect dance it a bit more complex as I am in a GWT
However thanks for the feedback.
In most cases redirecting to login page will be easy enough, it is just
during editing that things may get tricky
On Fri, Aug 26, 2016 at 10:09 AM Stian Thorgersen <sthorger(a)redhat.com>
> If you're adding new roles the refresh token will continue to work, but
> won't get new roles. If you're removing roles the refresh token won't be
> permitted anymore.
> You don't need to re-login though. Just discard the refresh token, do the
> redirect dance to Keycloak again and you'll get a new client session under
> the existing user session so the user won't have to re-authenticate, but
> you'll have your new refresh token with updates roles.
> On 20 August 2016 at 09:52, Christopher Davies <christopher.james.davies@
> gmail.com> wrote:
>> I adding keycloak into a legacy application that uses GWT and Jetty.
>> I have managed to get add Keycloak application using Spring-security.
>> Because this is GWT I am doing the authorisation in the application
>> Sping just provides a way to get access to the KeycloakSecurityContext.
>> The issue I have is refreshing the token. I can get hold of a
>> RefreshableKeycloakSecurityContext instance
>> and use that to get a refresh token. What surprised me is that I cannot
>> refresh a token if the roles have changed.
>> Is this correct. I was hoping that the application could notice the role
>> changes and adapt itself on the fly.
>> I do not want to have to logout to get the new roles it at all possible.
>> Is there something that I have overlooked that will allow
>> me to use the idToken to get a new accessToken given that the
>> authentication of the user is still valid, it is just the roles the user is
>> in that have changed.
>> keycloak-user mailing list