Re: [keycloak-dev] Keycloak Modules developed for the Cloudtrust project

Hello, I meant to send you this mail last week, but somehow I left it in my drafts. For the keycloak export module, we have not added any special mechanisms to the standard full export, so all the problems you mention are valid. However, in our use case we run keycloak with high availability, and there’s no possibility to shut keycloak completely down for the current full export system. However, there are some benefits to having a full export ,which we require. for example: * It allows us to have a simple logical export of the database. This export can be used to quickly set up a test system. It is also easier to transform via scripts if we have some more complex changes to perform upon the data than a standard database export (in which case we would export, run scripts and reimport). * It allows us to get the complete persistent state for any of our clients which have problems, without having to plan a maintenance shutdown From our point of view, doing a full export or a partial export while keycloak is running amounts to the same thing. In both cases there’s a risk of inconstancies during the export, though there’s definitely more chance of inconstancies with the full export. Therefore, we shift the difficulty to our import process, which must be able to detect such inconsistencies. Sections with problems can be dropped or corrected manually/via script. I can certainly understand why you don’t want an endpoint that can return secrets, however by restricting to admin access and with https communication it’s not much different than viewing the information in the admin GUI. The size of the export is however a concern, and as you say, saving it on a disk is not practical. In our architecture, we have an interface in front of keycloak through which all API request and responses must pass. We can have this interface provide the necessary buffering/streaming mechanisms in order to transmit the large data to the requestor. Cheers, Alistair From: Stian Thorgersen <sthorger(a)redhat.com&gt; Sent: jeudi 16 août 2018 10:30 To: Doswald Alistair <alistair.doswald(a)elca.ch&gt; Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org&gt; Subject: Re: [keycloak-dev] Keycloak Modules developed for the Cloudtrust project On Tue, 14 Aug 2018 at 12:03, Doswald Alistair <alistair.doswald@elca.ch<mailto:alistair.doswald@elca.ch>> 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. This is great and pleased that you are maintaining this. We simply don't have the capacity to have this incorporated into Keycloak as we lack expertise on WS-Fed and have to many other things to maintain. * 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. Sounds interesting. Can you write some more details about this? In the past I've considered if we should have something like required roles to use to a client. That would by not allowing a user to authenticate with a client, but also could prevent adding audience for a service the user isn't allowed to access. Could perhaps take it one step further and prevent client scopes that users are not allowed to access. * 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. SAML JavaScript protocol mapper would be great. If you submit with tests and docs we'd love to have this in. * 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!). Can you write some more details about this? In the past we've considered this, but not added it mainly for a few reasons, including: * What happens if there are changes while doing the export, we where thinking we'd have to pause the server from receiving requests during this export * We don't want a REST endpoint that can return credentials and other secrets. Then there's also the size of the export. It would have to store the export on disc, but then what about clustering. One potential would be to develop a tool that can be executed from anywhere that has access to the db. It would use Keycloak code base, but instead of starting a server it would allow things like running an export from the db, migrate the db, etc. Cheers, Alistair PS: I mailed this to both dev and user mailing lists as I believe it may interest members of both mailing lists. However, upon sending to the dev mailing list the first time it bounced. This is the second attempt. _______________________________________________ keycloak-dev mailing list keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev