<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 30 June 2016 at 08:08, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What I suggested was based on what I saw at our current proposal:<br>
<br>
$ kcreg login -r master -u manage-client<br>
Server to connect to (<a href="http://localhost:8080/auth" rel="noreferrer" target="_blank">http://localhost:8080/auth</a>):<br>
Password:<br>
<br>
If you want to automate it for example in a shell script, unless I'm<br>
mistaken, you have to provide user's password or obtain initial access<br>
token through console. If we're assuming that's the default<br>
flow for automated scripts should be obtaining an initial access token<br>
from console first, that's fine.<br></blockquote><div><br></div><div>Yes, the password is just for manual use and wouldn't be cached or anything like that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Flow for encryption:<br>
<br>
1. Admin client retrieve the public key from the server<br>
2. Admin client encrypt's whatever data is sensitive<br>
3. Server decrypt's it<br></blockquote><div><br></div><div>Isn't that only going to hide the password? The encrypted password could still be used as the server would accept/decrypt it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
On 2016-06-30, Stian Thorgersen wrote:<br>
> I can't see why we should consider it though:<br>
><br>
> a) We have service account support, initial access tokens, offline tokens,<br>
> etc.. All designed so credentials don't need to be stored. Using a user<br>
> account directly is horrible as not only are you potentially exposing the<br>
> credentials, you're also giving all permissions of the user to the<br>
> automation. Using tokens or service account you can limit what permissions<br>
> the automation has.<br>
> b) If the credentials are encrypted, you'll also need to unlock the<br>
> vault/encrypted file. How would you suggest we do that? I can't see the<br>
> full flow here.<br>
><br>
> On 30 June 2016 at 07:15, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
><br>
> > Yes, the encrypted data goes into public repository with .travis.yaml file.<br>
> > Only the Travis server is able to decrypt such data and validate it[1][2].<br>
> ><br>
> > Like I mentioned, not a blocker, but maybe something to take into<br>
> > consideration.<br>
> ><br>
> > [1] -<br>
> > <a href="https://docs.travis-ci.com/user/encryption-keys/#Notifications-Example" rel="noreferrer" target="_blank">https://docs.travis-ci.com/user/encryption-keys/#Notifications-Example</a><br>
> > [2] - <a href="https://github.com/twbs/bootstrap/blob/master/.travis.yml#L30-L32" rel="noreferrer" target="_blank">https://github.com/twbs/bootstrap/blob/master/.travis.yml#L30-L32</a><br>
> ><br>
> > On 2016-06-30, Stian Thorgersen wrote:<br>
> > > The encryption support in Travis isn't that so you can encrypt sensitive<br>
> > > details that goes into .travis.yaml which is public through the repo?<br>
> > ><br>
> > > On 30 June 2016 at 06:52, Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>> wrote:<br>
> > ><br>
> > > > I don't see the need for that. For the client registration CLI we will<br>
> > > > support initial access tokens as well as service accounts with<br>
> > pub/priv key<br>
> > > > authentication. For admin cli we'll support service accounts. No one<br>
> > should<br>
> > > > be using username/password combined with automated jobs.<br>
> > > ><br>
> > > > On 29 June 2016 at 21:49, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
> > > ><br>
> > > >> I'm not sure if it's part of the scope for now. But<br>
> > > >> thinking about situations where you have to automate jobs plus provide<br>
> > > >> credentials without exposing them.<br>
> > > >><br>
> > > >> My suggestion, even if it's not part of the scope for now is to<br>
> > encrypt<br>
> > > >> it,<br>
> > > >> like travis does[1]. I know that our plan is to deal of access token,<br>
> > > >> but would be nice to not expose credentials not even a single time.<br>
> > > >><br>
> > > >><br>
> > > >> [1] - <a href="https://docs.travis-ci.com/user/encryption-keys/" rel="noreferrer" target="_blank">https://docs.travis-ci.com/user/encryption-keys/</a><br>
> > > >><br>
> > > >> On 2016-06-29, Stian Thorgersen wrote:<br>
> > > >> > On 28 June 2016 at 11:40, Marko Strukelj <<a href="mailto:mstrukel@redhat.com">mstrukel@redhat.com</a>><br>
> > wrote:<br>
> > > >> ><br>
> > > >> > ><br>
> > > >> > ><br>
> > > >> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <<br>
> > > >> <a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>><br>
> > > >> > > wrote:<br>
> > > >> > ><br>
> > > >> > >><br>
> > > >> > >><br>
> > > >> > >> On 27 June 2016 at 21:26, John Dennis <<a href="mailto:jdennis@redhat.com">jdennis@redhat.com</a>><br>
> > wrote:<br>
> > > >> > >><br>
> > > >> > >>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:<br>
> > > >> > >>> > I've started work on Client Registration CLI tool. As a first<br>
> > > >> step,<br>
> > > >> > >>> here<br>
> > > >> > >>> > is a design document describing how I imagine the tool would<br>
> > be<br>
> > > >> used.<br>
> > > >> > >>> ><br>
> > > >> > >>> ><br>
> > > >> > >>> ><br>
> > > >> > >>><br>
> > > >><br>
> > <a href="https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing</a><br>
> > > >> > >>> ><br>
> > > >> > >>> ><br>
> > > >> > >>> > I'll use this document as a spec / guide as I implement the<br>
> > client<br>
> > > >> > >>> tool.<br>
> > > >> > >>> ><br>
> > > >> > >>> > Within days I'll also send a link to initial ideas for Admin<br>
> > > >> Client<br>
> > > >> > >>> tool<br>
> > > >> > >>> > which in principle should allow administrator to configure<br>
> > > >> everything<br>
> > > >> > >>> > that can otherwise be done through Admin Console.<br>
> > > >> > >>> ><br>
> > > >> > >>> > Any feedback welcome.<br>
> > > >> > >>><br>
> > > >> > >>> FWIW we've already written a client registration tool for<br>
> > Keycloak.<br>
> > > >> At<br>
> > > >> > >>> the moment it is specifically targeted for SAML clients (SP,<br>
> > Service<br>
> > > >> > >>> Provider) in Apache HTTPD but we have plans to extend it to<br>
> > OIDC.<br>
> > > >> > >>><br>
> > > >> > >>> It is currently in Fedora and will also ship in OSP.<br>
> > > >> > >>><br>
> > > >> > >>> It is hosted here:<br>
> > > >> > >>> <a href="https://github.com/jdennis/keycloak-httpd-client-install" rel="noreferrer" target="_blank">https://github.com/jdennis/keycloak-httpd-client-install</a><br>
> > > >> > >>><br>
> > > >> > >>> The man page for it (formatted for HTML) can be found here:<br>
> > > >> > >>><br>
> > > >><br>
> > <a href="https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html" rel="noreferrer" target="_blank">https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html</a><br>
> > > >> > >>><br>
> > > >> > >>> The man page discusses 3 different ways you can authenticate<br>
> > and 2<br>
> > > >> > >>> different ways client registration can be performed.<br>
> > > >> > >>><br>
> > > >> > >>> I have a lot of experience with Keycloak client registration<br>
> > tools<br>
> > > >> and<br>
> > > >> > >>> have worked through many issues, I'm happy to share my<br>
> > experience.<br>
> > > >> > >>><br>
> > > >> > >>> Here are some thoughts/issues you may want to take into account:<br>
> > > >> > >>><br>
> > > >> > >>> * The tool must be capable of running without interactivity as<br>
> > part<br>
> > > >> of a<br>
> > > >> > >>> scripted installation task.<br>
> > > >> > >>><br>
> > > >> > >>> * It should not depend on a home directory being available.<br>
> > > >> > >>><br>
> > > >> > >>> * If a home directory is utilized how will you disambiguate any<br>
> > > >> stored<br>
> > > >> > >>> state belonging to a script that is run by different processes<br>
> > but<br>
> > > >> under<br>
> > > >> > >>> the same user (possibly simultaneously)? To clarify, many<br>
> > install<br>
> > > >> tools<br>
> > > >> > >>> run as the root user or some other admin user. Each invocation<br>
> > of<br>
> > > >> these<br>
> > > >> > >>> install tools can be run with entirely different parameters and<br>
> > may<br>
> > > >> > >>> execute either in parallel or partially overlapping in time.<br>
> > > >> > >>><br>
> > > >> > >><br>
> > > >> > > Maybe I should have included this link in the design document to<br>
> > make<br>
> > > >> it<br>
> > > >> > > clear to everyone what Client Registration this tool is for:<br>
> > > >> > ><br>
> > > >><br>
> > <a href="http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html" rel="noreferrer" target="_blank">http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html</a><br>
> > > >> > ><br>
> > > >> > > It's a REST API defined by specs, and is separate from Admin REST<br>
> > API.<br>
> > > >> > ><br>
> > > >> > > About using home directory, the way I see it - you either a)<br>
> > specify<br>
> > > >> all<br>
> > > >> > > the state when executing a command, or b) you have a mechanism<br>
> > that<br>
> > > >> allows<br>
> > > >> > > the concept of 'session' between command invocations.<br>
> > > >> > ><br>
> > > >> > > If you use the first approach (a) then on each invocation of the<br>
> > > >> command<br>
> > > >> > > you have to specify either username:password, or a token. The<br>
> > client<br>
> > > >> > > registration specification defines workflow for Initial Access<br>
> > > >> Tokens, and<br>
> > > >> > > Registration Access Tokens, which require to automatically<br>
> > intercept a<br>
> > > >> > > newly issued token after each CRUD operation, and save it for any<br>
> > > >> > > subsequent operation on the same client resource. I can't see how<br>
> > this<br>
> > > >> > > could be achieved by using the first approach.<br>
> > > >> > ><br>
> > > >> > > For the second approach (b) you need a way to communicate<br>
> > 'session'<br>
> > > >> state.<br>
> > > >> > > The state we are saving are just tokens associated with current<br>
> > user<br>
> > > >> or<br>
> > > >> > > specific clients, or specific grants. Looks to me that if multiple<br>
> > > >> parallel<br>
> > > >> > > sessions are in collision about these tokens then the cli tool<br>
> > itself<br>
> > > >> might<br>
> > > >> > > be used the wrong way. Namely, once the client authenticates with<br>
> > a<br>
> > > >> login,<br>
> > > >> > > access token and refresh token are cached. Multiple client<br>
> > instances<br>
> > > >> can<br>
> > > >> > > use the same access token, and the same refresh token. A thing to<br>
> > > >> maybe be<br>
> > > >> > > careful about is just properly locking the file when making<br>
> > changes<br>
> > > >> to it.<br>
> > > >> > > For initial access token you have to explicitly add it, and<br>
> > assign it<br>
> > > >> an<br>
> > > >> > > alias - you can use any random value there if you want. For<br>
> > > >> registration<br>
> > > >> > > access token they are automatically associated with initial token<br>
> > > >> they were<br>
> > > >> > > initiated from - again there should be no collision.<br>
> > > >> > ><br>
> > > >> ><br>
> > > >> > I like the option to have two approaches as there are two use-cases.<br>
> > > >> One is<br>
> > > >> > manually registering for example during development or when manually<br>
> > > >> > configuring an application to use Keycloak. Another is scripted.<br>
> > Even<br>
> > > >> for<br>
> > > >> > scripted you may quite likely want to just add service account<br>
> > > >> credentials<br>
> > > >> > or initial access token directly to ~/.keycloak/ rather than pass<br>
> > these<br>
> > > >> to<br>
> > > >> > the commands.<br>
> > > >> ><br>
> > > >> > Registration access tokens are associated with a client, not an<br>
> > initial<br>
> > > >> > access token. Also, remember the registration access token is<br>
> > changed on<br>
> > > >> > updates.<br>
> > > >> ><br>
> > > >> ><br>
> > > >> > ><br>
> > > >> > > What alternative mechanism would you suggest for storing 'session'<br>
> > > >> info?<br>
> > > >> > > We want to support Windows as well so it can't be Unix / Bash<br>
> > > >> specific.<br>
> > > >> > ><br>
> > > >> > ><br>
> > > >> > ><br>
> > > >> > >><br>
> > > >> > >>> * The tool should be idempotent.<br>
> > > >> > >>><br>
> > > >> > >>> * You suggest storing tokens in a cache, how do you plan on<br>
> > > >> handling the<br>
> > > >> > >>> case where a token expires before all operations are complete?<br>
> > > >> > >>><br>
> > > >> > >>> * We also initially took the approach of caching tokens but<br>
> > > >> discovered<br>
> > > >> > >>> the complexity did not justify the minimal cost of obtaining a<br>
> > new<br>
> > > >> token<br>
> > > >> > >>> for each invocation. This greatly simplified the code with very<br>
> > > >> little<br>
> > > >> > >>> performance impact.<br>
> > > >> > >>><br>
> > > >> > >>> * You do not mention what type of client you're registering. I'm<br>
> > > >> > >>> assuming it's OpenID but SAML clients (SP) are equally<br>
> > important.<br>
> > > >> The<br>
> > > >> > >>> tool must be able to handle both.<br>
> > > >> > >>><br>
> > > >> > >><br>
> > > >> > >> Marko is probably referring to the Keycloak client<br>
> > representation,<br>
> > > >> which<br>
> > > >> > >> can be either OpenID or SAML. However, we also need to support<br>
> > OpenID<br>
> > > >> > >> Connect client descriptions as well as SAML entity descriptors as<br>
> > > >> both are<br>
> > > >> > >> supported by client reg services.<br>
> > > >> > >><br>
> > > >> > ><br>
> > > >> > > The CLI needs to know which of the client registration providers<br>
> > (REST<br>
> > > >> > > endpoints) to use - there are four as described in the Client<br>
> > > >> Registration<br>
> > > >> > > documentation (<br>
> > > >> > ><br>
> > > >><br>
> > <a href="http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html" rel="noreferrer" target="_blank">http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html</a><br>
> > > >> > > )<br>
> > > >> > ><br>
> > > >> > > Ideally the input format of the file could be recognised as only<br>
> > > >> > > appropriate for one of these providers, and the correct provider<br>
> > then<br>
> > > >> > > automatically used. But maybe we need a way to explicitly tell the<br>
> > > >> tool<br>
> > > >> > > what provider to use. For example:<br>
> > > >> > ><br>
> > > >> > > kc new --type default --name test-app --enabled true --base-url<br>
> > > >> > > <a href="http://localhost:8480/test-app" rel="noreferrer" target="_blank">http://localhost:8480/test-app</a> --redirect-uri '<br>
> > > >> > > <a href="http://localhost:8480/test-app/*" rel="noreferrer" target="_blank">http://localhost:8480/test-app/*</a>' --admin-url<br>
> > > >> > > <a href="http://localhost:8480/test-app/logout" rel="noreferrer" target="_blank">http://localhost:8480/test-app/logout</a> --secret password | kc<br>
> > create<br>
> > > >> > > --type default -f -<br>
> > > >> > ><br>
> > > >> > ><br>
> > > >> > ><br>
> > > >> > > Having to set --type for both creating a description (kc new), and<br>
> > > >> > > pushing it to the server (kc create) is not ideal.<br>
> > > >> > ><br>
> > > >> ><br>
> > > >> > We can detect the difference between Keycloak client rep, SAML and<br>
> > OIDC<br>
> > > >> > json that's pretty trivial and we should do that. However, there<br>
> > needs<br>
> > > >> to<br>
> > > >> > be a way to specify the provider as well as there could be custom<br>
> > > >> providers<br>
> > > >> > added.<br>
> > > >> ><br>
> > > >> > For getting the client it should by default return Keycloak client<br>
> > > >> > representation, but we need an option to be able to specify the<br>
> > > >> provider so<br>
> > > >> > it can return the client installation file instead.<br>
> > > >> ><br>
> > > >> > With regards to creating by passing arguments rather than a file<br>
> > that<br>
> > > >> > should only support client representation files.<br>
> > > >> ><br>
> > > >> ><br>
> > > >> ><br>
> > > >> > ><br>
> > > >> > ><br>
> > > >> > >><br>
> > > >> > >><br>
> > > >> > >>><br>
> > > >> > >>> * I don't see anything in your document on how to specify the<br>
> > SAML<br>
> > > >> > >>> metadata.<br>
> > > >> > >>><br>
> > > >> > >><br>
> > > >> > > Instead of piping in my-client.json, you would pipe in<br>
> > > >> my-client-saml.xml,<br>
> > > >> > > possibly requiring an extra --type specifier as described above.<br>
> > > >> > ><br>
> > > >> > ><br>
> > > >> > >><br>
> > > >> > >>> * I don't see anything in your document on how the user<br>
> > modifies the<br>
> > > >> > >>> client. It appears as if you are retrieving a<br>
> > ClientRepresentation<br>
> > > >> JSON<br>
> > > >> > >>> document and expecting the user to edit it in a text editor<br>
> > which<br>
> > > >> will<br>
> > > >> > >>> then be sent back. That won't work for non-interactive<br>
> > installs. It<br>
> > > >> also<br>
> > > >> > >>> presumes the user knows how to read and modify the JSON.<br>
> > > >> > >>><br>
> > > >> > >><br>
> > > >> > >> It would be nice to be able to set specific fields without<br>
> > having to<br>
> > > >> > >> modify JSON. We discussed that for the Admin CLI, but we should<br>
> > > >> probably<br>
> > > >> > >> also add it to the client reg CLI<br>
> > > >> > >><br>
> > > >> > ><br>
> > > >> > > It would be very valuable to see some of the usecases, what kind<br>
> > of<br>
> > > >> > > changes people do on existing clients.<br>
> > > >> > ><br>
> > > >> ><br>
> > > >> > We should support anything that is in client representation. It<br>
> > should<br>
> > > >> just<br>
> > > >> > be a generic way to change json fields. For example:<br>
> > > >> ><br>
> > > >> > # kcreg update <client id> --set enabled=false --set baseUrl=<br>
> > > >> > <a href="http://new-url/myapp" rel="noreferrer" target="_blank">http://new-url/myapp</a> --remove rootUrl<br>
> > > >> ><br>
> > > >> > This would get the KC client rep, change the corresponding fields<br>
> > and<br>
> > > >> send<br>
> > > >> > it back.<br>
> > > >> ><br>
> > > >> ><br>
> > > >> > ><br>
> > > >> > ><br>
> > > >> > >><br>
> > > >> > >><br>
> > > >> > >>><br>
> > > >> > >>> * Keycloak currently has a few problems with client<br>
> > registration and<br>
> > > >> > >>> it's necessary to modify the client before it will work<br>
> > correctly.<br>
> > > >> We<br>
> > > >> > >>> currently do this via the REST API. How are you planning on<br>
> > handling<br>
> > > >> > >>> these issues in your installer? It would be nice if the<br>
> > installer<br>
> > > >> was<br>
> > > >> > >>> aware of the Keycloak version and could apply "fix-ups" as<br>
> > needed<br>
> > > >> based<br>
> > > >> > >>> on the version.<br>
> > > >> > >>><br>
> > > >> > >><br>
> > > >> > >> AFAIK you have one problem? About not all redirect URI included<br>
> > from<br>
> > > >> the<br>
> > > >> > >> SAML entity descriptor. Is that what you are referring to or do<br>
> > you<br>
> > > >> have<br>
> > > >> > >> other problems?<br>
> > > >> > >><br>
> > > >> > >> In either case fix-ups should be performed by the client<br>
> > registration<br>
> > > >> > >> services, not in the CLI.<br>
> > > >> > >><br>
> > > >> > >><br>
> > > >> > >>><br>
> > > >> > >>> * Keycloak has two ways to register a client (client<br>
> > registration<br>
> > > >> > >>> service vs. REST API). The two methods do not produce the same<br>
> > > >> client<br>
> > > >> > >>> configuration (I suspect because they do not share common code<br>
> > in<br>
> > > >> the<br>
> > > >> > >>> server). How are you planning on addressing the discrepancies?<br>
> > > >> > >>><br>
> > > >> > >><br>
> > > >> > >> The task of the CLI is not to address any discrepancies. It's<br>
> > just<br>
> > > >> > >> invoking the client reg services. Any discrepancies should be<br>
> > > >> handled by<br>
> > > >> > >> the client reg services themselves. Have you created JIRA's for<br>
> > > >> these or<br>
> > > >> > >> can you list them to us?<br>
> > > >> > >><br>
> > > >> > >><br>
> > > >> > >>><br>
> > > >> > >>> * The tool should be smart enough to produce a working client<br>
> > > >> without<br>
> > > >> > >>> manual intervention (i.e. the need to run admin cli commands<br>
> > > >> afterwards<br>
> > > >> > >>> to fix problems). Most admins won't know how to tweak the<br>
> > > >> configuration.<br>
> > > >> > >>><br>
> > > >> > >><br>
> > > >> > >> Can you list any you are aware of? Same comment as above applies<br>
> > > >> though,<br>
> > > >> > >> it's the responsibility of the client reg services to handle<br>
> > this,<br>
> > > >> not the<br>
> > > >> > >> CLI. Otherwise you'd have different behavior if you invoke<br>
> > client reg<br>
> > > >> > >> services directly rather than through the CLI.<br>
> > > >> > >><br>
> > > >> > >><br>
> > > >> > >>><br>
> > > >> > >>> * The tool should not have significant dependencies.<br>
> > > >> > >>><br>
> > > >> > >><br>
> > > >> > >> It'll be a fat-jar and will have a single dependency on the JVM.<br>
> > > >> > >><br>
> > > >> > >><br>
> > > >> > >>><br>
> > > >> > >>> Those are the thoughts off the top of my head, as you fill out<br>
> > the<br>
> > > >> > >>> details I'll continue to review. Recall the plan of record is<br>
> > for<br>
> > > >> > >>> Keycloak to provide such tools which we will then utilize. The<br>
> > > >> > >>> keycloak-httpd-client-install tool is a stop-gap solution until<br>
> > such<br>
> > > >> > >>> time as "offical" tools become available.<br>
> > > >> > >>><br>
> > > >> > >>><br>
> > > >> > >>><br>
> > > >> > >>> --<br>
> > > >> > >>> John<br>
> > > >> > >>> _______________________________________________<br>
> > > >> > >>> keycloak-dev mailing list<br>
> > > >> > >>> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> > > >> > >>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
> > > >> > >>><br>
> > > >> > >><br>
> > > >> > >><br>
> > > >> > ><br>
> > > >><br>
> > > >> > _______________________________________________<br>
> > > >> > keycloak-dev mailing list<br>
> > > >> > <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> > > >> > <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
> > > >><br>
> > > >><br>
> > > >> --<br>
> > > >><br>
> > > >> abstractj<br>
> > > >> PGP: 0x84DC9914<br>
> > > >><br>
> > > ><br>
> > > ><br>
> ><br>
> > --<br>
> ><br>
> > abstractj<br>
> > PGP: 0x84DC9914<br>
> ><br>
<br>
</div></div>--<br>
<br>
abstractj<br>
PGP: 0x84DC9914<br>
</blockquote></div><br></div></div>