<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">This is very similar to how I've
      implemented impersonation in GateIn portal. Basically the session
      wrapped the "admin" session and after logout, the admin session
      was restored back. So admin wasn't logged-out, but he was able to
      continue with his session in exactly same state like before
      impersonation.<br>
      <br>
      But for the Keycloak, it will be very tricky to support this as
      Keycloak is SSO and admin is already logged to some applications
      before he started impersonation session. So for support of
      save/restore the admin session, we would need to implement the
      "stack" for the UserSession on auth-server but also for all the
      application sessions. This might be possible (but quite tricky)
      for servlet adapters, but I am not seeing how to properly support
      it for JS adapter...<br>
      <br>
      In shortcut, it seems that we would really need to logout original
      admin session and then login as impersonated user. For audit
      purpose, we will have info that session is impersonated, but IMO
      we will not be able to restore original admin session back to the
      state before impersonation.<br>
      <br>
      Marek<br>
      <br>
      <br>
      On 8.4.2015 16:56, Scott Rossillo wrote:<br>
    </div>
    <blockquote
cite="mid:CALAqdu8S4waCixOodbqUgzYh-DGsAAgOYEi82Bxv_PxNS5trTg@mail.gmail.com"
      type="cite">
      <div dir="ltr">One thing I've seen done with Spring Security
        (custom code) is to implement the impersonation as a "stack."
         An admin impersonating another user gets pushed instead of
        logged out and when the impersonated user is logged out, the
        admin is popped and re-becomes the principal. This may be much
        more complex with distributed security, but the pseudo code of
        the token would be something like:
        <div><br>
        </div>
        <div>public class KeycloakSecurityContext {<br>
        </div>
        <div>  boolean isImpersonated;</div>
        <div>  KeycloakSecurityContext impersonatingContext;</div>
        <div>}</div>
        <div><br>
        </div>
        <div>This is obviously only one aspect but could be used by an
          application to know if the user is impersonated, and who's
          doing the impersonating.</div>
        <div><br>
        </div>
        <div>~ Scott</div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, Apr 8, 2015 at 10:17 AM, Raghu
          Prabhala <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:prabhalar@yahoo.com" target="_blank">prabhalar@yahoo.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Jumping in
            with my requirements as Impersonation is a very sensitive
            issue. It has to be read only and clearly indicated in both
            gui and audit engine( logs). We typically require both the
            admin and user information populated for audit purposes
            which means that the admin should not be logged out.<br>
            <br>
            Sent from my iPhone<br>
            <div class="HOEnZb">
              <div class="h5"><br>
                &gt; On Apr 8, 2015, at 9:55 AM, Bill Burke &lt;<a
                  moz-do-not-send="true" href="mailto:bburke@redhat.com">bburke@redhat.com</a>&gt;
                wrote:<br>
                &gt;<br>
                &gt; I worry a bit about how this can be exploited.  I
                think it might need to<br>
                &gt; be its own service that<br>
                &gt;<br>
                &gt; 1. checks and verifies the admin is logged in (via
                the cookie)<br>
                &gt; 2. Re-authenticates the admin manually<br>
                &gt; 3. Logouts out the admin and logins him in as
                impersonated user.<br>
                &gt;<br>
                &gt; There might be other sensitive areas/features where
                we might want to<br>
                &gt; require manual re-authentication before.<br>
                &gt;<br>
                &gt; Also, we might also want to add information to the
                id/access tokens and<br>
                &gt; saml assertions for auditing purposes so that
                clients know that the user<br>
                &gt; is being impersonated.<br>
                &gt;<br>
                &gt; FYI, I know this is a must-have feature in order
                for Red Hat IT to use us.<br>
                &gt;<br>
                &gt;<br>
                &gt;&gt; On 4/8/2015 12:53 AM, Stian Thorgersen wrote:<br>
                &gt;&gt; I would say an admin would need a special role
                as well as having all the roles of the user the admin
                wants to impersonate.<br>
                &gt;&gt;<br>
                &gt;&gt; That's the simple part, second part would be to
                let an admin login as another user. Maybe that could be
                done with a query param to the authorization endpoint,
                for example:<br>
                &gt;&gt;<br>
                &gt;&gt; 
 /realms/myrealm/protocols/openid-connect/auth?...&amp;kc_impersonate=&lt;username&gt;<br>
                &gt;&gt;<br>
                &gt;&gt; Would also be good to have a enable/disable
                option for this feature for a realm.<br>
                &gt;&gt;<br>
                &gt;&gt; ----- Original Message -----<br>
                &gt;&gt;&gt; From: "Scott Rossillo" &lt;<a
                  moz-do-not-send="true"
                  href="mailto:srossillo@smartling.com">srossillo@smartling.com</a>&gt;<br>
                &gt;&gt;&gt; To: "Bill Burke" &lt;<a
                  moz-do-not-send="true" href="mailto:bburke@redhat.com">bburke@redhat.com</a>&gt;<br>
                &gt;&gt;&gt; Cc: <a moz-do-not-send="true"
                  href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
                &gt;&gt;&gt; Sent: Wednesday, 8 April, 2015 1:13:19 AM<br>
                &gt;&gt;&gt; Subject: Re: [keycloak-user] Impersonate
                User<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Thanks.<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; Out of curiosity, how do you see this being
                implemented? Would a user who can<br>
                &gt;&gt;&gt; impersonate another have a specific role to
                allow this?<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; I’m thinking a bit about how I may be able
                to support it before it becomes a<br>
                &gt;&gt;&gt; feature, or if it’s something we would be
                able to contribute.<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; ~ Scott<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; On Tue, Apr 7, 2015 at 6:06 PM, Bill Burke
                &lt; <a moz-do-not-send="true"
                  href="mailto:bburke@redhat.com">bburke@redhat.com</a>
                &gt; wrote:<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; We don't have this feature but it is
                something that some key customers<br>
                &gt;&gt;&gt; want. I would say we would get to it
                sometime this summer.<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; On 4/7/2015 6:03 PM, Scott Rossillo
                wrote:<br>
                &gt;&gt;&gt;&gt; Hi,<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; We’re looking for the best way to
                support having one user, such as an<br>
                &gt;&gt;&gt;&gt; admin, have the ability to impersonate
                another user. I don’t see a<br>
                &gt;&gt;&gt;&gt; simple way to do this with Keycloak at
                the moment.<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Would you mind letting me know if this
                is on the roadmap - I didn’t see<br>
                &gt;&gt;&gt;&gt; a JIRA - or if you have any
                recommendations on implementing such behavior.<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt; Thanks,<br>
                &gt;&gt;&gt;&gt; Scott<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;<br>
                &gt;&gt;&gt;&gt;
                _______________________________________________<br>
                &gt;&gt;&gt;&gt; keycloak-user mailing list<br>
                &gt;&gt;&gt;&gt; <a moz-do-not-send="true"
                  href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
                &gt;&gt;&gt;&gt; <a moz-do-not-send="true"
                  href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
                  target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt; --<br>
                &gt;&gt;&gt; Bill Burke<br>
                &gt;&gt;&gt; JBoss, a division of Red Hat<br>
                &gt;&gt;&gt; <a moz-do-not-send="true"
                  href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
                &gt;&gt;&gt;
                _______________________________________________<br>
                &gt;&gt;&gt; keycloak-user mailing list<br>
                &gt;&gt;&gt; <a moz-do-not-send="true"
                  href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
                &gt;&gt;&gt; <a moz-do-not-send="true"
                  href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
                  target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt;<br>
                &gt;&gt;&gt;
                _______________________________________________<br>
                &gt;&gt;&gt; keycloak-user mailing list<br>
                &gt;&gt;&gt; <a moz-do-not-send="true"
                  href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
                &gt;&gt;&gt; <a moz-do-not-send="true"
                  href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
                  target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
                &gt;<br>
                &gt; --<br>
                &gt; Bill Burke<br>
                &gt; JBoss, a division of Red Hat<br>
                &gt; <a moz-do-not-send="true"
                  href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
                &gt; _______________________________________________<br>
                &gt; keycloak-user mailing list<br>
                &gt; <a moz-do-not-send="true"
                  href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
                &gt; <a moz-do-not-send="true"
                  href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
                  target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
keycloak-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
    </blockquote>
    <br>
  </body>
</html>