+1 on not allow remote export from admin console with possibility to download file . However I am not seeing a problem with allowing export from admin console as long as the exported file is downloaded to the server filesystem - either to specified file or directory. As mentioned by Thomas, the advantage of this is, that you can do export at runtime without need to restart server.

However there is one tricky with export at runtime, that some user may do modifications when export is in progress (For example some user registers himself or changes his stuff in account management). This may results in broken data/inconsistencies. And that's the main reason why the export is currently allowed just at the startup when server is not yet opened for any requests from users. This can be likely handled somehow - for example with the locking servlet filter, which will block any requests to server when export is in progress etc.

Another good thing to add might be the "progress" table. This can be useful when admin has some very large database with million of users and export can take 10 hours or so. So admin will be able to go to the table and check the progress of export task (500.000 users already exported, 500.000 users still remaining, expected time to end: 3 hours 30 minutes) etc. This stuff might be good for other long running tasks in Keycloak as well (like syncing users from federation provider when you have million users in LDAP etc)

Marek

On 05/10/15 20:33, Stan Silvert wrote:
On 10/5/2015 2:26 PM, Thomas Raehalme wrote:


On Oct 5, 2015 21:24, "Bill Burke" <bburke@redhat.com> wrote:
>
> I'm still averse to allowing export from admin console of any
> credentials or private keys.

Even if they are not directly downloadable but require access to the server just like now?

I think there should be no secrets ever downloadable from admin console.  Admin console is, by definition, remote.

If you have access to the server then you can use what is there now.

It is possible, however, that when we do our CLI implementation we can verify that the user is local and allow full access.  That way, you could do full export on a running server.  WildFly CLI already has logic to verify a user is local.


>
> On 10/5/2015 2:02 PM, Stan Silvert wrote:
> > I'm actually starting on the design and implementation of this right
> > now.  It's import/export from the admin console.  It will also have the
> > ability to import/export partial pieces of a realm such as just users.
> >
> > Thanks for the comments so far on this thread.  They have been very helpful.
> >
> > We will keep the idea that no secrets should ever be exported from admin
> > console.  I'm not sure that having a flag for it in keycloak-server.json
> > helps.  To edit keycloak-server.json, you need access to the server, in
> > which case you might as well do the current import/export.
> >
> > So what do you do after you import a user with no credentials? Some ideas:
> > * The administrator can reset the password manually.
> > * The user can do password recovery (if enabled)
> >
> > An other ideas?
> >
> > Stan
> >
> > On 10/5/2015 12:34 PM, Tim Dudgeon wrote:
> >> That's a good point. Having to stop/start the server to generate an
> >> export is not ideal.
> >>
> >> Tim
> >>
> >> On 05/10/2015 11:56, Thomas Raehalme wrote:
> >>>
> >>>
> >>> On Mon, Oct 5, 2015 at 2:47 AM, Bill Burke <bburke@redhat.com
> >>> <mailto:bburke@redhat.com>> wrote:
> >>>
> >>>     On 10/4/2015 5:37 PM, Thomas Raehalme wrote:
> >>>
> >>>
> >>>         On Oct 4, 2015 23:57, "Bill Burke" <bburke@redhat.com
> >>>         <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> wrote:
> >>>          >
> >>>          > For security reasons we did not want to have a remote
> >>>         option to export.
> >>>
> >>>
> >>> How about just storing the export as a local file on the server?
> >>> You'd need access to the server in order to get the file (making the
> >>> system compromised anyways). The change to current behaviour is that
> >>> you would be able to trigger the export at will without server restart.
> >>>
> >>> Best regards,
> >>> Thomas
> >>>
> >>>
> >>> _______________________________________________
> >>> keycloak-user mailing list
> >>> keycloak-user@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>
> >>
> >>
> >> _______________________________________________
> >> keycloak-user mailing list
> >> keycloak-user@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user



_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user