Keycloak Live Events?
by Stian Thorgersen
All,
I have been considering setting up a series of live events for Keycloak.
The plan would be once a month to have a live event with presentations from
the Keycloak team and we would also be happy to invite others that want to
talk about Keycloak.
Topics would include presentations on new features, archicture/design on
upcoming features and perhaps open Q&A sessions.
Now the question is how many would attend? Let me know on the mailing list
or on Doodle (https://doodle.com/poll/qadckvmkgi6eyukd) if you are
interested. I'm also interested in knowing if you are not interested.
Suggestions for other topics are also welcome.
5 years, 11 months
Device fingerprinting
by Douglas Palmer
Hi everyone
I haven’t managed to find an open source solution to device fingerprinting which gives us everything we need. This library however gets us most of the way there http://valve.github.io/fingerprintjs2 <http://valve.github.io/fingerprintjs2>. It doesn’t give us enough information to distinguish between a desktop and a laptop but it will let us correlate devices and we can distinguish between a PC, a tablet and a phone. We can also get the OS, Browser and Versions from the user agent string.
I have taken a look at a few sites the track device sessions. Apple can tell the difference between an iMac, a MacBook, an iPad and an iPhone. Facebook, GitHub, Google, LinkedIn and Pinterest don’t distinguish between an iMac and a MacBook. So maybe the library above is enough.
I also came across the following article from the EFF which casts doubt on the legality of digital fingerprinting in Europe. https://www.eff.org/deeplinks/2018/06/gdpr-and-browser-fingerprinting-how... <https://www.eff.org/deeplinks/2018/06/gdpr-and-browser-fingerprinting-how...>
Does anyone have any input on any of this? Is there a better library that I have missed? Should we stick to parsing the user agent to avoid potential problems with GDPR?
Regards
Doug
5 years, 11 months
Clustering configuration
by Sebastian Laskawiec
Hey guys,
During our weekly sync meeting, Stian asked me to look into different
options for clustering in Keycloak server. This topic has quite hot with
the context of our Docker image (see the proposed community contributions
[1][2][3]). Since we are based on WF 13, which uses JGroups 4.0.11 and has
KUBE_PING in its modules, we have a couple of options how to do it.
Before discussing different implementations, let me quickly go through the
requirements:
- We need a configuration stack that works for on-prem and cloud
deployments with OpenShift as our primary target.
- The configuration should be automatic (if it's possible). E.g. if we
discover that Keycloak is running in the container, we should use proper
discovery protocol.
- There needs to be a way to override the discovery protocol manually.
With those requirements in mind, we have a couple of implementation options
on the table:
1. Add more stacks to the configuration, e.g. openshift, azure or gcp. Then
we use the standard `-Djboss.default.jgroups.stack=<stack>` configuration
switch.
2. Provide more standalone-*.xml configuration files, e.g.
standalone-ha.xml (for on-prem) or standalone-cloud.xml.
3. Add protocols dynamically using CLI. A similar approach to what we did
for the Data Grid Cache Service [4].
4. Use MULTI_PING protocols [5][6], with multiple discovery protocols on
the same stack. This will include MPING (for multicasting), KUBE_PING (if
we can access Kubernetes API), DNS_PING (if Pods are governed by a Service).
Option #1 and #2 is somewhat similar to what we did for Infinispan [7]. It
works quite well but the configuration grows quite quickly and most of the
protocols (apart from discovery) are duplicated. On the other hand, having
separate configuration pieces for each use case is very flexible. Having in
mind that AWS cuts TCP connections, using FD_SOCK might lead to false
suspicions but on GCP for the instance, FD_SOCK works quite nicely. The CLI
option (#3), is also very flexible and probably should be implemented only
in our Docker image. This somehow follows the convention we already started
with different CLI files for different DBs [8]. Option #4 is brand new
(implemented in JGroups 4.0.8; we have 4.0.11 as you probably recall). It
has been specifically designed for this kind of use cases where we want to
gather discovery data from multiple places. Using this way, we should end
up with two stacks in standalone-ha.xml file - UDP and TCP.
I honestly need to say, that my heart goes for options #4. However, as far
as I know it hasn't been battle tested and we might get some surprises. All
other options are not as elegant as option #4 but they are used somewhere
in other projects. They are much safer options but they will add some
maintenance burden on our shoulders.
What would you suggest guys? What do you think about all this? @Rado,
@Paul, @Tristan - Do you have any plans regarding this piece in Wildfly or
Infinispan?
Thanks,
Sebastian
[1] https://github.com/jboss-dockerfiles/keycloak/pull/96
[2] https://github.com/jboss-dockerfiles/keycloak/pull/100
[3] https://github.com/jboss-dockerfiles/keycloak/pull/116
[4]
https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-...
[5] http://www.jgroups.org/manual4/index.html#_multi_ping
[6] https://issues.jboss.org/browse/JGRP-2224
[7]
https://github.com/infinispan/infinispan/tree/master/server/integration/j...
[8]
https://github.com/jboss-dockerfiles/keycloak/tree/master/server/tools/cl...
5 years, 12 months
Invalid CORS request
by Jeus Geek
Hi
I add a new tab (SMS) for configuration service.
this service has 2 <key, value> same for a register in the database
I used from SMTP (Email) tab to configuration develop that. when trying to
set configuration at system get an error
"19:06:11,581 DEBUG [org.keycloak.services.resources.Cors] (default task-7)
Invalid CORS request: origin http://127.0.0.1:8080 not in allowed origins
[]"
I can't find anywhere that defined CORSs for new realm tabs.
Thanks
Jeus
5 years, 12 months
Re: [keycloak-dev] Clustering configuration
by Sebastian Laskawiec
Answering a several email in a row. Please forgive me for not responding
each one individually.
Keycloak is actually a web app (rather than a separate app as Infiispan,
which is more forked of Wildfly rather than layered). We already use a
database that needs to be somewhere there (either embedded H2, MySQL or
whatever). Moreover, we also define our data source - KeycloakDS. I also
expect Keycloak clusters to be rather small, just 2-3 servers for HA.
Having all this in mind, using JDBC_PING might not be a bad idea, I think.
I guess we are lucky since we can assume that we already have an SQL
database running. @Bela Ban <bban(a)redhat.com> I've also seen you fixed the
crashed members issue mentioned in [1] in 4.0.10. We're on 4.0.11, so we
should also be good to go.
However there are a few limitations that are worth mentioning and I would
like to request some comments from @Marek Posolda <mposolda(a)redhat.com>, @Stian
Thorgersen <stian(a)redhat.com> and @Hynek Mlnarik <hmlnarik(a)redhat.com>:
- This makes our dependency to the database even stronger. If we ever
decided to change the storage, this issue will get back to us like a
boomerang.
- When considering cross site replication (with database replication turned
on), I guess we will need a separate, not-replicated table for discovery
per each site. Otherwise, sites might override each other by writing into
the same row in the same table.
- We have a few data base implementation that we can work with (H2, MySQL,
PostgreSQL and others but that requires additional drivers). The JDBC_PING
uses SQL queries so we would need to write them in such a way, that they
always work regardless to the DB implementation. Since this is at the
configuration level, we can not use JPA. Those will need to be hand-crafted
queries. But I guess it shouldn't be a big deal.
The MULTI_PING also seems very interesting. Thanks a lot for all the useful
info! @Paul Ferraro <paul.ferraro(a)redhat.com>, could you please tell me
when do you plan to implement the multi discovery protocol behavior you
mentioned in your email? In which Wildfly version this feature will be
available?
Thanks,
Sebastian
PS - If you guys spot any problems with JDBC_PING and current version of
Keycloak, please create a JIRA for us -
https://issues.jboss.org/browse/KEYCLOAK
[1] https://issues.jboss.org/browse/JGRP-2245
On Wed, Sep 12, 2018 at 5:10 PM Bela Ban <bban(a)redhat.com> wrote:
>
>
> On 12/09/18 14:46, Paul Ferraro wrote:
> > Hi Sebastian,
> >
> > We've planned to support MULTI_PING in WF by adding it to the stack
> > automatically in the event that a stack contains multiple discovery
> > protocols [1]. We want to keep this hidden from users, since JGroups
> > plans to support multiple discovery protocols transparently [2].
>
> As I said before, I don't like to add hidden stuff, or else
> configuration != runtime. However, in this specific case, I agree that
> this may be a good interim solution until we have multiple discovery
> protocols without the need for MULTI_PING.
>
> > Since we haven't had time to do this yet, we have not yet performed
> > any testing of MULTI_PING, nor do I know of any users already using
> > this.
>
> Correct. I haven't heard of any users, either.
>
> Next steps wrt discovery are me thinking about multiple discovery
> protocols without MULTI_PING and perhaps a more reactive design
> (FIND_MBRS_ASYNC) involving CompletableFutures, as suggested by Dan.
>
> > If you don't have the bandwidth to toy with MULTI_PING, I would
> > strongly encourage you to use option #3. Configuration XML is
> > permitted to change dramatically between schema versions, and can be a
> > nightmare for XML manipulation scripts, while the EAP/WF management
> > CLI is effectively a stable API, where backwards compatibility (for a
> > specific version range of the model) is a requirement. Rado recently
> > refactored our testsuite to uses CLI scripts for modifying
> > configuration (instead of XML manipulation) and it has considerably
> > reduced the complexity of our testsuite. I can't imagine ever going
> > back.
> >
> > CLI scripts for WF/EAP's jgroups subsystem would look considerably
> > simpler than the scripts you posted above (for the datagrid-jgroups
> > subsystem). Specifically:
> > 1. Rather than remove and redefine an entire protocol stack, you can
> > remove a specific protocol and insert an new one in the stack at a
> > specific index.
> > 2. pbcast.NAKACK2's use_mcast_xmit attribute is auto-disabled when the
> > transport does not support multicast, so this property never needs to
> > be set explicitly.
> > 3. All clustering operations support the
> > {allow-resource-service-restart=true} operation header to avoid a full
> > server reload by restarting only affected services. Batching
> > (especially when containing remove/add operation pairs) is encouraged
> > to eliminate redundant service restarts.
> >
> > [1] https://issues.jboss.org/browse/WFLY-9723
> > [2] https://issues.jboss.org/browse/JGRP-2230
> > On Wed, Sep 12, 2018 at 4:00 AM Sebastian Laskawiec <slaskawi(a)redhat.com>
> wrote:
> >>
> >> Hey guys,
> >>
> >> During our weekly sync meeting, Stian asked me to look into different
> options for clustering in Keycloak server. This topic has quite hot with
> the context of our Docker image (see the proposed community contributions
> [1][2][3]). Since we are based on WF 13, which uses JGroups 4.0.11 and has
> KUBE_PING in its modules, we have a couple of options how to do it.
> >>
> >> Before discussing different implementations, let me quickly go through
> the requirements:
> >> - We need a configuration stack that works for on-prem and cloud
> deployments with OpenShift as our primary target.
> >> - The configuration should be automatic (if it's possible). E.g. if we
> discover that Keycloak is running in the container, we should use proper
> discovery protocol.
> >> - There needs to be a way to override the discovery protocol manually.
> >>
> >> With those requirements in mind, we have a couple of implementation
> options on the table:
> >> 1. Add more stacks to the configuration, e.g. openshift, azure or gcp.
> Then we use the standard `-Djboss.default.jgroups.stack=<stack>`
> configuration switch.
> >> 2. Provide more standalone-*.xml configuration files, e.g.
> standalone-ha.xml (for on-prem) or standalone-cloud.xml.
> >> 3. Add protocols dynamically using CLI. A similar approach to what we
> did for the Data Grid Cache Service [4].
> >> 4. Use MULTI_PING protocols [5][6], with multiple discovery protocols
> on the same stack. This will include MPING (for multicasting), KUBE_PING
> (if we can access Kubernetes API), DNS_PING (if Pods are governed by a
> Service).
> >>
> >> Option #1 and #2 is somewhat similar to what we did for Infinispan [7].
> It works quite well but the configuration grows quite quickly and most of
> the protocols (apart from discovery) are duplicated. On the other hand,
> having separate configuration pieces for each use case is very flexible.
> Having in mind that AWS cuts TCP connections, using FD_SOCK might lead to
> false suspicions but on GCP for the instance, FD_SOCK works quite nicely.
> The CLI option (#3), is also very flexible and probably should be
> implemented only in our Docker image. This somehow follows the convention
> we already started with different CLI files for different DBs [8]. Option
> #4 is brand new (implemented in JGroups 4.0.8; we have 4.0.11 as you
> probably recall). It has been specifically designed for this kind of use
> cases where we want to gather discovery data from multiple places. Using
> this way, we should end up with two stacks in standalone-ha.xml file - UDP
> and TCP.
> >>
> >> I honestly need to say, that my heart goes for options #4. However, as
> far as I know it hasn't been battle tested and we might get some surprises.
> All other options are not as elegant as option #4 but they are used
> somewhere in other projects. They are much safer options but they will add
> some maintenance burden on our shoulders.
> >>
> >> What would you suggest guys? What do you think about all this? @Rado,
> @Paul, @Tristan - Do you have any plans regarding this piece in Wildfly or
> Infinispan?
> >>
> >> Thanks,
> >> Sebastian
> >>
> >> [1] https://github.com/jboss-dockerfiles/keycloak/pull/96
> >> [2] https://github.com/jboss-dockerfiles/keycloak/pull/100
> >> [3] https://github.com/jboss-dockerfiles/keycloak/pull/116
> >> [4]
> https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-...
> >> [5] http://www.jgroups.org/manual4/index.html#_multi_ping
> >> [6] https://issues.jboss.org/browse/JGRP-2224
> >> [7]
> https://github.com/infinispan/infinispan/tree/master/server/integration/j...
> >> [8]
> https://github.com/jboss-dockerfiles/keycloak/tree/master/server/tools/cl...
>
> --
> Bela Ban | http://www.jgroups.org
>
>
5 years, 12 months
Regarding https://issues.jboss.org/browse/KEYCLOAK-8162
by vidhyadharan D
Hi Experts,
I have been working on keycloak html email. I am in need to embed logo to
the emails i.e. from the *themes/email/resources/img/logo.png *
In the login module there is a way to locate image / favicon via
${url.resourcesPath}
However in email module we dont have access to locate the resources..
I have achieved by adding custom email template provider. If possible
please add these into email module because it is useful for all .
or let me know i can provide PR.
https://issues.jboss.org/browse/KEYCLOAK-8162
Thanks,
vidhya
5 years, 12 months
Proxy injects Role headers
by Raúl Uría Elices
Hi all,
We would like proxy to inject Role information as a header for
authorization purpouses. I think this can be easily achive by adding a
new key for "header-names" in config.json and putting the information
that already exists on the back request ...
We have a working branch for this, maybe we can pull request if is
interesting for others.
bye.
--
*Raúl Uría Elíces*
Director
e-mail: ruria(a)zzircon.com<mailto:ruria@zzircon.com>
web: www.zzircon.com<http://www.zzircon.com/>
Tlf: 609 721021
ZZircon Technologies SL
Parque Científico Tecnológico de Cantabria
Edificio 3000 Oficina 11
c/ Isabel Torres 11
39011 Santander
/Este mensaje de correo electrónico y sus documentos adjuntos están
dirigidos EXCLUSIVAMENTE a los destinatarios especificados. La
información contenida puede ser CONFIDENCIAL y / o estar LEGALMENTE
PROTEGIDA y no necesariamente refleja la opinión de este grupo de
correo. Si usted recibe este mensaje por ERROR, por favor comuníqueselo
inmediatamente al remitente y elimínelo ya que usted NO ESTA AUTORIZADO
al uso, revelación, distribución, impresión o copia de toda o alguna
parte de la información contenida. Gracias./
® ZZircon Technologies SL- TFNO 609 721021 �
info(a)zzircon.com<mailto:info@zzircon.com>
5 years, 12 months
