<div dir="ltr">This is exactly what offline tokens where created to do. The offline token is not linked to user sessions so it doesn't matter if users login or not. Our adapters doesn't support it properly though so you'd need to create a filter or something that sets up the context and principle based on the offline token.</div><div class="gmail_extra"><br><div class="gmail_quote">On 19 May 2016 at 19:56, Jesse Chahal <span dir="ltr"><<a href="mailto:jessec@stytch.com" target="_blank">jessec@stytch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So we've done a lot of work on our migration to keycloak but still<br>
have a few holes that are using another authentication system. We are<br>
using Wildfly10 along with the keycloak subsystem. The last real<br>
blocking issues is trying to schedule background tasks on behalf of a<br>
user using quartz. We've tried using impersonation role and mocking<br>
out the impersonation workflow that a browser does, it was fairly<br>
complicated and did not work very well. Service accounts don't seem to<br>
fit this scenario either as service accounts seem to be for performing<br>
client specific actions. We considered storing offline token's on<br>
behalf of users but the thing is users might not log in for years<br>
after scheduling their job. We need to set the Context and Principle<br>
to be the user who we are performing background tasks on behalf of. Is<br>
there a recommended way of doing this that has been tested by others?<br>
I'm sure we aren't the only company who schedule tasks on behalf of<br>
users.<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</blockquote></div><br></div>