<div dir="ltr">We need to follow the spec and verify that sector_identifier_uri points to a URL that contains the corresponding URIs. As an enhancement we could support wildcards in the JSON returned by sector_identifier_uri. For example if it returns:<div><br></div><div><span style="font-size:12.8px">[</span><span style="font-size:12.8px"> </span><a href="https://www.mydomain.com/*" target="_blank" style="font-size:12.8px">https://www.mydomain.com/*</a><span style="font-size:12.8px">, </span><a href="https://www.myotherdomain.com/*" target="_blank" style="font-size:12.8px">https://www.myotherdomain.com/<wbr>*</a><span style="font-size:12.8px"> ]</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">A client with the redirect uri '<a href="https://www.myotherdomain.com/myapp">https://www.myotherdomain.com/myapp</a>' would work</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 August 2016 at 15:09, Martin Hardselius <span dir="ltr"><<a href="mailto:martin.hardselius@gmail.com" target="_blank">martin.hardselius@gmail.com</a>></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>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">"When a<span> </span></span><tt style="color:rgb(0,51,102);font-family:"courier new",courier,monospace;font-size:small">sector_identifier_uri</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small"><span> </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> </span></span><tt style="color:rgb(0,51,102);font-family:"courier new",courier,monospace;font-size:small">sector_identifier_uri</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small"><span> </span>MUST be a URL using the<span> </span></span><tt style="color:rgb(0,51,102);font-family:"courier new",courier,monospace;font-size:small">https</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small"><span> </span>scheme that points to a JSON file containing an array of<span> </span></span><tt style="color:rgb(0,51,102);font-family:"courier new",courier,monospace;font-size:small">redirect_uri</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small"><span> </span>values. The values of the registered<span> </span></span><tt style="color:rgb(0,51,102);font-family:"courier new",courier,monospace;font-size:small">redirect_uris</tt><span style="font-family:verdana,charcoal,helvetica,arial,sans-serif;font-size:small"><span> </span>MUST be included in the elements of the array."</span><br></div><div><br></div><div>What'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't strictly required if a client has all it's redirect_uris under the same domain. How do we deal with changes to clients if the sector_identifier_uri isn'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/*" target="_blank">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> </span><a href="https://www.mydomain.com/*" target="_blank">https://www.mydomain.com/*</a>, <a href="https://www.myotherdomain.com/*" target="_blank">https://www.myotherdomain.com/<wbr>*</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's also means more work implementing a client. Leaving it optional is a lot more scary.</div><div><br></div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Thu, 18 Aug 2016 at 10:45 Stian Thorgersen <<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>> 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'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'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'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"><<a href="mailto:martin.hardselius@gmail.com" target="_blank">martin.hardselius@gmail.com</a>></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'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'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 <<a href="mailto:martin.hardselius@gmail.com" target="_blank">martin.hardselius@gmail.com</a>> 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'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 "native" 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 <<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>> 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/<wbr>browse/KEYCLOAK-3422</a><br>
<br>
Maybe an alternative for you is to use protocolMappers. That
should allow you to "construct" the token for particular client
exactly how you want and also use the different value for "sub"
claim. <br>
<br>
Another possibility is, to handle this on adapter side. We already
have an adapter option "principal-attribute", which specifies that
application will see the different attribute instead of "sub" as
subject. For example when in appllication you call
"httpServletRequest.<wbr>getRemoteUser()" it will return "john" instead
of "123456-unique-johns-uuid" . 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/<wbr>securing-client-applications-<wbr>guide/content/v/2.1/topics/<wbr>oidc/java/java-adapter-config.<wbr>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've identified
the need for Pairwise Subject Identifiers as we don't want to
expose internal user ids.</div>
<div><br>
</div>
<div>Right now, the only subject_types_supported seems to be
"public". Are there any near-future plans to include
"pairwise"? 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/<wbr>openid-connect-core-1_0.html#<wbr>SubjectIDTypes</a><br>
<div><a href="http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg" target="_blank">http://openid.net/specs/<wbr>openid-connect-core-1_0.html#<wbr>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>______________________________<wbr>_________________
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/<wbr>mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</div>
</blockquote></div></blockquote></div>
</div></div><br>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>