2:10 p.m.
+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(a)redhat.com
> <mailto: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(a)redhat.com
> <mailto:bburke@redhat.com>
> > >>> <mailto: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(a)redhat.com
> <mailto:bburke@redhat.com>
> > >>> <mailto:bburke@redhat.com
<mailto: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(a)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
> > >
> > >
> > >
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org <mailto: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(a)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
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user