[keycloak-user] External Username, Password, Email... dataset with Keycloak

Tue Feb 7 10:21:06 EST 2017

Is there anyone who would know what would need to be changed to make the migration provider work with Keycloak >= 2.5.0?

Thanks,

Reed

On 1/27/17, 12:48 PM, "keycloak-user-bounces at lists.jboss.org on behalf of Reed Lewis" <keycloak-user-bounces at lists.jboss.org on behalf of RLewis at carbonite.com> wrote:

    [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

    Scott,
       We are using your keycloak migration provider from here: https://github.com/Smartling/keycloak-user-migration-provider

    But the issue it seems is that version 2.50 and above of Keycloak has removed the AP that was being used.   Is there any way to easily migrate the code to use whatever Keycloak provides now?

    Thank you,

    Reed Lewis

    From: Scott Rossillo <srossillo at smartling.com>
    Date: Wednesday, January 27, 2016 at 1:02 PM
    To: Reed Lewis <RLewis at carbonite.com>
    Cc: Thomas Darimont <thomas.darimont at googlemail.com>, "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
    Subject: Re: [keycloak-user] External Username, Password, Email... dataset with Keycloak

    I think that’s a more general question about user account merging so maybe one of the core devs can chime in. However, I just want to clarify, you don’t want to query the federation provider at all when a user signs in with external IDP, right? In that case, you could modify the findByUsername() method to not create a user if the login is with a IDP.  I’m not sure if it still exists in 1.7+ but the username used to be created as idp.email at provider.com<mailto:idp.email at provider.com> where the IDP is the username prefix.

    Does that make sense / sufficiently address the use case?

    ~ Scott
    On Jan 27, 2016, at 12:34 PM, Reed Lewis <RLewis at carbonite.com<mailto:RLewis at carbonite.com>> wrote:

    This is working for me now.  I created a service that listens on a port and implements the GET, HEAD and POST requests that are being made.

    The one issue now is that integration with other Identity providers does not work now since it still calls my server with the username from the external provider.    How can I tell Keycloak that when a user comes from an external Identity provider not to check the user Federation provider?

    Thank you,

    Reed Lewis

    From: Scott Rossillo <srossillo at smartling.com<mailto:srossillo at smartling.com>>
    Date: Friday, January 15, 2016 at 4:42 PM
    To: Thomas Darimont <thomas.darimont at googlemail.com<mailto:thomas.darimont at googlemail.com>>, Reed Lewis <RLewis at carbonite.com<mailto:RLewis at carbonite.com>>
    Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
    Subject: Re: [keycloak-user] External Username, Password, Email... dataset with Keycloak

    We just put up and blog post[0] and some sample code[1] on how to do this type of migration.

    [0]: http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
    [1]: https://github.com/Smartling/keycloak-user-migration-provider

    Scott Rossillo
    Smartling | Senior Software Engineer
    srossillo at smartling.com<mailto:srossillo at smartling.com>

    [atest News + Events]<https://app.sigstr.com/uc/55e5d41c6533390d03580000>
    [owered by Sigstr]<http://www.sigstr.com/>

    On Jan 15, 2016, at 11:06 AM, Thomas Darimont <thomas.darimont at googlemail.com<mailto:thomas.darimont at googlemail.com>> wrote:

    Hello Reed,

    as you already wrote, you can write a federation provider that queries your
    backend service via REST for user data.
    Within the federation provider you can then import the user data
    returned from the REST call.

    This would work as follows - within the method:
      org.keycloak.models.UserFederationProvider.getUserByUsername(RealmModel, String)
    you call your backend REST service.

    As a next step you create a new user with the given username
      UserModel keycloakUser = session.userStorage().addUser(realm, username);

    Then you copy all the user data from your backend into Keycloak's UserModel.

    After that your backend user has a corresponding representation in Keycloak
    with a reference to this federation provider (id) via the "userModel.federationLink" property.

    The federation link will also be shown in the user page in the keycloak admin console.
    As long as the federation link is in place keycloak will ask the federation provider
    for the latest user data. Once you decide to cut the link to the federation provider you can
    simply do userModel.setFederationLink(null). You could basically cut (or rather omit) the federation
     link right after you added the user to Keycloak.

    Keycloak has no link information after that anymore and it will only use the user data stored
    in the Keycloak database for that particular user.

    You also have the option to do that for all your users via:
      org.keycloak.models.UserFederationProviderFactory.syncAllUsers(KeycloakSessionFactory, String, UserFederationProviderModel)
    or just use on demand per User when he / she want's to login for the first time.

    Cheers,
    Thomas

    2016-01-15 16:16 GMT+01:00 Reed Lewis <RLewis at carbonite.com<mailto:RLewis at carbonite.com>>:
    Hi,
       We are examining KeyCloak (It looks like it can do what we want), but we have the need to have an external lookup of accounts who are not in KeyCloak in an external database which is accessible via a REST call.   I know about federation, but would prefer to only check the external datasource if the user is not in KeyCloak, but from then on have all the data “live” in KeyCloak and never refer to the external datasource again once the account is “migrated” into KeyCloak.

    Can this be done with some modification of federation?

    We do not want to add the user accounts directly into KeyCloak as there are many more there than will ever be in KeyCloak.

    Thank you,

    Reed Lewis

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

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