Export/import implementation
by Marek Posolda
I am planning to start soon on export/import. If I recall correctly, one
of the requirements is to export the content of whole DB content
(including IDs and password hashes) to JSON file, which can then be
later imported into other DB. This will allow to migrate between
environments and various DB types (For example from Mongo to MySQL and
viceversa).
I have some question though
1) I assume that DB should be cleared before full import from JSON file?
Or do we want to update existing data without deleting the previous
content? I assume that this is used for migration, so it's not about
updating but completely delete and recreate existing DB, correct?
2) How to implement it. I can see two approaches
a) Use model API to retrieve content of the DB into JSON file during
export. Similarly during import use model API to sync objects back from
JSON into model DB.
b) Add some methods to KeycloakSession interface like:
ObjectNode export();
void import(ObjectNode node);
and implement export/import separately for each model.
Approach (b) might be better for performance as it allows to directly
use low-level queries specific to JPA, Mongo or other model
implementations to export/import stuff more effectively in batch,
however it will require changes in model implementations and probably
adding more stuff into dependencies. So I am more convinced to use (a).
Thoughts?
3) How will be export/import triggered?
I think that for security reasons, we want to always export into local
file with KC server and similarly always import from local file. Is it
correct? I can see approaches like:
a) Use KC admin console. By default, just "admin" will be able to
export/import stuff . Data will be always exported/imported into JSON
file local to server. So it will be possible to trigger export/import
remotely from admin console, but just use local JSON file. The import
would be tricky though as import will recreate all data (including admin
realm and admin user) so it would need to cancel logout sessions
including the session of admin user who triggered import.
b) Use some script, which will trigger JVM process for export/import
data. Script can be executed locally from CMD. I can imagine something
like this (executed from the directory with AS7/wildfly server):
./bin/keycloak-import -Dkeycloak.model=jpa
-Ddata-to-import=/tmp/file-with-full-kc-data-to-import-which-were-previously-exported.json
Assumption is that distribution contains deployed KC inside
standalone/deployments/auth-server.war. Script will be able to run JVM
which will have access to needed KC jars on classpath and access to
persistence.xml . In AS7/Wildfly environment the persistence.xml bundled
inside auth-server.war is using datasource though, so this JVM process
would also need to parse datasource from
standalone/configuration/standalone.xml as it won't be executed in
managed AS7/Wildfly environment.
c) Use something similar to approach (b) but execute export/import from
AS7/Wildfly CLI or admin console. The advantage is that it is triggered
from the managed (AS7 or Wildfly) so has access to server resources like
datasource referenced from persistence.xml
Any other possibility I am missing?
Thanks,
Marek
11 years, 12 months
Account management requirements for beta1
by Stian Thorgersen
With regards to account management what additional requirements do we have for beta1?
Features I can think off to add now or in the future includes:
* Manage refresh tokens - view applications and clients that have refresh tokens, and the ability to invalidate specific tokens
* Manage devices - view browsers and devices that have access (remember me cookie?), and the ability to invalidate specific cookies
* Manage devices that can bypass totp - it seems to be quite common that it's possible to not require asking for totp again for a specific device, I assume this is done by setting a cookie, if we enable this it should be possible to view what devices have this option, as well as invalidate them
* Manage applications - view all applications, be able to navigate to an application, and the ability to invalidate access to specific application
* Manage clients - view all clients and what grants they have, and the ability to revoke access to specific client
I think listing client grants, invalidate specific client grants, and a logout everything option would be sufficient. The logout everything option would invalidate any refresh tokens, remember me cookies, 'skip' totp cookies and do a sso-logout.
11 years, 12 months
isolate picketlink dependency please
by Bill Burke
Mongo model project seems to have picketlink dependencies:
org.picketlink.common
These need to be isolated and removed as a dependency. Since we may be
introducing Keycloak into EAP (via Aerogear) we want to be sure we can
remove any version conflicting picketlink dependencies. So, anything
picketlink related has to be behind a plugglable and removable SPI.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
Broke model tests
by Stian Thorgersen
Some idiot (me) have broken the tests. Will fix it asap!
12 years
Admin resources moved
by Stian Thorgersen
I've moved resources for admin-ui to 'forms/common-themes/src/main/resources/theme/admin/base'. The admin console now has theme support.
For example by starting the server with:
bin/standalone.sh -Dkeycloak.theme.admin=patternfly
You'll get the standard PatternFly l&f in the console
12 years
Theme support for admin console
by Stian Thorgersen
I'm working on adding theme support to the admin console, and the plan was to use the what we have for login and account forms.
To get this to work I can either use a Servlet or a JAX-RS endpoint to deliver resources. My preference is to use JAX-RS and have everything done through RestEasy, effectively dropping Servlets (and web fragments). This would also let us drop '/rest' from the other endpoints (so it would be '/realms/keycloak-admin/tokens/login' instead of '/rest/realms/keycloak-admin/tokens/login').
12 years
KeyCloak and HornetQ REST?
by Matt Casperson
We have a need for browser based apps to interact with a message queue, and the HornetQ REST interface looks like it could serve us quite well. Since the HornetQ REST interface uses RESTEasy, is it possible to secure it like any other REST service via KeyCloak?
Regards
Matthew Casperson
RHCE, RHCJA, RHCJD # 111-072-237
Engineering Content Services
Brisbane, Australia
12 years
