Batch import/export
by Stian Thorgersen
After your last email with regards to removing the import button from
client create page I had an idea.
How about we do the following:
Import/export single
--------------------------
On realm, client, identity provider and user federation create pages we add
the import button. This will prefill the form and let the user review
before importing. This is how realm and client works now. We'd also add a
link to export a single entity when displaying it in the admin console
(next to the delete icon).
Batch export
-----------------
When exporting a realm you can select what you want to export. The option
would include realm settings, clients, identity brokers, user federation,
users, credentials. Further there would be an option if export would be
done to a file or a json download. If export to file is selected you would
get the option to export credentials for users, if json download is
selected that option would be disabled.
Batch import
-----------------
We should have options to import a realm as well as import into an existing
realm. For this we should have an option to select what happens if
resources exists (for example client with client-id exists, or user with
username exists). Options could be replace, skip, warn, error, etc..
Finally I was also thinking about an option where we'd have a import
directory on the server. Any files in this would be imported on startup.
Once imported we'd add a "<filename>.imported" or "<filename>.failed". Same
here it would be nice to be able to somehow specify the strategy if the
resource exists.
10 years
Considering to introduce release candidates
by Stian Thorgersen
Lately we've been following a pretty aggressive release schedule with a new
Final released every 4 to 6 weeks. We want to continue having frequent
releases, but at the same time it would be good to give people the
opportunity to test things out in advance of a release.
I propose we continue doing releases every 4-6 weeks, but instead of going
straight to Final we'll release a CR1. If there are no high priority issues
reported against within a week we'll release the Final. Otherwise we'll
release CR2, but this time reduce the wait to roughly half a week before
releasing Final (or CR3).
We would not support migrating between CR releases as they are purely
targeted towards testing. These releases should only be used in
staging/test environments. Ideally with a copy of the production database.
Basically that would mean that upgrading from 1.6.0.Final to 1.7.0.CR1 and
then upgrading to 1.7.0.Final would not work. You would have to upgrade
directly from 1.6.0.Final to 1.7.0.Final.
I'd like to ask the community is this something that would be beneficial?
Would you actually play with and test release candidates, or would you
simply wait for the Final to be released?
10 years
keycloak admin access in order to crate users
by Ian Hamilton
Hi All,
I am new to redHat and my role is to set up automation test frameworks for developers.redhat.com.
I would like to know how to gain permissions to Keycloak admin in order create/delete new users on the fly in the tests using the Keycloak REST API? Or what the usual process is for creating users via the Keycloak.
The reason for this is; when we make a new user for a test, we have a "clean slate" which allows us great control over how to shape that user for our test. And if we make that user using a REST API call, we avoid the time penalty of having to fill out a sign-up form (not to mention having to find any emails involved in confirming an email address).
I would like to be able to do this locally, as well as in the staging environments.
Could anyone point me in the right direction?
thanks in advance,
Ian
10 years
Access datasource from a CLI
by Stian Thorgersen
It would be nice to have an "offline" cli that can be used to configure
Keycloak. If we roll our own CLI for that and it uses jboss-modules do you
reckon we can get access to the datasources somehow? This is for things
like setting the admin password, import/export from cli, etc..
10 years
Ability to set hostname for server
by Stian Thorgersen
Currently we have a few people having issues with the fact that we use the
URL of the request as the hostname for Keycloak. For example to get the
address sent in emails or as the iss value in tokens. This works fine as
long as everyone accesses it using the proper domain name. However, it
doesn't work when servers are on the same local network use the direct IP
address or internal hostname.
The simplest solution to this would be to add an option to set the hostname
for the server. This would be configured in keycloak-server.json, but we'd
also support setting it with a system property. Default would be to use the
request-url as we do now, but once specified we would not use the
request-url anymore and always use the configured hostname as the base URL.
10 years
Event log consistency - EventBuilder using client.getClientId()
by Tomas Kyjovsky
EventBuilder uses client.getClientId() when building new events instead of client.getId() - which is the real "primary key" for the entity. This may cause problems with consistency of the event log. A client can be removed and a new one created with the same clientId but different id.
On the other hand, the clientId attribute is also useful when filtering the log.
Tomas
10 years
Autogeneration of admin-client REST API
by Marek Posolda
Was wondering if resteasy has some way to autogenerate REST endpoints
inside integration/admin-client to be automatically synced with the REST
endpoints from keycloak-services ?
So for example when I add new REST endpoint on server-side into
org.keycloak.services.resources.RealmsResource class, the admin-client
class org.keycloak.admin.client.resource.RealmsResource will be
automatically updated too . Ideally there can be maven target executed
on demand for update admin-client sources. That would help to avoid
unsynced endpoints in admin-client - issues like
https://issues.jboss.org/browse/KEYCLOAK-1967 .
Marek
10 years
