<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 29.10.2015 09:05, Marek Posolda
wrote:<br>
</div>
<blockquote cite="mid:5631D355.6000402@redhat.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 28/10/15 23:44, Scott Rossillo
wrote:<br>
</div>
<blockquote
cite="mid:27E56C7A-FAEC-4114-AA48-5D79EEF374AB@smartling.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
It’s important to allow for account linking without a manual
step if the trust email is true. I’m not against optionally
forcing the user to link accounts. However, if the user never
confirms they want to link, I’d want to identity broker account
to never be created.
<div class=""><br class="">
</div>
<div class="">Hope that makes sense. I know there are a lot of
use cases you’re considering here but I’d rather not have to
write code to maintain automatic account linking (with or
without a verification step)<br>
</div>
</blockquote>
<blockquote
cite="mid:27E56C7A-FAEC-4114-AA48-5D79EEF374AB@smartling.com"
type="cite">
<div class=""><br class="">
</div>
<div class="">Also, if user <a moz-do-not-send="true"
href="mailto:me@gmail.com" class="">me@gmail.com</a> is
registered in Keycloak and then uses Google+ authentication,
it would be silly to make the user confirm they want the
accounts linked.</div>
</blockquote>
<br>
With the authentication flows, it's possible to do things very
flexible. However the question is what should be the default
behaviour. I think we will have the possibility to "autolink"
without additional verification/reauthentication, but it won't be
likely enabled by default. As Stian mentioned, there is some
security impact with autolinking even for trusted providers like
Google.<br>
</blockquote>
<br>
+1000 for flexibility but sane and secure defaults.<br>
<br>
Vl<br>
<br>
<blockquote cite="mid:5631D355.6000402@redhat.com" type="cite"> <br>
Marek<br>
<blockquote
cite="mid:27E56C7A-FAEC-4114-AA48-5D79EEF374AB@smartling.com"
type="cite">
<div class="">
<div class=""><br class="">
<div apple-content-edited="true" class="">
<div class="">Scott Rossillo</div>
<div class="">Smartling | Senior Software Engineer</div>
<div class=""><a moz-do-not-send="true"
href="mailto:srossillo@smartling.com" class="">srossillo@smartling.com</a></div>
<div class=""><br class="">
</div>
<div class=""><span style="color: rgb(169, 169, 169);
font-family: gesta, Arial, Helvetica, sans-serif;
font-size: 14px; line-height: 20px; widows: 1;
background-color: rgb(255, 255, 255);" class=""></span>
<div id="watermark" style="box-sizing: border-box;
color: rgb(169, 169, 169); font-family: gesta, Arial,
Helvetica, sans-serif; font-size: 14px; line-height:
20px; widows: 1; background-color: rgb(255, 255,
255);" class=""><a moz-do-not-send="true"
href="http://www.sigstr.com/" style="box-sizing:
border-box; color: rgb(0, 124, 194);
text-decoration: none; background-color:
transparent; outline: 0px !important;" class=""><img
moz-do-not-send="true" alt="Powered by Sigstr"
src="https://app.sigstr.com/uc/55e5d41c6533390d03580000/watermark"
style="box-sizing: border-box; border: 0px;
vertical-align: top; max-width: 100%; height:
auto; width: inherit; color: rgb(99, 99, 99);
font-family: Helvetica; font-size: 11px;" class=""
border="0"></a></div>
</div>
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Oct 28, 2015, at 4:32 PM, Bill Burke
<<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:bburke@redhat.com">bburke@redhat.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">If a user has loads of social networks
and links a bunch of them, if <br class="">
*any one* of them is compromised the entire account
is compromised. <br class="">
Most sites using social login, the only reason is
there is a login is <br class="">
for the appliation to collect marketing data. So,
the default behavior <br class="">
should make things as simple as possible for the
user.<br class="">
<br class="">
At a minimum, by default, the user should not be
required to link an <br class="">
account if there is a conflicting duplicate email
given by the provider. <br class="">
I have found <a moz-do-not-send="true"
href="http://develoeprs.redhat.com" class="">develoeprs.redhat.com</a>
very difficult to use.<br class="">
<br class="">
<br class="">
<br class="">
On 10/28/2015 12:34 PM, Scott Rehorn wrote:<br
class="">
<blockquote type="cite" class="">I agree with Stian
here – the process to normalize a collection of<br
class="">
logins requires human-interaction nuance that
should not be automated. I<br class="">
think Keycloak can provide a nice user experience
to aid the process,<br class="">
but it should always be an interactive process
with plenty of<br class="">
re-authentication challenges to make sure an
individual still retains<br class="">
ownership of the various candidate linked
accounts.<br class="">
<br class="">
From: <<a moz-do-not-send="true"
href="mailto:keycloak-dev-bounces@lists.jboss.org"
class="">keycloak-dev-bounces@lists.jboss.org</a><br
class="">
<<a moz-do-not-send="true"
href="mailto:keycloak-dev-bounces@lists.jboss.org"
class="">mailto:keycloak-dev-bounces@lists.jboss.org</a>>>
on behalf of Stian<br class="">
Thorgersen <<a moz-do-not-send="true"
href="mailto:sthorger@redhat.com" class="">sthorger@redhat.com</a>
<<a moz-do-not-send="true"
href="mailto:sthorger@redhat.com" class="">mailto:sthorger@redhat.com</a>>><br
class="">
Reply-To: "<a moz-do-not-send="true"
href="mailto:stian@redhat.com" class="">stian@redhat.com</a>
<<a moz-do-not-send="true"
href="mailto:stian@redhat.com" class="">mailto:stian@redhat.com</a>>"
<<a moz-do-not-send="true"
href="mailto:stian@redhat.com" class="">stian@redhat.com</a><br
class="">
<<a moz-do-not-send="true"
href="mailto:stian@redhat.com" class="">mailto:stian@redhat.com</a>>><br
class="">
Date: Wednesday, October 28, 2015 at 8:06 AM<br
class="">
To: Marek Posolda <<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" class="">mposolda@redhat.com</a>
<<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" class="">mailto:mposolda@redhat.com</a>>><br
class="">
Cc: keycloak-dev <<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org"
class="">keycloak-dev@lists.jboss.org</a><br
class="">
<<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org"
class="">mailto:keycloak-dev@lists.jboss.org</a>>><br
class="">
Subject: Re: [keycloak-dev] Plan for "First login
with identity brokers"<br class="">
<br class="">
I'm quite concerned about auto linking accounts.
If someone has loads of<br class="">
social networks enabled and a user has a single of
those compromised<br class="">
(that happens quite frequently) the attackers
would then also be able to<br class="">
gain access to whatever Keycloak secures. The user
wouldn't even know<br class="">
they have access to Keycloak, since the user has
never used to<br class="">
compromised account to login to Keycloak.<br
class="">
<br class="">
I strongly feel we should never link to any
account without requiring<br class="">
user to first authenticate to the account we are
linking with.<br class="">
<br class="">
On 27 October 2015 at 08:04, Marek Posolda <<a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:mposolda@redhat.com"><a class="moz-txt-link-abbreviated" href="mailto:mposolda@redhat.com">mposolda@redhat.com</a></a><br
class="">
<<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" class="">mailto:mposolda@redhat.com</a>>>
wrote:<br class="">
<br class="">
On 27/10/15 14:05, Bill Burke wrote:<br
class="">
<blockquote type="cite" class="">IMO, most
applications will not care about account
duplication. Most<br class="">
users won't care about account linking. So,
IMO:<br class="">
</blockquote>
Remember you mentioned that already in the
previous discussions. IMO<br class="">
people care and usually want to have single
account on single site. If<br class="">
you have 2 accounts, you never know to which of
your accounts you are<br class="">
authenticated. This causes various issues, like
permissions available to<br class="">
account1, but you are logged with account2 etc.<br
class="">
<br class="">
Remember some time ago I messed on some site
and have 2 accounts like<br class="">
"mposolda" and "<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" class="">mposolda@redhat.com</a>
<<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" class="">mailto:mposolda@redhat.com</a>>"
.<br class="">
I had always issues like that<br class="">
when I was logged as "mposolda" I had "Access
denied" when going to page<br class="">
I was supposed to have permission. So needed to
logout and login again<br class="">
as "<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" class="">mposolda@redhat.com</a>
<<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" class="">mailto:mposolda@redhat.com</a>>"
etc.<br class="">
<blockquote type="cite" class=""><br class="">
1) users should not be required to link
accounts. In the case where an<br class="">
account cannot be automatically linked a
duplicate account should be<br class="">
created<br class="">
2) Providers should be trusted by default.
Trusted providers can just<br class="">
automatically link themselves to existing
accounts that were logged in<br class="">
by other trusted providers.<br class="">
3) Untrusted providers can automatically link if
email has been verified<br class="">
for all parties.<br class="">
4) Users can merge accounts that have verified
emails.<br class="">
5) An alternative to user self merging of
account could be requiring to<br class="">
enter in a temporary code after logging into
each account.<br class="">
<br class="">
<br class="">
#1 and #2 can be added with minimal changes to
code. #3 requires a flow<br class="">
on broker login and a rework of the broker SPI.
#4 is account service<br class="">
changes. #5 might be as easy as adding a
required action.<br class="">
<br class="">
I guess it depends if ultimate flexibility is
needed. #1, #2 and #4<br class="">
might be enough and require the least amount of
changes and SPI refactoring.<br class="">
</blockquote>
I think that flexibility is needed based on
various JIRAs and feedback.<br class="">
Just talked with Vlasta Elias from <a
moz-do-not-send="true" href="http://jboss.org"
class="">jboss.org</a> <<a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://jboss.org"><a class="moz-txt-link-freetext" href="http://jboss.org">http://jboss.org</a></a>>.<br
class="">
They have even more<br class="">
requirements for possible conditions when
accounts should be merged and<br class="">
how to merge accounts. For example Vlasta
mentioned the usecase like:<br class="">
- When user logges with Facebook (or other
provider) account, which is<br class="">
not yet linked to any Keycloak account, then
new account on Keycloak<br class="">
side shouldn't be created automatically. Even
if I logged with Facebook<br class="">
<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">bob@gmail.com</a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>
and there is no KC account for<br class="">
email <a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">bob@gmail.com</a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>,
there<br class="">
is requirement to always show the screen like:
"You just logged with<br class="">
facebook account <a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">bob@gmail.com</a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>.
Do you want<br class="">
to link it with existing<br class="">
keycloak account?" If user agree, he would need
to provide Keycloak<br class="">
account he wants to merge and then verify email
or re-authenticate to<br class="">
link Facebook with existing account<br class="">
<br class="">
- Another use-case was to merge account
automatically based on username<br class="">
from thirdparty SAML provider. For example the
SAMLResponse with<br class="">
username "john" returned from SAML provider,
there is a need to<br class="">
automatically merge it with Keycloak account
"john" . In this case, they<br class="">
know that "john" will be always available on
Keycloak side because of<br class="">
Federation provider, which SAML IDP uses as
storage as well.<br class="">
<br class="">
Based on all of this, it looks that introducing
Auth SPI for first time<br class="">
broker login is a way to go. This will address
all of #1, #2 and #3 and<br class="">
many other usecases.<br class="">
<br class="">
For your #2, I agree that providers should be
trusted by default. But<br class="">
not all of providers, because some of them
don't verify email. AFAIK<br class="">
Facebook and Google verify email. But Github
doesn't . It will be a<br class="">
security hole to trust github provider by
default because then user can<br class="">
do something like:<br class="">
- He can create github account with any email
he wants like<br class="">
"<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" class="">mposolda@redhat.com</a>
<<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" class="">mailto:mposolda@redhat.com</a>>"<br
class="">
- Login with this github account into Keycloak.
If we trust the email by<br class="">
default, he will be logged into Keycloak to
account<br class="">
"<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" class="">mposolda@redhat.com</a>
<<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" class="">mailto:mposolda@redhat.com</a>>",
which is not his<br class="">
email -> FAIL<br class="">
<br class="">
I am not sure about support for merging
accounts in Account management<br class="">
(like #4 and #5), will try to work on login
flow first and will try to<br class="">
possibly look at account management then.<br
class="">
<br class="">
Marek<br class="">
<blockquote type="cite" class=""><br class="">
<br class="">
On 10/27/2015 4:33 AM, Marek Posolda wrote:<br
class="">
<blockquote type="cite" class="">I went again
through all the previous discussions, related
JIRAs and<br class="">
requirements. As of now, my plan is to:<br
class="">
<br class="">
- Use authentication SPI to handle the flow
and related actions for<br class="">
first social login. (Update user profile,
Detect duplicated account,<br class="">
Verify email or reauthenticate user if
duplication is detected, Create<br class="">
social link to existing account). This allows
most flexibility for<br class="">
admins to specify how exactly the linking
should work<br class="">
<br class="">
- Detecting duplication will be based on email
only by default - (For<br class="">
example duplication is detected if Facebook
user with email<br class="">
<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">bob@gmail.com</a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>
authenticates, but there is<br class="">
</blockquote>
</blockquote>
already Keycloak user with<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:emailbob@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:emailbob@gmail.com">emailbob@gmail.com</a></a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>
). The people can provide their<br class="">
</blockquote>
</blockquote>
own execution if<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">they want
different way for detect duplications<br
class="">
<br class="">
- It seems it's more proper to postpone
creating user account later,<br class="">
once we know that there is no duplication. In
other words, if "Update<br class="">
profile on first login" is enabled, the user
account is not yet created<br class="">
when the update profile page is shown. All the
info related to<br class="">
BrokeredIdentityContext stuff will be
available on ClientSession. This<br class="">
seems to me easier and more proper solution
then creating temporary<br class="">
account with email in some "temporary"
attribute. Temporary accounts<br class="">
have other challenges (Cleaner thread for
delete outdated unmerged<br class="">
accounts etc).<br class="">
<br class="">
- If "trustEmail" flag is on for
IdentityProvider, the provider link<br
class="">
will be created automatically. (For example if
Facebook user<br class="">
<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">bob@gmail.com</a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>
authenticates for the first<br class="">
</blockquote>
</blockquote>
time and there is already<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">Keycloak user
with <a moz-do-not-send="true"
href="mailto:emailbob@gmail.com" class="">emailbob@gmail.com</a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>
and trustEmail is on, the<br class="">
Facebook link is automatically created for
Keycloak account<br class="">
<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">bob@gmail.com</a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>
without any additional<br class="">
</blockquote>
</blockquote>
verification)<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class=""><br class="">
- If "trustEmail" flag is off, there would
need to be other way to<br class="">
verify user before creating social link. The
user will first confirm if<br class="">
he wants to merge the accounts. Then there
will be either:<br class="">
-- Email verification: The mail will be sent <a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:tobob@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:tobob@gmail.com">tobob@gmail.com</a></a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>
like<br class="">
"Someone authenticates to Keycloak <a
moz-do-not-send="true"
href="serverhttp://www.keycloak.org:8080"
class="">serverhttp://www.keycloak.org:8080</a><br
class="">
through Facebook <a moz-do-not-send="true"
href="mailto:accountbob@gmail.com" class="">accountbob@gmail.com</a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>
and wants to link Facebook<br class="">
account with existing Keycloak <a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:accountbob@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:accountbob@gmail.com">accountbob@gmail.com</a></a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>
. If it is you,<br class="">
click here" . After user clicks, the social
link is created<br class="">
-- Further authentication: User will need to
authenticate to existing<br class="">
<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">bob@gmail.com</a>
<<a moz-do-not-send="true"
href="mailto:bob@gmail.com" class="">mailto:bob@gmail.com</a>>
keycloak account through<br class="">
</blockquote>
</blockquote>
password (or OTP or both or<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">realms/rhd/login-actions/email-verification?code=KYxAcXLs140rGN8CwQFtQssOj2es7aZBa6DrbbdGHng.822f5fb1-e05b-4e17-bb90-e6bbb8fba68esomething
else)<br class="">
All of this is configurable through flows, so
admin can disable the "Do<br class="">
you want to create social link?" screen, or
enforce email verification<br class="">
instead of authentication, configure required
authenticators etc.<br class="">
<br class="">
- I am not sure if we want to handle just
merge with existing account<br class="">
during first broker login, or if we also want
to handle merging of<br class="">
accounts in account management? For now, I am
planning to handle just<br class="">
the login flow and possibly address Account
management later if there is<br class="">
need for it. The merging accounts in account
management might be quite a<br class="">
challenge as there is merge of 2 already
existing user accounts with<br class="">
various issues related to it (Which
roles/permissions should merged<br class="">
account have? Which attributes it should have?
Which federation link?<br class="">
etc.). But at least, I am planning to address
the issue with redirect to<br class="">
login forms error screen instead of stay in
account management -<br class="">
<a moz-do-not-send="true"
href="https://issues.jboss.org/browse/KEYCLOAK-1822"
class="">https://issues.jboss.org/browse/KEYCLOAK-1822</a><br
class="">
<br class="">
Marek<br class="">
_______________________________________________<br class="">
keycloak-dev mailing list<br class="">
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:keycloak-dev@lists.jboss.org"><mailto:keycloak-dev@lists.jboss.org></a><br
class="">
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br
class="">
<br class="">
</blockquote>
</blockquote>
<br class="">
_______________________________________________<br
class="">
keycloak-dev mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org"
class="">keycloak-dev@lists.jboss.org</a> <<a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="mailto:keycloak-dev@lists.jboss.org"><a class="moz-txt-link-freetext" href="mailto:keycloak-dev@lists.jboss.org">mailto:keycloak-dev@lists.jboss.org</a></a>><br
class="">
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
class="">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br
class="">
<br class="">
<br class="">
<br class="">
<br class="">
_______________________________________________<br
class="">
keycloak-dev mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org"
class="">keycloak-dev@lists.jboss.org</a><br
class="">
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br
class="">
<br class="">
</blockquote>
<br class="">
-- <br class="">
Bill Burke<br class="">
JBoss, a division of Red Hat<br class="">
<a moz-do-not-send="true"
href="http://bill.burkecentral.com" class="">http://bill.burkecentral.com</a><br
class="">
_______________________________________________<br
class="">
keycloak-dev mailing list<br class="">
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br
class="">
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team</pre>
</body>
</html>