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(a)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(a)redhat.com and/or
lkrzyzan(a)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
listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user