Repository navigation
Trying to understand import/export #19107
|
I have a server where I need to clone one realm into many others. I want basically all the configuration copied. When I try to make this work, some of the information is imported into the new realm, but nothing under the "Realm Settings" is set. As an example, this is part of the export.json file. I expect when I import into the new realm it will set the SMTP settings. However they are definitely not getting set. I may be misunderstanding how the import works. How do you import ALL setting (except the realm ID and name) to a new realm? "smtpServer": {
"replyToDisplayName": "",
"starttls": "false",
"auth": "",
"port": "25",
"host": "smtp.imsweb.com",
"replyTo": "no-reply@imsweb.com",
"from": "seertransfer@seerdms.com",
"fromDisplayName": "SEER*Transfer",
"envelopeFrom": "",
"ssl": "false"
}I imported using these settings. and here is the summary After the import I verified that none of those fields were set in "Email" tab of realm settings in the new realm. |
Replies: 2 comments 7 replies
|
I believe you've run into the "partial" part of Partial Import/Export. To import/export the entire configuration, you have to do it at server startup. See https://www.keycloak.org/server/importExport |
|
So for me to accomplish this, I need command-line access to the server. Once I have that, I need to manually edit the export file to change the realm ID and name and then place it in the the correct directory. Then I need to run the command-line method to restart the server and import it on startup. Is that correct? If so, that is crazy. I'm pretty sure we don't want to give additional people access to the command-line. Maybe my situation is unique, but I need to have 25 or so realms that are almost identical. Just a few things like SSO configuration are different. I guess I will have to do the partial import then have a checklist of things I need to go back and set manually each time. |
|
I've found using scripts with the admin CLI to be a much better solution than the import/export piece of Keycloak when it comes to re-producing Keycloak config. Figuring out the commands is tricky since it isn't well documented, but once you have them it is a much more reliable way to configure Keycloak as it allows you to break the import into small pieces when needed. |
All reactions
|
After playing with this for a while, I think you are correct. I will be able to write a script to do all this. I am still struggling a bit figuring out how to set some of the entities like SAML mappers, but I'm pretty sure I can figure it out. Thanks again. |
|
Never needed the mappers, but to take advantage of the Keycloak ability to obtain JSON configuration from SAML XML metadata URL here is an example with latest Keycloak: https://stackoverflow.com/a/75794013/562644 |
|
After fighting with this I ended up just doing a full export. I got about 75% of the way there with the admin CLI and I definitely preferred that method, however that last 25% was just very difficult since the documentation is so light. Full export on one server ./kc.sh export --file ~/export.json --realm my_realm--users skipand then a full import on the other server ./kc.sh import --file ~/export.jsonFrom my testing it is importing everything. It's a little strange that after importing you have to restart the instance to get the new realm to show up, but I can live with that. I'm not sure why Keycloak doesn't support a "full" import/export from the UI. Thanks again for all your suggestions. |
|
@ctmay4 @slominskir I have one use case that I need to export all the data from one realm but I don't want specific admin user password to be restored when importing it to new realm so that I can set a new one while setting it up and not want to use old one. Is there something which keycloak provides which can exclude specific passwords while exporting or maybe some another solution outside of keycloak ? |
|
Do you mean the master realm admin password? You could switch to using admin CLI to re-configure Keycloak to avoid that. If you do go the admin CLI approach and treat Keycloak like a caching and integration layer then for custom realms you probably need to store your users in LDAP and then Keycloak is just glue and chicken wire for web protocols. |
I've found using scripts with the admin CLI to be a much better solution than the import/export piece of Keycloak when it comes to re-producing Keycloak config. Figuring out the commands is tricky since it isn't well documented, but once you have them it is a much more reliable way to configure Keycloak as it allows you to break the import into small pieces when needed.