[keycloak-dev] Import proposal

[Stian Thorgersen]

On 9 November 2015 at 13:35, Sebastien Blanc <sblanc at redhat.com> wrote:

> That would be really nice indeed !
> But are the markers files not enough, instead of also having a table in
> the DB ?
>

We need a way to prevent multiple nodes in a cluster to import the same
file. For example on Kerberos you end up spinning up multiple instances of
the same Docker image.


>
>
> On Mon, Nov 9, 2015 at 1:20 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Currently we support importing a complete realm definition using the
>> import/export feature. Issues with the current approach is:
>>
>> * Only complete realm - not possible to add to an existing realm
>> * No good feedback if import was successful or not
>> * Use of system properties to initiate the import is not very user
>> friendly
>> * Not very elegant for provisioning. For example a Docker image that
>> want's to bundle some initial setup ends up always running the import of a
>> realm, which is skipped if realm exists
>>
>> To solve this I've come up with the following proposal:
>>
>> Allow dropping representations to be imported into 'standalone/import'.
>> This should support creating a new realm as well as importing into an
>> existing realm. When importing into an existing realm we will have an
>> import strategy that is used to configure what happens if a resource exists
>> (user, role, identity provider, user federtation provider). The import
>> strategies are:
>>
>> * Skip - existing resources are skipped,
>> * Fail - if any resource exists nothing is imported
>> * Overwrite - any existing resources are deleted.
>>
>> The directory will be scanned at startup, but there will also be an
>> option to monitor this directory at runtime.
>>
>> To prevent a file being imported multiple times (also to make sure only
>> one node in a cluster imports) we will have a table in the database that
>> contains what files was imported, from what node, date and result
>> (including a list of what resources where imported, which was not, and
>> stack trace if applicable). The primary key will be the checksum of the
>> file. We will also add marker files (<json file>.imported or <json
>> file>.failed). The contents of the marker files will be a json object with
>> date imported, outcome (including stack trace if applicable) as well as a
>> complete list of what resources was successfully imported, what where not.
>>
>> The files will also allow resolving system properties and environment
>> variables. For example:
>>
>> {
>>     "secret": "${env.MYCLIENT_SECRET}"
>> }
>>
>> This will be very convenient for example with Docker as it would be very
>> easy to create a Docker image that extends ours to add a few clients and
>> users.
>>
>> It will also be convenient for examples as it will make it possible to
>> add the required clients and users to an existing realm.
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151109/e73b6657/attachment.html