[keycloak-user] Multiple User Storage Providers

[Ryan Slominski]

Hey Dominik,
   Now I understand: the multiple user storage providers is for when you have multiple database of **unique** usernames.  In my case I have two databases and one is a subset of the other (100% duplicates) and there is a one-to-one match of usernames/email addresses.  In other words the company has an LDAP database and the department has its own database with a subset of global users so we can enforce a separate unique password for some "special" systems.  However, on the web either password should work.  It sounds like the custom authenticator might be a good option.  Would SPNEGO still work for either (the example doesn't show an API for dealing with that)?

Thanks,

Ryan

----- Original Message -----
From: "Dominik Guhr" <pinguwien at gmail.com>
To: "keycloak-user" <keycloak-user at lists.jboss.org>
Sent: Wednesday, May 2, 2018 3:53:20 AM
Subject: Re: [keycloak-user] Multiple User Storage Providers

Hi Ryan,

here a few thoughts and suggestions from my side:

For a customer, I implemented a kc 3.4.3 custom user storage provider 
for his "old" applicationdb, together with 2 Kerberos-using ldap 
providers which I added via admin page. This works very well, so-far, so 
what exactly does not work with your providers and priority?! Why is 
"only the first one used"? What you mention in 3., is the "normal" way 
to go in keycloak(*)

That said, there are several examples on github here: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_keycloak_keycloak_tree_master_examples&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=EMs2e6afv3D1GQJO76Z9Fg&m=bPuihQi6FebCvHuJGaT1rDWdzTD42bMpITuAcUq9ugI&s=rVRfGKour9FxxtowmX-BextsQy1Mftw7plhn2paK_44&e=  which are a 
great starting point.

(*) Might have something to do with this:

In the scenario I mentioned, it's possible that the usernames are not as 
unique as they should be. There's a john.doe in ldap1 and a john.doe in 
ldap2, different companies etc..

So, keycloaks "normal" flow is: look in provider 1 -> username matches? 
great! Password matches? Nope! -> send error!

we had the requirement to use a multi-password approach, which was quite 
easy to setup with a custom authenticator which does it like this:

look in provider 1 -> username matches? great! password matches? nope! 
-> go over all the ldaps of the realm and search for same username -> 
yep, there's one -> match pw -> ok, login!

Feel free to reach out if that might be the problem.