Batch importing of users

[mbyrdap]

Is your feature request related to a problem? Please describe.

Being as every bit of infrastructure seems to be moving to IaC style provisioning and deployment, I thought being able to turn up an IDM server with kanidm, and have the users present to get working, would be a good idea.

Describe the solution you'd like

A simple command line parameter with a filename as an argument to add/update/set the users with their authentication options.

Describe alternatives you've considered

a messy bash script

Additional context

[yaleman]

infrastructure as code, sure, deploy the binary and the configuration - but like with a database, you don't specify the full contents of it from your code... this what a backup's for, and that functionality's already in the system.

If someone wanted to wrangle the golang to make a terraform module for doing the various configuration bits for OAuth RS'en and service accounts... that'd be neat, maybe?

[Firstyear]

Well we still need a way to batch import users and details anyway so I'm not opposed to this. But I want to think about it and design it nicely for certain.

[mbyrdap]

but like with a database, you don't specify the full contents of it from your code... this what a backup's for, and that functionality's already in the system.

Why would you not deploy your IDM with an accurate data source?

For HA, portable, scaling, onprem + cloud presence, etc., what sense is it restoring a backup vs keeping the internal state of users accurate at deployment?

[yaleman]

Sorry if it came off wrong, that was a late-night response I could have worded better.

Scoping the request's important because we already have a lot of tools floating around and things like the SCIM endpoints; extending the iam-migrations package would allow for batch creation for people doing migrations.

For HA, portable, scaling, onprem + cloud presence, etc.

Clustering/sync (in development now) and backups covers all of these options, especially considering the token encryption requirements in the backend.

Again, I'm not against this, I just want to try and make sure we're not trying to oversell things or reinvent the wheel.

[Firstyear]

I think improving our batch operation interfaces and user creation mechanisms is the way to go here, but having uses in a "config" file I'm not sure about yet. I can see it both ways that it would be valuable to template and create these, but I can also see that it adds a complexity once we have replication (we'd essentially need to create an equivalent of the MS AD FSMO roles then.).

[Firstyear]

@mbyrdap I'm coming back to this ATM and I'm wondering if this is solved via a scim endpoint you can issue updates to.

Or is this that you want a fileshare that picks up changes and can apply them?

[Firstyear]

I think this is actually solved by #211