11:44 a.m.
Hello,
I just wanted to let this mailing list know that for the Cloudtrust project
(https://github.com/cloudtrust), we have developed a certain number modules for Keycloak.
These are currently compatible with the version 3.4.3.Final of Keycloak, but we will make
them compatible with Keycloak 4.X (where X will be the latest sub-version of Keycloak when
we start working on this) as soon as we can. These modules are:
* keycloak-wsfed (https://github.com/cloudtrust/keycloak-wsfed): an implementation of the
WS-Federation protocol for keycloak. This allows to select the WS-Federation protocol for
Keycloak clients and for identity brokers.
* keycloak-authorization (https://github.com/cloudtrust/keycloak-authorization): this
module allows the use of the client authorization system to prevent a user which is
authenticated in a Keycloak realm to access a given client. It works no matter which
protocol is used, and without the client having to support any extra protocol. Note: this
solution is a bit hacky, but necessary for one of our use-cases.
* keycloak-client-mappers (https://github.com/cloudtrust/keycloak-client-mappers): a
module for adding any mappers that we might need that are not yet part of Keycloak.
Currently only contains a JavaScript mapper for SAML, analogous to the OIDC script mapper.
I've noticed that there's an open issue for this feature
(https://issues.jboss.org/browse/KEYCLOAK-5520). If desirable I could submit this code not
as a module but a solution to the issue.
* keycloak-export (https://github.com/cloudtrust/keycloak-export): a module adding an
endpoint to fully export a realm while Keycloak is still running (no need for restarts!).
Cheers,
Alistair
PS: I'm mailing this both dev and user mailing lists as I believe it may interest
members of both mailing lists
2:43 p.m.
Thanks for the heads up!
IMO it will be cool if you send PR for the javascript mapper directly to
Keycloak, however we may need automated test and also docs (separate PR
needs to be sent for the docs).
For the keycloak-authorization and keycloak-export (and maybe for
keycloak-client-mappers too if you don't have time for the PR to
upstream), it may be good to send PR to update the extensions page
maybe? It's here: https://www.keycloak.org/extensions.html and sources
are here:
https://github.com/keycloak/keycloak-web/tree/master/src/main/resources/e...
. Assuming that those things are generally useful for the other users
from the community (I am not 100% sure about the keycloak-authorization.
Rather leaving to you to decide if it's generally useful or not). The
keycloak-wsfed is already on the extensions page.
Thanks!
Marek
On 10/08/18 11:44, Doswald Alistair wrote:
Hello,
I just wanted to let this mailing list know that for the Cloudtrust project
(https://github.com/cloudtrust), we have developed a certain number modules for Keycloak.
These are currently compatible with the version 3.4.3.Final of Keycloak, but we will make
them compatible with Keycloak 4.X (where X will be the latest sub-version of Keycloak when
we start working on this) as soon as we can. These modules are:
* keycloak-wsfed (https://github.com/cloudtrust/keycloak-wsfed): an implementation of the
WS-Federation protocol for keycloak. This allows to select the WS-Federation protocol for
Keycloak clients and for identity brokers.
* keycloak-authorization (https://github.com/cloudtrust/keycloak-authorization): this
module allows the use of the client authorization system to prevent a user which is
authenticated in a Keycloak realm to access a given client. It works no matter which
protocol is used, and without the client having to support any extra protocol. Note: this
solution is a bit hacky, but necessary for one of our use-cases.
* keycloak-client-mappers (https://github.com/cloudtrust/keycloak-client-mappers): a
module for adding any mappers that we might need that are not yet part of Keycloak.
Currently only contains a JavaScript mapper for SAML, analogous to the OIDC script mapper.
I've noticed that there's an open issue for this feature
(https://issues.jboss.org/browse/KEYCLOAK-5520). If desirable I could submit this code not
as a module but a solution to the issue.
* keycloak-export (https://github.com/cloudtrust/keycloak-export): a module adding an
endpoint to fully export a realm while Keycloak is still running (no need for restarts!).
Cheers,
Alistair
PS: I'm mailing this both dev and user mailing lists as I believe it may interest
members of both mailing lists
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
6:51 p.m.
Cool stuff ! Thanks for sharing.
I've looked keycloak-authorization very quickly and changes look really
simple, I'm glad to start a discussion about supporting this OOTB. Maybe
this can be part of the review of admin fine-grained permissions we are
planning.
Regards.
Pedro Igor
On Fri, Aug 10, 2018 at 9:43 AM, Marek Posolda <mposolda(a)redhat.com> wrote:
Thanks for the heads up!
IMO it will be cool if you send PR for the javascript mapper directly to
Keycloak, however we may need automated test and also docs (separate PR
needs to be sent for the docs).
For the keycloak-authorization and keycloak-export (and maybe for
keycloak-client-mappers too if you don't have time for the PR to
upstream), it may be good to send PR to update the extensions page
maybe? It's here: https://www.keycloak.org/extensions.html and sources
are here:
https://github.com/keycloak/keycloak-web/tree/master/src/
main/resources/extensions
. Assuming that those things are generally useful for the other users
from the community (I am not 100% sure about the keycloak-authorization.
Rather leaving to you to decide if it's generally useful or not). The
keycloak-wsfed is already on the extensions page.
Thanks!
Marek
On 10/08/18 11:44, Doswald Alistair wrote:
> Hello,
>
> I just wanted to let this mailing list know that for the Cloudtrust
project (https://github.com/cloudtrust), we have developed a certain
number modules for Keycloak. These are currently compatible with the
version 3.4.3.Final of Keycloak, but we will make them compatible with
Keycloak 4.X (where X will be the latest sub-version of Keycloak when we
start working on this) as soon as we can. These modules are:
>
> * keycloak-wsfed (https://github.com/cloudtrust/keycloak-wsfed): an
implementation of the WS-Federation protocol for keycloak. This allows to
select the WS-Federation protocol for Keycloak clients and for identity
brokers.
>
> * keycloak-authorization (https://github.com/cloudtrust/keycloak-
authorization): this module allows the use of the client authorization
system to prevent a user which is authenticated in a Keycloak realm to
access a given client. It works no matter which protocol is used, and
without the client having to support any extra protocol. Note: this
solution is a bit hacky, but necessary for one of our use-cases.
>
> * keycloak-client-mappers (https://github.com/
cloudtrust/keycloak-client-mappers): a module for adding any mappers that
we might need that are not yet part of Keycloak. Currently only contains a
JavaScript mapper for SAML, analogous to the OIDC script mapper. I've
noticed that there's an open issue for this feature (
https://issues.jboss.org/browse/KEYCLOAK-5520). If desirable I could
submit this code not as a module but a solution to the issue.
>
> * keycloak-export (https://github.com/cloudtrust/keycloak-export): a
module adding an endpoint to fully export a realm while Keycloak is still
running (no need for restarts!).
>
> Cheers,
>
> Alistair
>
> PS: I'm mailing this both dev and user mailing lists as I believe it may
interest members of both mailing lists
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:33 p.m.
I’ve done the PR for the extension page (keycloak-authorization and keycloak-export), and
it’s been accepted. For the client-mapper I’ll see what’s necessary to be done to have it
merged directly into Keycloak.
For the mechanism of keycloak-authorization, I for one would like having this
functionality supported OOTB, whether through our (admittedly not very sophisticated)
system, or another. I received a message from Stian Thorgersen on the dev mailing (here:
http://lists.jboss.org/pipermail/keycloak-dev/2018-August/011116.html ) list asking more
details about the module, so I’ll at least be discussing the matter with him.
Cheers,
Alistair
From: Pedro Igor Silva <psilva(a)redhat.com>
Sent: vendredi 10 août 2018 18:52
To: Marek Posolda <mposolda(a)redhat.com>
Cc: Doswald Alistair <alistair.doswald(a)elca.ch>; keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] Keycloak Modules developed for the Cloudtrust project
Cool stuff ! Thanks for sharing.
I've looked keycloak-authorization very quickly and changes look really simple,
I'm glad to start a discussion about supporting this OOTB. Maybe this can be part of
the review of admin fine-grained permissions we are planning.
Regards.
Pedro Igor
On Fri, Aug 10, 2018 at 9:43 AM, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
Thanks for the heads up!
IMO it will be cool if you send PR for the javascript mapper directly to
Keycloak, however we may need automated test and also docs (separate PR
needs to be sent for the docs).
For the keycloak-authorization and keycloak-export (and maybe for
keycloak-client-mappers too if you don't have time for the PR to
upstream), it may be good to send PR to update the extensions page
maybe? It's here: https://www.keycloak.org/extensions.html and sources
are here:
https://github.com/keycloak/keycloak-web/tree/master/src/main/resources/e...
. Assuming that those things are generally useful for the other users
from the community (I am not 100% sure about the keycloak-authorization.
Rather leaving to you to decide if it's generally useful or not). The
keycloak-wsfed is already on the extensions page.
Thanks!
Marek
On 10/08/18 11:44, Doswald Alistair wrote:
Hello,
I just wanted to let this mailing list know that for the Cloudtrust project
(https://github.com/cloudtrust), we have developed a certain number modules for Keycloak.
These are currently compatible with the version 3.4.3.Final of Keycloak, but we will make
them compatible with Keycloak 4.X (where X will be the latest sub-version of Keycloak when
we start working on this) as soon as we can. These modules are:
* keycloak-wsfed (https://github.com/cloudtrust/keycloak-wsfed): an implementation of the
WS-Federation protocol for keycloak. This allows to select the WS-Federation protocol for
Keycloak clients and for identity brokers.
* keycloak-authorization (https://github.com/cloudtrust/keycloak-authorization): this
module allows the use of the client authorization system to prevent a user which is
authenticated in a Keycloak realm to access a given client. It works no matter which
protocol is used, and without the client having to support any extra protocol. Note: this
solution is a bit hacky, but necessary for one of our use-cases.
* keycloak-client-mappers (https://github.com/cloudtrust/keycloak-client-mappers): a
module for adding any mappers that we might need that are not yet part of Keycloak.
Currently only contains a JavaScript mapper for SAML, analogous to the OIDC script mapper.
I've noticed that there's an open issue for this feature
(https://issues.jboss.org/browse/KEYCLOAK-5520). If desirable I could submit this code not
as a module but a solution to the issue.
* keycloak-export (https://github.com/cloudtrust/keycloak-export): a module adding an
endpoint to fully export a realm while Keycloak is still running (no need for
restarts!).
Cheers,
Alistair
PS: I'm mailing this both dev and user mailing lists as I believe it may interest
members of both mailing lists
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
4:58 p.m.
Hello Alistair,
Have you created the pull request for the keycloak-export module?
It's a very useful one and I think it could be nice if it becomes fully a
part of keycloak.
Meissa
Le ven. 17 août 2018 à 14:40, Doswald Alistair <alistair.doswald(a)elca.ch> a
écrit :
I’ve done the PR for the extension page (keycloak-authorization and
keycloak-export), and it’s been accepted. For the client-mapper I’ll see
what’s necessary to be done to have it merged directly into Keycloak.
For the mechanism of keycloak-authorization, I for one would like having
this functionality supported OOTB, whether through our (admittedly not very
sophisticated) system, or another. I received a message from Stian
Thorgersen on the dev mailing (here:
http://lists.jboss.org/pipermail/keycloak-dev/2018-August/011116.html )
list asking more details about the module, so I’ll at least be discussing
the matter with him.
Cheers,
Alistair
From: Pedro Igor Silva <psilva(a)redhat.com>
Sent: vendredi 10 août 2018 18:52
To: Marek Posolda <mposolda(a)redhat.com>
Cc: Doswald Alistair <alistair.doswald(a)elca.ch>;
keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] Keycloak Modules developed for the Cloudtrust
project
Cool stuff ! Thanks for sharing.
I've looked keycloak-authorization very quickly and changes look really
simple, I'm glad to start a discussion about supporting this OOTB. Maybe
this can be part of the review of admin fine-grained permissions we are
planning.
Regards.
Pedro Igor
On Fri, Aug 10, 2018 at 9:43 AM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Thanks for the heads up!
IMO it will be cool if you send PR for the javascript mapper directly to
Keycloak, however we may need automated test and also docs (separate PR
needs to be sent for the docs).
For the keycloak-authorization and keycloak-export (and maybe for
keycloak-client-mappers too if you don't have time for the PR to
upstream), it may be good to send PR to update the extensions page
maybe? It's here: https://www.keycloak.org/extensions.html and sources
are here:
https://github.com/keycloak/keycloak-web/tree/master/src/main/resources/e...
. Assuming that those things are generally useful for the other users
from the community (I am not 100% sure about the keycloak-authorization.
Rather leaving to you to decide if it's generally useful or not). The
keycloak-wsfed is already on the extensions page.
Thanks!
Marek
On 10/08/18 11:44, Doswald Alistair wrote:
> Hello,
>
> I just wanted to let this mailing list know that for the Cloudtrust
project (https://github.com/cloudtrust), we have developed a certain
number modules for Keycloak. These are currently compatible with the
version 3.4.3.Final of Keycloak, but we will make them compatible with
Keycloak 4.X (where X will be the latest sub-version of Keycloak when we
start working on this) as soon as we can. These modules are:
>
> * keycloak-wsfed (https://github.com/cloudtrust/keycloak-wsfed): an
implementation of the WS-Federation protocol for keycloak. This allows to
select the WS-Federation protocol for Keycloak clients and for identity
brokers.
>
> * keycloak-authorization (
https://github.com/cloudtrust/keycloak-authorization): this module allows
the use of the client authorization system to prevent a user which is
authenticated in a Keycloak realm to access a given client. It works no
matter which protocol is used, and without the client having to support any
extra protocol. Note: this solution is a bit hacky, but necessary for one
of our use-cases.
>
> * keycloak-client-mappers (
https://github.com/cloudtrust/keycloak-client-mappers): a module for
adding any mappers that we might need that are not yet part of Keycloak.
Currently only contains a JavaScript mapper for SAML, analogous to the OIDC
script mapper. I've noticed that there's an open issue for this feature (
https://issues.jboss.org/browse/KEYCLOAK-5520). If desirable I could
submit this code not as a module but a solution to the issue.
>
> * keycloak-export (https://github.com/cloudtrust/keycloak-export): a
module adding an endpoint to fully export a realm while Keycloak is still
running (no need for restarts!).
>
> Cheers,
>
> Alistair
>
> PS: I'm mailing this both dev and user mailing lists as I believe it may
interest members of both mailing lists
> _______________________________________________
> keycloak-user mailing list
> keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:38 p.m.
Hello Meissa,
I’m a bit surprised about a question for Keycloak-export, as I thought that it was mostly
Keycloak-authorization which was of interest.
That being said, I haven’t created a pull request for this feature, no, though it is
available still as an extension on the cloudtrust project github (the latest release here
https://github.com/cloudtrust/keycloak-export/releases/download/0.4/keycl...
works on keycloak 4.6.0.FInal).
When I discussed the matter on the dev mailing list there were concerns about the
following aspects: data integrity, size of transfer and security. Our position was that
security is OK (data transferred over https), but that size and data integrity could be a
concern depending on the use case. However, from what I understood, there wasn’t really
any interest of bringing the feature to Keycloak.
If that has changed, I’ll gladly submit a pull request for the code.
Best regards,
Alistair Doswald
From: Meissa M'baye Sakho <msakho(a)redhat.com>
Sent: jeudi 6 décembre 2018 16:59
To: Doswald Alistair <alistair.doswald(a)elca.ch>
Cc: Pedro Igor Silva <psilva(a)redhat.com>; Marek Posolda <mposolda(a)redhat.com>;
keycloak-user <keycloak-user(a)lists.jboss.org>; Issa Gueye - Red Hat
<igueye(a)redhat.com>
Subject: Re: [keycloak-user] Keycloak Modules developed for the Cloudtrust project
Hello Alistair,
Have you created the pull request for the keycloak-export module?
It's a very useful one and I think it could be nice if it becomes fully a part of
keycloak.
Meissa
Le ven. 17 août 2018 à 14:40, Doswald Alistair
<alistair.doswald@elca.ch<mailto:alistair.doswald@elca.ch>> a écrit :
I’ve done the PR for the extension page (keycloak-authorization and keycloak-export), and
it’s been accepted. For the client-mapper I’ll see what’s necessary to be done to have it
merged directly into Keycloak.
For the mechanism of keycloak-authorization, I for one would like having this
functionality supported OOTB, whether through our (admittedly not very sophisticated)
system, or another. I received a message from Stian Thorgersen on the dev mailing (here:
http://lists.jboss.org/pipermail/keycloak-dev/2018-August/011116.html ) list asking more
details about the module, so I’ll at least be discussing the matter with him.
Cheers,
Alistair
From: Pedro Igor Silva <psilva@redhat.com<mailto:psilva@redhat.com>>
Sent: vendredi 10 août 2018 18:52
To: Marek Posolda <mposolda@redhat.com<mailto:mposolda@redhat.com>>
Cc: Doswald Alistair
<alistair.doswald@elca.ch<mailto:alistair.doswald@elca.ch>>;
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
Subject: Re: [keycloak-user] Keycloak Modules developed for the Cloudtrust project
Cool stuff ! Thanks for sharing.
I've looked keycloak-authorization very quickly and changes look really simple,
I'm glad to start a discussion about supporting this OOTB. Maybe this can be part of
the review of admin fine-grained permissions we are planning.
Regards.
Pedro Igor
On Fri, Aug 10, 2018 at 9:43 AM, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com><mailto:mposolda@redhat.com<mailto:mposolda@redhat.com>>>
wrote:
Thanks for the heads up!
IMO it will be cool if you send PR for the javascript mapper directly to
Keycloak, however we may need automated test and also docs (separate PR
needs to be sent for the docs).
For the keycloak-authorization and keycloak-export (and maybe for
keycloak-client-mappers too if you don't have time for the PR to
upstream), it may be good to send PR to update the extensions page
maybe? It's here: https://www.keycloak.org/extensions.html and sources
are here:
https://github.com/keycloak/keycloak-web/tree/master/src/main/resources/e...
. Assuming that those things are generally useful for the other users
from the community (I am not 100% sure about the keycloak-authorization.
Rather leaving to you to decide if it's generally useful or not). The
keycloak-wsfed is already on the extensions page.
Thanks!
Marek
On 10/08/18 11:44, Doswald Alistair wrote:
Hello,
I just wanted to let this mailing list know that for the Cloudtrust project
(https://github.com/cloudtrust), we have developed a certain number modules for Keycloak.
These are currently compatible with the version 3.4.3.Final of Keycloak, but we will make
them compatible with Keycloak 4.X (where X will be the latest sub-version of Keycloak when
we start working on this) as soon as we can. These modules are:
* keycloak-wsfed (https://github.com/cloudtrust/keycloak-wsfed): an implementation of the
WS-Federation protocol for keycloak. This allows to select the WS-Federation protocol for
Keycloak clients and for identity brokers.
* keycloak-authorization (https://github.com/cloudtrust/keycloak-authorization): this
module allows the use of the client authorization system to prevent a user which is
authenticated in a Keycloak realm to access a given client. It works no matter which
protocol is used, and without the client having to support any extra protocol. Note: this
solution is a bit hacky, but necessary for one of our use-cases.
* keycloak-client-mappers (https://github.com/cloudtrust/keycloak-client-mappers): a
module for adding any mappers that we might need that are not yet part of Keycloak.
Currently only contains a JavaScript mapper for SAML, analogous to the OIDC script mapper.
I've noticed that there's an open issue for this feature
(https://issues.jboss.org/browse/KEYCLOAK-5520). If desirable I could submit this code not
as a module but a solution to the issue.
* keycloak-export (https://github.com/cloudtrust/keycloak-export): a module adding an
endpoint to fully export a realm while Keycloak is still running (no need for
restarts!).
Cheers,
Alistair
PS: I'm mailing this both dev and user mailing lists as I believe it may interest
members of both mailing lists
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org><mailto:keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org><mailto:keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
3:37 p.m.
On 07/12/2018 14:38, Doswald Alistair wrote:
Hello Meissa,
I’m a bit surprised about a question for Keycloak-export, as I thought
that it was mostly Keycloak-authorization which was of interest.
That being said, I haven’t created a pull request for this feature,
no, though it is available still as an extension on the cloudtrust
project github (the latest release here
https://github.com/cloudtrust/keycloak-export/releases/download/0.4/keycl...
works on keycloak 4.6.0.FInal).
When I discussed the matter on the dev mailing list there were
concerns about the following aspects: data integrity, size of transfer
and security. Our position was that security is OK (data transferred
over https), but that size and data integrity could be a concern
depending on the use case. However, from what I understood, there
wasn’t really any interest of bringing the feature to Keycloak.
Yes, the size and data integrity can be a concern and that's the reason
why it's not officially supported to run full export/import in "online"
mode.
I know there is a workaround, which defacto allows "hot" export/import
in case that you have cluster environment. When you have 2 Keycloak
nodes, you can stop one of the node and then trigger export/import on
that node. But it's not something to recommend in production due the
issues with the integrity (Data can be changed in the meantime on node1
when export/import is in progress on node2, which can result in broken
data and tricky errors).
Marek
If that has changed, I’ll gladly submit a pull request for the code.
Best regards,
Alistair Doswald
*From:* Meissa M'baye Sakho <msakho(a)redhat.com>
*Sent:* jeudi 6 décembre 2018 16:59
*To:* Doswald Alistair <alistair.doswald(a)elca.ch>
*Cc:* Pedro Igor Silva <psilva(a)redhat.com>; Marek Posolda
<mposolda(a)redhat.com>; keycloak-user <keycloak-user(a)lists.jboss.org>;
Issa Gueye - Red Hat <igueye(a)redhat.com>
*Subject:* Re: [keycloak-user] Keycloak Modules developed for the
Cloudtrust project
Hello Alistair,
Have you created the pull request for the keycloak-export module?
It's a very useful one and I think it could be nice if it becomes
fully a part of keycloak.
Meissa
Le ven. 17 août 2018 à 14:40, Doswald Alistair
<alistair.doswald(a)elca.ch <mailto:alistair.doswald@elca.ch>> a écrit :
I’ve done the PR for the extension page (keycloak-authorization
and keycloak-export), and it’s been accepted. For the
client-mapper I’ll see what’s necessary to be done to have it
merged directly into Keycloak.
For the mechanism of keycloak-authorization, I for one would like
having this functionality supported OOTB, whether through our
(admittedly not very sophisticated) system, or another. I received
a message from Stian Thorgersen on the dev mailing (here:
http://lists.jboss.org/pipermail/keycloak-dev/2018-August/011116.html
) list asking more details about the module, so I’ll at least be
discussing the matter with him.
Cheers,
Alistair
From: Pedro Igor Silva <psilva(a)redhat.com <mailto:psilva@redhat.com>>
Sent: vendredi 10 août 2018 18:52
To: Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>>
Cc: Doswald Alistair <alistair.doswald(a)elca.ch
<mailto:alistair.doswald@elca.ch>>; keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
Subject: Re: [keycloak-user] Keycloak Modules developed for the
Cloudtrust project
Cool stuff ! Thanks for sharing.
I've looked keycloak-authorization very quickly and changes look
really simple, I'm glad to start a discussion about supporting
this OOTB. Maybe this can be part of the review of admin
fine-grained permissions we are planning.
Regards.
Pedro Igor
On Fri, Aug 10, 2018 at 9:43 AM, Marek Posolda
<mposolda(a)redhat.com
<mailto:mposolda@redhat.com><mailto:mposolda@redhat.com
<mailto:mposolda@redhat.com>>> wrote:
Thanks for the heads up!
IMO it will be cool if you send PR for the javascript mapper
directly to
Keycloak, however we may need automated test and also docs
(separate PR
needs to be sent for the docs).
For the keycloak-authorization and keycloak-export (and maybe for
keycloak-client-mappers too if you don't have time for the PR to
upstream), it may be good to send PR to update the extensions page
maybe? It's here: https://www.keycloak.org/extensions.html
<https://www.keycloak.org/extensions.html> and sources
are here:
https://github.com/keycloak/keycloak-web/tree/master/src/main/resources/e...
. Assuming that those things are generally useful for the other users
from the community (I am not 100% sure about the
keycloak-authorization.
Rather leaving to you to decide if it's generally useful or not). The
keycloak-wsfed is already on the extensions page.
Thanks!
Marek
On 10/08/18 11:44, Doswald Alistair wrote:
> Hello,
>
> I just wanted to let this mailing list know that for the
Cloudtrust project (https://github.com/cloudtrust), we have
developed a certain number modules for Keycloak. These are
currently compatible with the version 3.4.3.Final of Keycloak, but
we will make them compatible with Keycloak 4.X (where X will be
the latest sub-version of Keycloak when we start working on this)
as soon as we can. These modules are:
>
> * keycloak-wsfed (https://github.com/cloudtrust/keycloak-wsfed):
an implementation of the WS-Federation protocol for keycloak. This
allows to select the WS-Federation protocol for Keycloak clients
and for identity brokers.
>
> * keycloak-authorization
(https://github.com/cloudtrust/keycloak-authorization): this
module allows the use of the client authorization system to
prevent a user which is authenticated in a Keycloak realm to
access a given client. It works no matter which protocol is used,
and without the client having to support any extra protocol. Note:
this solution is a bit hacky, but necessary for one of our use-cases.
>
> * keycloak-client-mappers
(https://github.com/cloudtrust/keycloak-client-mappers): a module
for adding any mappers that we might need that are not yet part of
Keycloak. Currently only contains a JavaScript mapper for SAML,
analogous to the OIDC script mapper. I've noticed that there's an
open issue for this feature
(https://issues.jboss.org/browse/KEYCLOAK-5520). If desirable I
could submit this code not as a module but a solution to the issue.
>
> * keycloak-export
(https://github.com/cloudtrust/keycloak-export): a module adding
an endpoint to fully export a realm while Keycloak is still
running (no need for restarts!).
>
> Cheers,
>
> Alistair
>
> PS: I'm mailing this both dev and user mailing lists as I
believe it may interest members of both mailing lists
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org><mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
<https://lists.jboss.org/mailman/listinfo/keycloak-user>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org><mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
7:16 a.m.
Marek,
I was considering the hot solution regarding the cloud environment
(Openshift) where customer require zero downtime while making a backup for
disaster recovery purpose.
In that case, there will be no data integrity issue and they would be able
to export without stopping their cluster. Actually te only solution we can
to it is to scale down the nodes to 0 which mean stopping all RHSSO pods.
This is way I think that Doswald solution would need the requirement.
Meissa
Le ven. 7 déc. 2018 à 15:37, Marek Posolda <mposolda(a)redhat.com> a écrit :
On 07/12/2018 14:38, Doswald Alistair wrote:
Hello Meissa,
I’m a bit surprised about a question for Keycloak-export, as I thought
that it was mostly Keycloak-authorization which was of interest.
That being said, I haven’t created a pull request for this feature, no,
though it is available still as an extension on the cloudtrust project
github (the latest release here
https://github.com/cloudtrust/keycloak-export/releases/download/0.4/keycl...
works on keycloak 4.6.0.FInal).
When I discussed the matter on the dev mailing list there were concerns
about the following aspects: data integrity, size of transfer and security.
Our position was that security is OK (data transferred over https), but
that size and data integrity could be a concern depending on the use case.
However, from what I understood, there wasn’t really any interest of
bringing the feature to Keycloak.
Yes, the size and data integrity can be a concern and that's the reason
why it's not officially supported to run full export/import in "online"
mode.
I know there is a workaround, which defacto allows "hot" export/import in
case that you have cluster environment. When you have 2 Keycloak nodes, you
can stop one of the node and then trigger export/import on that node. But
it's not something to recommend in production due the issues with the
integrity (Data can be changed in the meantime on node1 when export/import
is in progress on node2, which can result in broken data and tricky errors).
Marek
If that has changed, I’ll gladly submit a pull request for the code.
Best regards,
Alistair Doswald
*From:* Meissa M'baye Sakho <msakho(a)redhat.com> <msakho(a)redhat.com>
*Sent:* jeudi 6 décembre 2018 16:59
*To:* Doswald Alistair <alistair.doswald(a)elca.ch>
<alistair.doswald(a)elca.ch>
*Cc:* Pedro Igor Silva <psilva(a)redhat.com> <psilva(a)redhat.com>; Marek
Posolda <mposolda(a)redhat.com> <mposolda(a)redhat.com>; keycloak-user
<keycloak-user(a)lists.jboss.org> <keycloak-user(a)lists.jboss.org>; Issa
Gueye - Red Hat <igueye(a)redhat.com> <igueye(a)redhat.com>
*Subject:* Re: [keycloak-user] Keycloak Modules developed for the
Cloudtrust project
Hello Alistair,
Have you created the pull request for the keycloak-export module?
It's a very useful one and I think it could be nice if it becomes fully a
part of keycloak.
Meissa
Le ven. 17 août 2018 à 14:40, Doswald Alistair <alistair.doswald(a)elca.ch>
a écrit :
I’ve done the PR for the extension page (keycloak-authorization and
keycloak-export), and it’s been accepted. For the client-mapper I’ll see
what’s necessary to be done to have it merged directly into Keycloak.
For the mechanism of keycloak-authorization, I for one would like having
this functionality supported OOTB, whether through our (admittedly not very
sophisticated) system, or another. I received a message from Stian
Thorgersen on the dev mailing (here:
http://lists.jboss.org/pipermail/keycloak-dev/2018-August/011116.html )
list asking more details about the module, so I’ll at least be discussing
the matter with him.
Cheers,
Alistair
From: Pedro Igor Silva <psilva(a)redhat.com>
Sent: vendredi 10 août 2018 18:52
To: Marek Posolda <mposolda(a)redhat.com>
Cc: Doswald Alistair <alistair.doswald(a)elca.ch>;
keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] Keycloak Modules developed for the Cloudtrust
project
Cool stuff ! Thanks for sharing.
I've looked keycloak-authorization very quickly and changes look really
simple, I'm glad to start a discussion about supporting this OOTB. Maybe
this can be part of the review of admin fine-grained permissions we are
planning.
Regards.
Pedro Igor
On Fri, Aug 10, 2018 at 9:43 AM, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Thanks for the heads up!
IMO it will be cool if you send PR for the javascript mapper directly to
Keycloak, however we may need automated test and also docs (separate PR
needs to be sent for the docs).
For the keycloak-authorization and keycloak-export (and maybe for
keycloak-client-mappers too if you don't have time for the PR to
upstream), it may be good to send PR to update the extensions page
maybe? It's here: https://www.keycloak.org/extensions.html and sources
are here:
https://github.com/keycloak/keycloak-web/tree/master/src/main/resources/e...
. Assuming that those things are generally useful for the other users
from the community (I am not 100% sure about the keycloak-authorization.
Rather leaving to you to decide if it's generally useful or not). The
keycloak-wsfed is already on the extensions page.
Thanks!
Marek
On 10/08/18 11:44, Doswald Alistair wrote:
> Hello,
>
> I just wanted to let this mailing list know that for the Cloudtrust
project (https://github.com/cloudtrust), we have developed a certain
number modules for Keycloak. These are currently compatible with the
version 3.4.3.Final of Keycloak, but we will make them compatible with
Keycloak 4.X (where X will be the latest sub-version of Keycloak when we
start working on this) as soon as we can. These modules are:
>
> * keycloak-wsfed (https://github.com/cloudtrust/keycloak-wsfed): an
implementation of the WS-Federation protocol for keycloak. This allows to
select the WS-Federation protocol for Keycloak clients and for identity
brokers.
>
> * keycloak-authorization (
https://github.com/cloudtrust/keycloak-authorization): this module allows
the use of the client authorization system to prevent a user which is
authenticated in a Keycloak realm to access a given client. It works no
matter which protocol is used, and without the client having to support any
extra protocol. Note: this solution is a bit hacky, but necessary for one
of our use-cases.
>
> * keycloak-client-mappers (
https://github.com/cloudtrust/keycloak-client-mappers): a module for
adding any mappers that we might need that are not yet part of Keycloak.
Currently only contains a JavaScript mapper for SAML, analogous to the OIDC
script mapper. I've noticed that there's an open issue for this feature (
https://issues.jboss.org/browse/KEYCLOAK-5520). If desirable I could
submit this code not as a module but a solution to the issue.
>
> * keycloak-export (https://github.com/cloudtrust/keycloak-export): a
module adding an endpoint to fully export a realm while Keycloak is still
running (no need for restarts!).
>
> Cheers,
>
> Alistair
>
> PS: I'm mailing this both dev and user mailing lists as I believe it may
interest members of both mailing lists
> _______________________________________________
> keycloak-user mailing list
> keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
1963
days inactive
2085
days old
7 comments
4 participants
participants (4)
-
Doswald Alistair -
Marek Posolda -
Meissa M'baye Sakho -
Pedro Igor Silva