Allow me some rubber-ducking here..

1) Add user attributes (old salt, etc.) when migrating a user
2) Implement authenticator that:
  2.1) Get user by username/email, if not present, fail
  2.2) Retrieve user attributes
  2.3) If user attributes include old salt, hence user has been migrated, hash input password (cleartext) and pass it to context.getSession().users().validCredentials(...)
  2.4) If user attributes don't include old salt, hence user was created in KC, pass input password(cleartext) to context.getSession().users().validCredentials(...)

If this is proven to work - and there's no better way to do it - one may verify validCredentials(...) return-value, and if it is validated successfully, and the user is migrated, can we replace current user model password with a new one?

Pires 

On Fri, Jul 22, 2016 at 10:41 AM Paulo Pires <pires@littlebits.cc> wrote:
Updated PR!

But now I'm hitting another wall: password migration.

The app I'm replacing generated a random salt per user, stored it and then used SHA-512(password, iterations, pepper, salt) to hash the password - iterations and pepper are static. Now, I want to import this to Keycloak and use bcrypt to hash the old hash. Obviously, I'll still need to be able to generate the old hash when validating on KC log-in, right?

I also want that new users to just have bcrypt and not the old hashing thing.

Now, I know that I can implement a PasswordHashProvider, but I'm not sure exactly where to store and how to read information like the old salt, or how to split between users that were migrated and need to use old hash + brcrypt hash AND users that were created directly in KC and just need bcrypt hash.

Any help is highly appreciated,
Pires

On Thu, Jul 21, 2016 at 1:46 PM Paulo Pires <pires@littlebits.cc> wrote:
Oh, awesome! Going to add tests, open JIRA ticket and update PR.

Thanks Stian,
Pires

On Thu, Jul 21, 2016 at 1:13 PM Stian Thorgersen <sthorger@redhat.com> wrote:

On 21 July 2016 at 13:13, Paulo Pires <pires@littlebits.cc> wrote:
I went ahead, cowboy style and opened a PR for it https://github.com/keycloak/keycloak/pull/3056

Couldn't find tests so didn't add any.

Pires

On Thu, Jul 21, 2016 at 12:06 PM Paulo Pires <pires@littlebits.cc> wrote:
Something like this should work though:

@GET
@Produces({"application/json"})
@Path("default-roles")
List<RoleRepresentation> getDefaultRoles();

@PUT
@Path("default-roles/{roleId}")
void addDefaultRole(@PathParam("roleId") String roleId);

@DELETE
@Path("default-roles/{roleId}")
void removeDefaultRole(@PathParam("roleId") String roleId);

On Thu, Jul 21, 2016 at 12:03 PM Paulo Pires <pires@littlebits.cc> wrote:
It's working like a charm :)

Some things I learned:
* Need to import resteasy deps for keycloak-admin-cli explicitly
* Methods won't return errors but will throw InvocationTargetException (must be checked)

Question: is there a way to set default roles? I can't seem to find it in the Java code but it is available through REST.

Thanks,
Pires

On Thu, Jul 21, 2016 at 8:47 AM Paulo Pires <pires@littlebits.cc> wrote:
Thank you Bruno, I haven't been able to verify your code but I assume you're sharing it because it works.

It seems pretty trivial, awesome!

Cheers,
Pires

On Wed, Jul 20, 2016 at 9:30 PM Bruno Oliveira <bruno@abstractj.org> wrote:
Note sure if it helps, but an example about how to do it
programatically is here[1].

I just adapted from the admin-client[2].


[1] - https://gist.github.com/abstractj/78b127e8c9273cdcea6eb82a1cfc153c
[2] - https://github.com/keycloak/keycloak/tree/master/examples/admin-client

On 2016-07-20, Paulo Pires wrote:
> I did check the admin-cli JAR but it's not clear how to add roles and
> users, or if it's even implemented (I did check the REST API and there's
> endpoints for that).
>
> Thank you very much for clarifying,
> Pires
>
> On Wed, Jul 20, 2016 at 2:52 PM Stian Thorgersen <sthorger@redhat.com>
> wrote:
>
> > Yep, take a look at
> > https://keycloak.gitbooks.io/server-developer-guide/content/topics/admin-rest-api.html
> >
> > On 20 July 2016 at 15:33, Paulo Pires <pires@littlebits.cc> wrote:
> >
> >> More than 150k. Is there a Java library for the REST api?
> >>
> >> On Jul 20, 2016 13:56, "Stian Thorgersen" <sthorger@redhat.com> wrote:
> >>
> >>> Depending on the amount of users I'd use either partial import through
> >>> the admin console (if you don't have more than a thousand or so users) or
> >>> use the admin REST endpoints if you have quite a lot of users.
> >>>
> >>> On 20 July 2016 at 11:52, Paulo Pires <pires@littlebits.cc> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> I'm in the process of migrating from an in-house user-role storage to
> >>>> Keycloak and I'm looking for programmatic (Java) ways to migrate all
> >>>> current users to the new storage. And I need your help to figure out the
> >>>> best approach.
> >>>>
> >>>> At first, when reading KC documentation, I believed I could easily
> >>>> achieve this by implementing a User Federation provider but after diving a
> >>>> little more into it, and looking for examples, I can't see a way to migrate
> >>>> all users on-demand but simply one user at a time, possible during log-in.
> >>>>
> >>>> Next, I tried and look into ways, such as admin-cli, REST, etc but
> >>>> nothing strikes me as the solution to use.
> >>>>
> >>>> Here's what I was hoping to deliver:
> >>>> * Get all roles and users from my soon-to-be deprecated storage, e.g.
> >>>> MySQL tables
> >>>> * Add roles to KC
> >>>> * Iterate users and add user to KC + map roles + update password hashes
> >>>> (here I know I need to implement a HashProvider)
> >>>>
> >>>> Any hints will be appreciated!
> >>>>
> >>>> Pires
> >>>>
> >>>> _______________________________________________
> >>>> keycloak-user mailing list
> >>>> keycloak-user@lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>>>
> >>>
> >>>
> >

> _______________________________________________
> keycloak-user mailing list
> keycloak-user@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


--

abstractj
PGP: 0x84DC9914