<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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 class="moz-txt-link-freetext" href="http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation">http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation</a><br>
<br>
Marek<br>
<br>
On 22/08/16 15:50, Martin Hardselius wrote:<br>
</div>
<blockquote
cite="mid:CAPJq0L8+eohJDyYEWj+KeaLEkDw148EVxgn7CBZ4eTHUwbagaw@mail.gmail.com"
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">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
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
style="color:rgb(33,33,33);font-family:"helvetica
neue",helvetica,arial,sans-serif">"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
style="color:rgb(33,33,33);font-family:"helvetica
neue",helvetica,arial,sans-serif">"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
style="font-size:small;color:rgb(0,51,102);font-family:"courier
new",courier,monospace">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
style="font-size:small;color:rgb(0,51,102);font-family:"courier
new",courier,monospace">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">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">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/*"
style="font-size:12.8px"
target="_blank"><a class="moz-txt-link-freetext" href="https://www.mydomain.com/*">https://www.mydomain.com/*</a></a><span
style="font-size:12.8px">, </span><a
moz-do-not-send="true"
href="https://www.myotherdomain.com/*"
style="font-size:12.8px"
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
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
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"
rel="noreferrer"
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>
</body>
</html>