<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I've only worked on one application
      that required impersonation, but we thought about the problem
      differently.<br>
      <br>
      It was the corporate travel offering from Sabre.&nbsp; The problem was
      that an administrative assistant needed to be able to book travel
      for one or more executives.&nbsp; The assistant would not actually
      impersonate the user, but the application simply knew who she was
      allowed to book travel for.&nbsp; Therefore, impersonation was really
      more like composite roles that included a user name (or a wildcard
      for "any user").&nbsp; It was up to the application to know what to do
      with the roles.&nbsp; It would present a drop-down to select which user
      you were working on behalf of.<br>
      <br>
      This way, you never require more than one login or logout.&nbsp; You
      are just pushing all the complexity onto the application.&nbsp;&nbsp; But
      maybe that's where it belongs.<br>
      <br>
      On 4/9/2015 3:23 AM, Marek Posolda wrote:<br>
    </div>
    <blockquote cite="mid:552628FF.7060303@redhat.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <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."
          &nbsp;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>&nbsp; boolean isImpersonated;</div>
          <div>&nbsp; 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.&nbsp; 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;&nbsp;
&nbsp;/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&#8217;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&#8217;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&#8217;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&#8217;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&#8217;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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>
<a moz-do-not-send="true" 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>
      <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>