On another subject, @User and others here, there is a compelling use case for providing SOME mechanism via the Admin API to import existing users with existing passwords. It is very, very important for the following reasons: • When our customers want to move from another identity management solution to Kratos, it is simply NOT reasonable to expect potentially thousands of users to reset their passwords when a conversion is done. It is very hard to defend that for users regardless of the security concerns. For that reason, perhaps a protected Admin API requiring a special admin key to get access should be considered and an endpoint added supporting this ONLY for the identity system owners. • I have several use cases where we are utilizing the multiple identity schema feature to support scenarios where a customer wants to share a single identity for a group of users. In our last implementation, our customer sells access to content and content management to police departments and other first responder agencies. Each of these agencies shares a single identifier and password for the entire agency. Our back end is multi-tenant, so we key off that identity to ensure that those users access the right content. The sales process involves an agency giving us this information to set up on their behalf. A registration/recovery email workflow is not really appropriate for this. • Our deployment process for the entire suite of microservices that include Kratos sets up a SINGLE administrative "God" user for the system. From there, that God users invites all other users using the standard secure workflow (create identity and invite to complete registration with their password via recovery link). However, the God user must exist first (chicken or the egg). We have solved some of this by building a "sidecar" service/container that, in our Kubernetes installation, activates after Kratos has been been created in the cluster. This sidecar has a "migrate" style feature that, based on configuration, will create that first user when run as an "init container". It also exposes an API that allows for the creation of a user with a password if authorized by a "God" user type (known by JWT using Oathkeeper access rules and mutation). In order to pull this off, however, I have to fake Kratos out by running the entire sequence that would normally be executed by a browser to create the identity, create a recovery link, and then POST to that recovery link with cookies passed along and the

user-agent

set to assure Kratos thinks it is talking to a browser to complete the operation. That is a lot of work and not really proper process--it's a hack. However, it is the only way to automate a necessary process. Any thoughts on that?

Hey travis, we are aware of the import password feature, there's an open PR for it, did you see it? https://github.com/ory/kratos/pull/2151

I had not seen that, @User! Thanks for that. When will this be merged? This can save me some work that is in progress....

Depends a bit on how active the contributors are but we plan on merging it soon as it's a common request

It is in a blocked state right now, but I will pull the code and use it...

@User Cool, we have almost a similar app but we refer to the "God" as "Super Admin" 😃

Would you be willing to share yours? As soon as we are done we will share ours on GitHub.

Oh Sorry mate, its a private repo for a client but I will definitely check out yours if you don't mind

Hey, no problem! We should be finished with our implementation by Thursday. I will share it then. This is all going to be a part of an article series I will be posting on Medium on the production use of Kratos on a real scalable Kubernetes application.