<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">+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.<br>
<br>
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.<br>
<br>
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)<br>
<br>
Marek<br>
<br>
On 05/10/15 20:33, Stan Silvert wrote:<br>
</div>
<blockquote cite="mid:5612C27F.9080809@redhat.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 10/5/2015 2:26 PM, Thomas Raehalme
wrote:<br>
</div>
<blockquote
cite="mid:CAPyAMobeFGVWgVhyWaE+dxtwr-v89T=Nx993w6whjYrTNKpu5g@mail.gmail.com"
type="cite">
<p dir="ltr"><br>
On Oct 5, 2015 21:24, "Bill Burke" <<a
moz-do-not-send="true" href="mailto:bburke@redhat.com"><a class="moz-txt-link-abbreviated" href="mailto:bburke@redhat.com">bburke@redhat.com</a></a>>
wrote:<br>
><br>
> I'm still averse to allowing export from admin console of
any<br>
> credentials or private keys.</p>
<p dir="ltr">Even if they are not directly downloadable but
require access to the server just like now?<br>
</p>
</blockquote>
I think there should be no secrets ever downloadable from admin
console. Admin console is, by definition, remote.<br>
<br>
If you have access to the server then you can use what is there
now.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAPyAMobeFGVWgVhyWaE+dxtwr-v89T=Nx993w6whjYrTNKpu5g@mail.gmail.com"
type="cite">
<p dir="ltr"><br>
</p>
<p dir="ltr">><br>
> On 10/5/2015 2:02 PM, Stan Silvert wrote:<br>
> > I'm actually starting on the design and
implementation of this right<br>
> > now. It's import/export from the admin console. It
will also have the<br>
> > ability to import/export partial pieces of a realm
such as just users.<br>
> ><br>
> > Thanks for the comments so far on this thread. They
have been very helpful.<br>
> ><br>
> > We will keep the idea that no secrets should ever be
exported from admin<br>
> > console. I'm not sure that having a flag for it in
keycloak-server.json<br>
> > helps. To edit keycloak-server.json, you need
access to the server, in<br>
> > which case you might as well do the current
import/export.<br>
> ><br>
> > So what do you do after you import a user with no
credentials? Some ideas:<br>
> > * The administrator can reset the password manually.<br>
> > * The user can do password recovery (if enabled)<br>
> ><br>
> > An other ideas?<br>
> ><br>
> > Stan<br>
> ><br>
> > On 10/5/2015 12:34 PM, Tim Dudgeon wrote:<br>
> >> That's a good point. Having to stop/start the
server to generate an<br>
> >> export is not ideal.<br>
> >><br>
> >> Tim<br>
> >><br>
> >> On 05/10/2015 11:56, Thomas Raehalme wrote:<br>
> >>><br>
> >>><br>
> >>> On Mon, Oct 5, 2015 at 2:47 AM, Bill Burke
<<a moz-do-not-send="true" href="mailto:bburke@redhat.com">bburke@redhat.com</a><br>
> >>> <mailto:<a moz-do-not-send="true"
href="mailto:bburke@redhat.com">bburke@redhat.com</a>>>
wrote:<br>
> >>><br>
> >>> On 10/4/2015 5:37 PM, Thomas Raehalme
wrote:<br>
> >>><br>
> >>><br>
> >>> On Oct 4, 2015 23:57, "Bill Burke"
<<a moz-do-not-send="true" href="mailto:bburke@redhat.com">bburke@redhat.com</a><br>
> >>> <mailto:<a moz-do-not-send="true"
href="mailto:bburke@redhat.com">bburke@redhat.com</a>
<mailto:<a moz-do-not-send="true"
href="mailto:bburke@redhat.com">bburke@redhat.com</a>>>>
wrote:<br>
> >>> ><br>
> >>> > For security reasons we did
not want to have a remote<br>
> >>> option to export.<br>
> >>><br>
> >>><br>
> >>> How about just storing the export as a local
file on the server?<br>
> >>> You'd need access to the server in order to
get the file (making the<br>
> >>> system compromised anyways). The change to
current behaviour is that<br>
> >>> you would be able to trigger the export at
will without server restart.<br>
> >>><br>
> >>> Best regards,<br>
> >>> Thomas<br>
> >>><br>
> >>><br>
> >>>
_______________________________________________<br>
> >>> keycloak-user mailing list<br>
> >>> <a moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> >>> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
> >><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> keycloak-user mailing list<br>
> >> <a moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> >> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > keycloak-user mailing list<br>
> > <a moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> > <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
> ><br>
><br>
> --<br>
> Bill Burke<br>
> JBoss, a division of Red Hat<br>
> <a moz-do-not-send="true"
href="http://bill.burkecentral.com">http://bill.burkecentral.com</a><br>
> _______________________________________________<br>
> keycloak-user mailing list<br>
> <a moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-user mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-user">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
</body>
</html>