<div dir="ltr"><div>Speaking of subject_identifier_uri</div><div><br></div><div>From the spec:</div><div><br></div><div><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small">&quot;When a<span class="inbox-inbox-Apple-converted-space"> </span></span><tt style="color:rgb(0,51,102);font-family:&quot;courier new&quot;,courier,monospace;font-size:small">sector_identifier_uri</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small"><span class="inbox-inbox-Apple-converted-space"> </span>is provided, the host component of that URL is used as the Sector Identifier for the pairwise identifier calculation. The value of the<span class="inbox-inbox-Apple-converted-space"> </span></span><tt style="color:rgb(0,51,102);font-family:&quot;courier new&quot;,courier,monospace;font-size:small">sector_identifier_uri</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small"><span class="inbox-inbox-Apple-converted-space"> </span>MUST be a URL using the<span class="inbox-inbox-Apple-converted-space"> </span></span><tt style="color:rgb(0,51,102);font-family:&quot;courier new&quot;,courier,monospace;font-size:small">https</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small"><span class="inbox-inbox-Apple-converted-space"> </span>scheme that points to a JSON file containing an array of<span class="inbox-inbox-Apple-converted-space"> </span></span><tt style="color:rgb(0,51,102);font-family:&quot;courier new&quot;,courier,monospace;font-size:small">redirect_uri</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small"><span class="inbox-inbox-Apple-converted-space"> </span>values. The values of the registered<span class="inbox-inbox-Apple-converted-space"> </span></span><tt style="color:rgb(0,51,102);font-family:&quot;courier new&quot;,courier,monospace;font-size:small">redirect_uris</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small"><span class="inbox-inbox-Apple-converted-space"> </span>MUST be included in the elements of the array.&quot;</span><br></div><div><br></div><div>What&#39;s your stance on sanity/health checking the sector_identifier_uri? URI validation is one thing, but should we also make a request to the uri in order to validate the response?</div><div><br></div><div>The spec also mentions that the sector_identifier_uri isn&#39;t strictly required if a client has all it&#39;s redirect_uris under the same domain. How do we deal with changes to clients if the sector_identifier_uri isn&#39;t required for enabling pairwise subs?</div><div><br></div><div>Example:</div><div><br></div><div>I create a client, enabling pairwise subs. Valid redirect_uris are [ <a href="https://www.mydomain.com/*">https://www.mydomain.com/*</a> ]. The sector_identifier would be mydomain.</div><div><br></div><div>Later on, I update the redirect_uris to [<span class="inbox-inbox-Apple-converted-space"> </span><a href="https://www.mydomain.com/*">https://www.mydomain.com/*</a>, <a href="https://www.myotherdomain.com/*">https://www.myotherdomain.com/*</a> ] Do we</div><div><br></div><div>* keep the old sector_identifier, or</div><div>* reject the update, or</div><div>* allow the update if a valid subject_identifier_uri is provided at mydomain, or</div><div>* just allow it and let the client devs deal with the consequences, or</div><div>* take some other path you can think of ?</div><div><br></div><div>Having the sector_identifier_uri as a hard requirement seems safer, but it&#39;s also means more work implementing a client. Leaving it optional is a lot more scary.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen &lt;<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Makes sense to make this pluggable. The default should probably SHA-256( sector_identifier || local_sub || salt ).<div><br></div><div>We would love a PR for this, but there&#39;s a few bits required:</div><div><br></div><div>* OIDC clients need option for subject type and sector_identifier_uri. If not set it should default to public so existing clients continue to work. These options can just be set as client attributes so there&#39;s no need to update db schema</div><div>* Admin console update for the above</div><div>* <span style="font-size:12.8px">PairwiseSubGeneratorSpi</span> and default implementation</div><div>* Generation of salt for clients. This should be done when a client sets subject type to pairwise</div><div>* Tests and docs</div><div><br></div><div>I&#39;d say the <span style="font-size:12.8px">PairwiseSubGeneratorSpi signature should probably be:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">* public String getPairwiseSub(UserModel user, </span><span style="font-size:12.8px">ClientModel client</span><span style="font-size:12.8px">)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It might even be an option to let the default PairwiseSubGenerator provider create the salt and store it as an attribute on the client, making that part pluggable as well.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 August 2016 at 15:59, Martin Hardselius <span dir="ltr">&lt;<a href="mailto:martin.hardselius@gmail.com" target="_blank">martin.hardselius@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I&#39;m going to bump this, as I want to continue the discussion/provide some input.</div><div><br></div><div>Does it make sense to support more than type of pairwise subject identifier generator? E.g through a PairwiseSubGeneratorSpi?</div><div><br></div><div>Let&#39;s say I want to generate the pairwise sub as a salted hash: sub = SHA-256( sector_identifier || local_sub || salt )</div><div>To me, it makes sense to allow for per-client salts. These salts should probably be generated and persisted during client creation. Thoughts?</div></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, 12 Aug 2016 at 09:57 Martin Hardselius &lt;<a href="mailto:martin.hardselius@gmail.com" target="_blank">martin.hardselius@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you for your response. Did not see that ticket before. Great news!<div><br></div><div>I looked into using protocol mappers to achieve this, and while it would work I&#39;m worried that once KEYCLOAK-3422 has been resolved and included in a proper release we would run into migration issues if the method used for calculating &quot;native&quot; pairwise subs is different from what we implement. Clients could loose / be forced to re-register all their users if we decide to switch. The example methods in the spec are just that. Examples. Maybe the method/alg for computing the pairwise sub should be pluggable?</div></div><div dir="ltr"><div><br></div><div>-- </div><div>Martin</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 11 Aug 2016 at 17:15 Marek Posolda &lt;<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Sorry for late response. <br>
      <br>
      We have JIRA created for that. You can possibly add yourself as a
      watcher. See <a href="https://issues.jboss.org/browse/KEYCLOAK-3422" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-3422</a><br>
      <br>
      Maybe an alternative for you is to use protocolMappers. That
      should allow you to &quot;construct&quot; the token for particular client
      exactly how you want and also use the different value for &quot;sub&quot;
      claim. <br>
      <br>
      Another possibility is, to handle this on adapter side. We already
      have an adapter option &quot;principal-attribute&quot;, which specifies that
      application will see the different attribute instead of &quot;sub&quot; as
      subject. For example when in appllication you call
      &quot;httpServletRequest.getRemoteUser()&quot; it will return &quot;john&quot; instead
      of &quot;123456-unique-johns-uuid&quot; . See
<a href="https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html" target="_blank">https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html</a><br>
      <br>
      Hopefully some of the options can be useful for you?<br>
      <br>
      Marek</div></div><div bgcolor="#FFFFFF" text="#000000"><div><br>
      <br>
      On 02/08/16 14:13, Martin Hardselius wrote:<br>
    </div></div><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite">
      <div dir="ltr">
        <div>Me and my team are working towards getting Keycloak,
          customized for our needs, into production but we&#39;ve identified
          the need for Pairwise Subject Identifiers as we don&#39;t want to
          expose internal user ids.</div>
        <div><br>
        </div>
        <div>Right now, the only subject_types_supported seems to be
          &quot;public&quot;. Are there any near-future plans to include
          &quot;pairwise&quot;? Can we pitch in with a PR to make this happen as
          soon as possible?</div>
        <div><br>
        </div>
        <div>Links to relevant sections in the spec:</div>
        <div><br>
        </div>
        <a href="http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes" target="_blank">http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes</a><br>
        <div><a href="http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg" target="_blank">http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg</a><br>
        </div>
        <div><br>
        </div>
        <div>-- </div>
        <div>Martin</div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </blockquote></div><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
    </blockquote>
    <br>
  </div>

</blockquote></div></blockquote></div>
</div></div><br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>
</blockquote></div>