<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 href="mailto:mposolda@redhat.com">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>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 href="mailto:mposolda@redhat.com" target="_blank"><a href="mailto:mposolda@redhat.com" target="_blank">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>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 href="http://good-host/url1" target="_blank">"http://good-host/url1"</a>
<a 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 href="http://evil-host/url1" target="_blank"><a href="http://evil-host/url1" target="_blank">"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 href="https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/protocol/AbstractLoginProtocolFactory.java#L39" target="_blank">https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/protocol/AbstractLoginProtocolFactory.java#L39</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 href="https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UserFederationProviderResource.java#L437-L440" target="_blank"><a href="https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UserFederationProviderResource.java#L437-L440" target="_blank">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 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 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 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">
<div class="gmail_extra">
<div class="gmail_quote">On 22 August 2016
at 14:16, Martin Hardselius <span dir="ltr"><<a href="mailto:martin.hardselius@gmail.com" target="_blank"><a href="mailto:martin.hardselius@gmail.com" target="_blank">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 href="mailto:sthorger@redhat.com" target="_blank"><a href="mailto:sthorger@redhat.com" target="_blank">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 href="mailto:martin.hardselius@gmail.com" target="_blank"><a href="mailto:martin.hardselius@gmail.com" target="_blank">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 href="mailto:sthorger@redhat.com" target="_blank"><a href="mailto:sthorger@redhat.com" target="_blank">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 href="https://www.mydomain.com/*" target="_blank">https://www.mydomain.com/*</a><span style="font-size:12.8px">, </span><a href="https://www.myotherdomain.com/*" target="_blank"><a href="https://www.myotherdomain.com/*" target="_blank">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 href="https://www.myotherdomain.com/myapp" target="_blank"><a href="https://www.myotherdomain.com/myapp" target="_blank">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 href="mailto:martin.hardselius@gmail.com" target="_blank"><a href="mailto:martin.hardselius@gmail.com" target="_blank">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 href="https://www.mydomain.com/*" target="_blank"><a href="https://www.mydomain.com/*" target="_blank">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 href="https://www.mydomain.com/*" target="_blank"><a href="https://www.mydomain.com/*" target="_blank">https://www.mydomain.com/*</a></a>,
<a href="https://www.myotherdomain.com/*" target="_blank"><a href="https://www.myotherdomain.com/*" target="_blank">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 href="mailto:sthorger@redhat.com" target="_blank"><a href="mailto:sthorger@redhat.com" target="_blank">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 href="mailto:martin.hardselius@gmail.com" target="_blank"><a href="mailto:martin.hardselius@gmail.com" target="_blank">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 href="mailto:martin.hardselius@gmail.com" target="_blank"><a href="mailto:martin.hardselius@gmail.com" target="_blank">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 href="mailto:mposolda@redhat.com" target="_blank"><a href="mailto:mposolda@redhat.com" target="_blank">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 href="https://issues.jboss.org/browse/KEYCLOAK-3422" target="_blank"><a href="https://issues.jboss.org/browse/KEYCLOAK-3422" target="_blank">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 href="https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.1/topics/oidc/java/java-adapter-config.html" target="_blank"><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></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"><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></a><br>
<div><a href="http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg" target="_blank"><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></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"><a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a></a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank"><a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">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>