Marek,
Thank you very much for the information and the leads!  That should get me a good ways towards my goal.


Mike,
If you do get to that blog post, please post your link, I'd really like to check it out.


Thomas,
Thank you for the links, they are very helpful!  The example User Federation Provider appears to be close to what I'll need to implement.  It's just missing the part where the external data source is kept in sync.


jim


On Wed, Jun 1, 2016 at 3:41 AM, Marek Posolda <mposolda@redhat.com> wrote:
On 01/06/16 03:20, Jim Dillon wrote:
It looks like a custom User Federation Provider in needs to be created in order to access a REST Service for user information and an Authentication Provider to authenticate against a REST Service.

I've looked at the example User Federation Provider that uses a static file and the Authentication Provider examples which enforce secret question / answer flow. I have a better understanding of what needs to be accomplished, but I'm still quite a ways from where I need to be.

Can anyone point me in the direction of an example User Federation Provider and / or an Authentication Provider that uses a REST Service?  (Google hasn't found any examples for me.)

Is there more documentation to be found on these subjects other than the inline code comments, User Manual, and github based docs?

Could I possibly be making it more difficult than it is, do I simply need to substitute http requests for file i/o in the User Federation Provider example?
I think yes, that's what you can to do. And I think that you don't need to implement any Authentication Provider, really just an User Federation Provider.

The Authentication Provider is used if you need to somehow change the authentication flow (for example add some new form with new login mechanism), however here you don't need it. Here the flow is like this:

  1. User lands on Keycloak login page and initiates login. This is done with the standard Keycloak login form for username/password. So you don't need any custom Authentication provider.
  2. User does not exist in Keycloak
  3. Keycloak asks User storage (UserFederationManager), which will try to lookup user in it's database and if it doesn't exists in database, then will lookup via your UserFederationProvider. So it will call method YourUserFederationProvider.getUserByUsername . In this method, you are supposed to implement calling your REST API and lookup user and then create user into Keycloak DB
  4. User is authenticated - Keycloak will call YourUserFederationProvider.validCredentials where you are supposed to implement validation of username/password against your REST service
  5. You can implement the proxy object for your user where you can control which info exactly is retrieved from/to Keycloak DB and which is retrieved from/to your REST service.

Note that registering user back to REST service is done via YourUserFederationProvider.register . So always when new user is created in Keycloak, it will call this method of your FederationProvider and you are supposed to "register" user in your REST service too. Via the User proxy object, you can control when your REST service needs to be updated (for example if you implement user.setEmail in your proxy and call the REST service here, then Keycloak will call this method and hence your REST service always when email of some user is changed.

And btv. you can try to contact the guys from RH jboss.org team, which did some UserFederationProvider calling REST. It's possible that your implementation will be similar. You can try velias@redhat.com and/or lkrzyzan@redhat.com .

Marek


The Flow (as I understand it, please confirm / correct as needed):
  1. User lands on Keycloak login page and initiates login
  2. User does not exist in Keycloak
  3. REST API is asked to authenticate via Authentication Provider SPI
  4. User is authenticated
  5. REST API is asked for user information to create user in Keycloak (part of this process would need to decrypt the existing password and then encrypt it using Keycloak's "default" method.)
  6. User is created in Keycloak and any further authentication / authorization logic will remain "in house"

Thank you for your time,

jim



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