[keycloak-user] Keycloak Modules developed for the Cloudtrust project

Mon Dec 10 01:16:08 EST 2018

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 at 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/keycloak-export.tar.gz
> 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 at redhat.com> <msakho at redhat.com>
> *Sent:* jeudi 6 décembre 2018 16:59
> *To:* Doswald Alistair <alistair.doswald at elca.ch>
> <alistair.doswald at elca.ch>
> *Cc:* Pedro Igor Silva <psilva at redhat.com> <psilva at redhat.com>; Marek
> Posolda <mposolda at redhat.com> <mposolda at redhat.com>; keycloak-user
> <keycloak-user at lists.jboss.org> <keycloak-user at lists.jboss.org>; Issa
> Gueye - Red Hat <igueye at redhat.com> <igueye at 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 at 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 at redhat.com>
> Sent: vendredi 10 août 2018 18:52
> To: Marek Posolda <mposolda at redhat.com>
> Cc: Doswald Alistair <alistair.doswald at elca.ch>;
> keycloak-user at 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 at redhat.com
> <mailto:mposolda at 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 at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>