<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">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 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">"http://evil-host/url1"</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">https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UserFederationProviderResource.java#L437-L440</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"><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>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">https://www.myotherdomain.com/*</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>