<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Yes, Thanks for sharing.<br>
<br>
Marek<br>
<br>
On 31/08/16 13:29, Martin Hardselius wrote:<br>
</div>
<blockquote
cite="mid:CAPJq0L-FAJe=1Zt5Vw5AVXp6adwMBsPhF7MKC3LU4s8HtCUyCQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div style="font-size:small">Just had the chance to start
looking at this. Wanted to check with you if this is the
direction you had in mind?<br>
</div>
<div style="font-size:small">
<pre style="background-image:initial;background-position:initial;background-repeat:initial"><span style="color:rgb(128,0,0);font-weight:bold">public</span> <span style="color:rgb(128,0,0);font-weight:bold">abstract</span> <span style="color:rgb(128,0,0);font-weight:bold">class</span> AbstractPairwiseSubGeneratorMapper <span style="color:rgb(128,0,0);font-weight:bold">extends</span> AbstractOIDCProtocolMapper <span style="color:rgb(128,0,0);font-weight:bold">implements</span> OIDCAccessTokenMapper, OIDCIDTokenMapper <span style="color:rgb(128,0,128)">{</span>
<span style="color:rgb(128,128,48)">@</span>Override
<span style="color:rgb(128,0,0);font-weight:bold">public</span> IDToken transformIDToken<span style="color:rgb(128,128,48)">(</span>IDToken token<span style="color:rgb(128,128,48)">,</span> ProtocolMapperModel mappingModel<span style="color:rgb(128,128,48)">,</span> KeycloakSession session<span style="color:rgb(128,128,48)">,</span> UserSessionModel userSession<span style="color:rgb(128,128,48)">,</span> ClientSessionModel clientSession<span style="color:rgb(128,128,48)">)</span> <span style="color:rgb(128,0,128)">{</span>
token<span style="color:rgb(128,128,48)">.</span>setSubject<span style="color:rgb(128,128,48)">(</span>generateSub<span style="color:rgb(128,128,48)">(</span>mappingModel<span style="color:rgb(128,128,48)">,</span> userSession<span style="color:rgb(128,128,48)">.</span>getUser<span style="color:rgb(128,128,48)">(</span><span style="color:rgb(128,128,48)">)</span><span style="color:rgb(128,128,48)">.</span>getId<span style="color:rgb(128,128,48)">(</span><span style="color:rgb(128,128,48)">)</span><span style="color:rgb(128,128,48)">)</span><span style="color:rgb(128,128,48)">)</span><span style="color:rgb(128,0,128)">;</span>
<span style="color:rgb(128,0,0);font-weight:bold">return</span> token<span style="color:rgb(128,0,128)">;</span>
<span style="color:rgb(128,0,128)">}</span>
<span style="color:rgb(128,128,48)">@</span>Override
<span style="color:rgb(128,0,0);font-weight:bold">public</span> AccessToken transformAccessToken<span style="color:rgb(128,128,48)">(</span>AccessToken token<span style="color:rgb(128,128,48)">,</span> ProtocolMapperModel mappingModel<span style="color:rgb(128,128,48)">,</span> KeycloakSession session<span style="color:rgb(128,128,48)">,</span> UserSessionModel userSession<span style="color:rgb(128,128,48)">,</span> ClientSessionModel clientSession<span style="color:rgb(128,128,48)">)</span> <span style="color:rgb(128,0,128)">{</span>
token<span style="color:rgb(128,128,48)">.</span>setSubject<span style="color:rgb(128,128,48)">(</span>generateSub<span style="color:rgb(128,128,48)">(</span>mappingModel<span style="color:rgb(128,128,48)">,</span> userSession<span style="color:rgb(128,128,48)">.</span>getUser<span style="color:rgb(128,128,48)">(</span><span style="color:rgb(128,128,48)">)</span><span style="color:rgb(128,128,48)">.</span>getId<span style="color:rgb(128,128,48)">(</span><span style="color:rgb(128,128,48)">)</span><span style="color:rgb(128,128,48)">)</span><span style="color:rgb(128,128,48)">)</span><span style="color:rgb(128,0,128)">;</span>
<span style="color:rgb(128,0,0);font-weight:bold">return</span> token<span style="color:rgb(128,0,128)">;</span>
<span style="color:rgb(128,0,128)">}</span>
<span style="color:rgb(128,0,0);font-weight:bold">public</span> <span style="color:rgb(128,0,0);font-weight:bold">abstract</span> <span style="color:rgb(187,121,119);font-weight:bold">String</span> generateSub<span style="color:rgb(128,128,48)">(</span>ProtocolMapperModel mappingModel<span style="color:rgb(128,128,48)">,</span> <span style="color:rgb(187,121,119);font-weight:bold">String</span> localSub<span style="color:rgb(128,128,48)">)</span><span style="color:rgb(128,0,128)">;</span>
<span style="color:rgb(128,0,128)">}</span></pre>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, 24 Aug 2016 at 12:03 Marek Posolda <<a
moz-do-not-send="true" href="mailto:mposolda@redhat.com"><a class="moz-txt-link-abbreviated" href="mailto:mposolda@redhat.com">mposolda@redhat.com</a></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>Sounds great. Thanks!</div>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<div><br>
<br>
Marek</div>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<div><br>
<br>
On 24/08/16 11:08, Martin Hardselius wrote:<br>
</div>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr">Sounds good. I'll look into it and see what
I can do. Possibly during next week. :)</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, 23 Aug 2016 at 15:38 Marek
Posolda <<a moz-do-not-send="true"
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>We discussed it with Stian a bit and we
discussed to:<br>
<br>
- Implement as protocolMapper<br>
<br>
- There will be possibility to configure "salt" as
parameter to protocolMapper. It may not be
mandatory parameter. If it's used, then client
will use it as salt, otherwise salt will be
generated. This allows the use-case you mentioned.
You can use same salt for clients x,y,z but
different salt for clients m,n. If you let
generate salt, then the subject identifiers will
be really unique just to the particular client.<br>
<br>
- We need to validate sector_identifier_uri during
create/update of protocolMapper, but also during
update of client. Otherwise someone can register
sector_identifier_uri and register the client with
valid redirect_uris (for example URLs <a
moz-do-not-send="true"
href="http://good-host/url1" target="_blank"><a class="moz-txt-link-rfc2396E" href="http://good-host/url1">"http://good-host/url1"</a></a>
<a moz-do-not-send="true"
href="http://good-host/url2" target="_blank">"http://good-host/url2"</a>
, which are both specified under
sector_identifier_uri ) but then later update just
the client redirect_uris to <a
moz-do-not-send="true"
href="http://evil-host/url1" target="_blank"><a class="moz-txt-link-rfc2396E" href="http://evil-host/url1">"http://evil-host/url1"</a></a>
. Basically he will be able to update
redirect_uris to anything he wants regardless of
redirect_uris under sector_identifier_uri, so the
whole validation will be bypassed.<br>
<br>
For updating client, I've just sent PR, which adds
RealmModel.ClientUpdatedEvent . You can register
to that event similarly like <a
moz-do-not-send="true"
href="https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/protocol/AbstractLoginProtocolFactory.java#L39"
target="_blank"><a class="moz-txt-link-freetext" href="https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/protocol/AbstractLoginProtocolFactory.java#L39">https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/protocol/AbstractLoginProtocolFactory.java#L39</a></a>
. The creation/update listener for protocolMapper
doesn't yet exists, however we are likely going to
refactor protocolMapper to generic component,
which will have validation support. But that will
be likely available in few weeks, so for now, we
can add something temporary for protocolMappers
similar to what is available for example for
UserFederationMapperFactory (See <a
moz-do-not-send="true"
href="https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UserFederationProviderResource.java#L437-L440"
target="_blank"><a class="moz-txt-link-freetext" href="https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UserFederationProviderResource.java#L437-L440">https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UserFederationProviderResource.java#L437-L440</a></a>
)<br>
<br>
Martin, will you have some time to eventually look
into this and send PR ?</div>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<div><br>
<br>
Marek</div>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<div><br>
<br>
On 23/08/16 14:25, Martin Hardselius wrote:<br>
</div>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr">
<div>Let's say we want to force all of our
client to use pairwise subs, but a single
"merchant" needs to implement several clients
where subs should remain the same for all
those clients.<br>
</div>
<div><br>
</div>
<div>Merchant A</div>
<div>- client x</div>
<div>- client y</div>
<div>- client z</div>
<div><br>
</div>
<div> Merchant B</div>
<div>- client m</div>
<div>- client n</div>
<div><br>
</div>
<div>You can assume the sector_identifiers are
the same across all clients owned by a
merchant</div>
<div><br>
</div>
<div>It should not be possible to correlate
activities between Customer A and Customer B
(at least not from their side). They should,
however, be able to correlate user activities
between their own clients.</div>
<div><br>
</div>
<div>Which implementation of pairwise subs is
better suited for supporting this scenario?
I'm leaning towards the protocol mapper
solution. It should be easier to create custom
mappers with merchant-wide configuration (e.g
salts).</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Mon, 22 Aug 2016 at 22:40
Marek Posolda <<a moz-do-not-send="true"
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>The question is, should we really
introduce another SPI for that? Doesn't it
mean uneccessary complexity? Also add the
new options directly to the client for the
feature, which is likely interesting just
for quite limited amount of people?<br>
<br>
IMO it's fine if this is implemented as
protocolMapper? <br>
<br>
Few thoughts:<br>
- We can have abstract superclass like
AbstractPairwiseSubGeneratorMapper . The
subclasses will just need to implement
method "generateSub" . We can have just
one concrete impl, which will use SHA-256(
sector_identifier || local_sub || salt )<br>
<br>
- The sector_identifier_uri will be a
configuration option of this
protocolMapper implementation. <br>
<br>
- If protocolMapper is not added to
client, the client will just use the
public subjects. By default it's not
added, which ensures backwards
compatibility and public subjects by
default. Note that with this approach, we
don't even need subject_type option on the
client.<br>
<br>
- The salt can be generated lazily at the
first time when mapper is used.<br>
<br>
- The validation can be done at the
moment, when protocolMapper is going to be
created/updated. Right now, we don't have
validation callback during protocolMapper
creation/update. However Bill is going to
add support for that into generic
componentModel. So if we're going to
refactor protocolMapper to use the new
generic component model, we will have
validation callback available to
protocolMapper SPI. The validation will
fail if array of redirect_uri from
sector_identifier_uri doesn't contain the
uris from redirect_uri of particular
client (including wildcards etc). <br>
<br>
- If client is updated and it's
redirect_uri are changed, we won't be able
to catch this, however this is not
strictly required per specs per my
understanding. At least the dynamic client
registration specs sais [1]<br>
<br>
"The values registered in <tt>redirect_uris</tt>
MUST be included in the elements of the
array, or registration MUST fail. This
MUST be validated at registration time;
there is no requirement for the OP to
retain the contents of this JSON file or
to retrieve or revalidate its contents in
the future. "<br>
<br>
[1] <a moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation"
target="_blank">http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation</a></div>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<div><br>
<br>
Marek</div>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<div><br>
<br>
On 22/08/16 15:50, Martin Hardselius
wrote:<br>
</div>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr">Ok, thanks for the
clarification.
<div><br>
</div>
<div>Where would it make sense to put
the PairwiseSubGeneratorSpi? Which
package, that is?</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Mon, 22 Aug 2016 at
14:51 Stian Thorgersen <<a
moz-do-not-send="true"
href="mailto:sthorger@redhat.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:sthorger@redhat.com">sthorger@redhat.com</a></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">
<div class="gmail_extra">
<div class="gmail_quote">On 22
August 2016 at 14:16, Martin
Hardselius <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:martin.hardselius@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:martin.hardselius@gmail.com">martin.hardselius@gmail.com</a></a>></span>
wrote:<br>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr"><span>
<div><span>"IMO it's
sufficient to document
the algorithm to
create the sub, which
should make it clear
that the origin in the
redirect uri will
affect the sub."</span><br>
</div>
<div><br>
</div>
</span></div>
</blockquote>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div dir="ltr">Reasonable.
:)</div>
<span>
<div dir="ltr">
<div><br>
</div>
<div><span>"One client
could also have
multiple redirect
uris with different
origins so could get
different sub's
generated depending
on the redirect uri
used."</span><br>
</div>
<div><br>
</div>
</div>
</span>
<div dir="ltr">
<div>That case is probably
caught by</div>
<div>[...] <span
style="font-size:small;font-family:verdana,charcoal,helvetica,arial,sans-serif">If
there are multiple
hostnames in the
registered<span> </span></span><tt>redirect_uris</tt><span
style="font-size:small;font-family:verdana,charcoal,helvetica,arial,sans-serif">,
the Client MUST
register a<span> </span></span><tt>sector_identifier_uri</tt><span
style="font-size:small;font-family:verdana,charcoal,helvetica,arial,sans-serif">. </span>[...]<br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Yes, but I meant from a
documentation perspective. It
should be clear from the
documentation that is the
case.</div>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Mon,
22 Aug 2016 at 10:42
Stian Thorgersen
<<a
moz-do-not-send="true"
href="mailto:sthorger@redhat.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:sthorger@redhat.com">sthorger@redhat.com</a></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">IMO
it's sufficient to
document the
algorithm to
create the sub,
which should make
it clear that the
origin in the
redirect uri will
affect the sub.
One client could
also have multiple
redirect uris with
different origins
so could get
different sub's
generated
depending on the
redirect uri
used. </div>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
22 August 2016
at 09:58, Martin
Hardselius <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:martin.hardselius@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:martin.hardselius@gmail.com">martin.hardselius@gmail.com</a></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">Sounds
fair enough.
<div><br>
</div>
<div>What
about the case
where you
don't provide
a
sector_identifier_uri,
set up a
single
redirect uri
on myhost and
then later go
on to change
that redirect
uri to
something on
myotherhost?
That would
change the
sector_identifier
and
subsequently
all the user
subs. Do we
protect
against such
"mistakes" or
do we warn
people (in the
docs and/or
admin gui)
that it's not
a good idea to
do that?</div>
</div>
<div>
<div><br>
<div
class="gmail_quote">
<div dir="ltr">On
Mon, 22 Aug
2016 at 09:38
Stian
Thorgersen
<<a
moz-do-not-send="true"
href="mailto:sthorger@redhat.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:sthorger@redhat.com">sthorger@redhat.com</a></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">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 moz-do-not-send="true"
href="https://www.mydomain.com/*"
target="_blank">https://www.mydomain.com/*</a><span
style="font-size:12.8px">, </span><a
moz-do-not-send="true" href="https://www.myotherdomain.com/*"
target="_blank"><a class="moz-txt-link-freetext" href="https://www.myotherdomain.com/*">https://www.myotherdomain.com/*</a></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
moz-do-not-send="true"
href="https://www.myotherdomain.com/myapp" target="_blank"><a class="moz-txt-link-freetext" href="https://www.myotherdomain.com/myapp">https://www.myotherdomain.com/myapp</a></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
moz-do-not-send="true" href="mailto:martin.hardselius@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:martin.hardselius@gmail.com">martin.hardselius@gmail.com</a></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>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>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>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>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>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
moz-do-not-send="true"
href="https://www.mydomain.com/*" target="_blank"><a class="moz-txt-link-freetext" href="https://www.mydomain.com/*">https://www.mydomain.com/*</a></a> ].
The
sector_identifier
would be
mydomain.</div>
<div><br>
</div>
<div>Later on,
I update the
redirect_uris
to [<span> </span><a
moz-do-not-send="true" href="https://www.mydomain.com/*" target="_blank"><a class="moz-txt-link-freetext" href="https://www.mydomain.com/*">https://www.mydomain.com/*</a></a>,
<a
moz-do-not-send="true"
href="https://www.myotherdomain.com/*" target="_blank"><a class="moz-txt-link-freetext" href="https://www.myotherdomain.com/*">https://www.myotherdomain.com/*</a></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>
<div><br>
<div
class="gmail_quote">
<div dir="ltr">On
Thu, 18 Aug
2016 at 10:45
Stian
Thorgersen
<<a
moz-do-not-send="true"
href="mailto:sthorger@redhat.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:sthorger@redhat.com">sthorger@redhat.com</a></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
moz-do-not-send="true" href="mailto:martin.hardselius@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:martin.hardselius@gmail.com">martin.hardselius@gmail.com</a></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
moz-do-not-send="true"
href="mailto:martin.hardselius@gmail.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:martin.hardselius@gmail.com">martin.hardselius@gmail.com</a></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
moz-do-not-send="true"
href="mailto:mposolda@redhat.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:mposolda@redhat.com">mposolda@redhat.com</a></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
moz-do-not-send="true"
href="https://issues.jboss.org/browse/KEYCLOAK-3422"
target="_blank"><a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/KEYCLOAK-3422">https://issues.jboss.org/browse/KEYCLOAK-3422</a></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.getRemoteUser()"
it will return
"john" instead
of
"123456-unique-johns-uuid"
. See <a
moz-do-not-send="true"
href="https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html"
target="_blank"><a class="moz-txt-link-freetext" href="https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html">https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html</a></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
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes"
target="_blank"><a class="moz-txt-link-freetext" href="http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes">http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes</a></a><br>
<div><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg"
target="_blank"><a class="moz-txt-link-freetext" href="http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg">http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg</a></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 moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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
moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a></a><br>
<a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
target="_blank"><a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>