[keycloak-user] Multiple User Storage Providers

Dominik Guhr pinguwien at gmail.com
Wed May 2 03:53:20 EDT 2018


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://github.com/keycloak/keycloak/tree/master/examples 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.



Am 01.05.18 um 20:19 schrieb Ryan Slominski:
> Hi Marek,
>    I'm looking for comments and suggestions on integrating multiple Kerberos realms into a single Keycloak realm (SSO namespace).  I initially overlooked the possibility of using identity provider brokering, but I'm not 100% sure that's the best option.  Here is a summary of ways I've discovered so far:
> 
> 1. Use identity provider brokering.  However, automatically linking accounts without prompting users to authenticate is not supported (https://issues.jboss.org/browse/KEYCLOAK-7270).  This kind-of defeats the purpose as users end up having to provide both credentials to create the link and login.
> 2. Create a new custom user storage provider.  Looks very complicated and fragile.  Any examples of this to look at?  Would this even work with SPNEGO for either or only for one?
> 3. Figure out what the heck configuring a Keycloak realm with multiple user storage providers and ordering them is supposed to do.  Still very confused as why you can configure it.  If Keycloak tried one and then tried the next if the first failed that would be great (account lockout from incorrect password count threshold would need to be set high on first one, but probably fine).
> 4. Use client-side multi-tenancy.  Each client can choose which Keycloak realm to authenticate to.  Each Keycloak realm has a different Kerberos realm in a one-to-one mapping.  This creates a complicated logic burden on clients and must be duplicated on all clients, and SSO token generated would vary based on actual realm chosen as opposed to having a single universal SSO token for the domain.
> 5. Use Kerberos Cross-Realm trusts.  Probably works, but Jira suggests this is untested (https://issues.jboss.org/browse/KEYCLOAK-3842).  This is not a great option in our case because we only trust users from the other realm on the web, not on workstations or anywhere else and don't want to change what "anyone with an account" means, and introduce extra risk requiring assigning users to a new group and relying on group authorization.
> 6. Instead of Keycloak just use mod_auth_kerb and SSSD (https://www.freeipa.org/page/Web_App_Authentication).  A hack integration, but might be easier.
> 
> What have others done?  Thoughts?  Suggestions?  None of these options are great.
> 
> Thanks,
> 
> Ryan
> 
> ----- Original Message -----
> From: "Ryan Slominski" <ryans at jlab.org>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: "keycloak-user" <keycloak-user at lists.jboss.org>
> Sent: Friday, February 9, 2018 9:46:25 AM
> Subject: Re: [keycloak-user] Multiple User Storage Providers
> 
> Thanks Marek,
>      I am using 3.4.3, but the two Kerberos realms are not configured in a cross realm trust (I want the web apps in one specific Keycloak realm to trust either realm, but that trust shouldn't be universal and System Admins don't want to trust other realms for Workstation logins and cross realm trust would require new authorization considerations as it changes what "anyone with an account" means).  Is cross realm trusts the only way to do what I'm after?
> 
> Ryan
> 
> ----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Ryan Slominski" <ryans at jlab.org>, "keycloak-user" <keycloak-user at lists.jboss.org>
> Sent: Friday, February 9, 2018 9:04:56 AM
> Subject: Re: [keycloak-user] Multiple User Storage Providers
> 
> Hi,
> 
> which Keycloak version are you using? In 3.4.3, we added support for the
> scenario when the kerberos realms are in trust with each other (hence
> you need just 1 LDAP/Kerberos UserStorageProvider and 1 keytab). Could
> you try with 3.4.3 and see if it helps? Otherwise please create JIRA
> with the steps to reproduce and ideally with server.log (with DEBUG
> option enabled on LDAP storage providers and with DEBUG logging
> described in "Troubleshooting" section of our Kerberos documentation).
> 
> Thanks,
> Marek
> 
> Dne 9.2.2018 v 14:51 Ryan Slominski napsal(a):
>> Hi Keycloak users,
>>      I'm looking for tips on how to migrate from mod_auth_kerb to Keycloak.  I have two Kerberos realms, and one is a subset of the other: DOMAIN.ORG and INTERNAL.DOMAIN.ORG.  The mod_auth_kerb handles this scenario beautifully and I simply have a service principal for each Kerberos realm in the keytab and Apache httpd will login the user if they are in either of the Kerberos realms.  For Keycloak adding two Kerberos user storage providers, one at priority 1, and another at priority 2 doesn't seem to work.  Only the first one used.  What are other people doing to handle this?  Creating a custom User Storage Provider?  Client side multitenancy?  Perhaps if I use two LDAP servers instead of two KDCs it could work (I assume from the priority field of user storage provider API that something must be allowed to be paired together)?
>>
>> Thanks,
>>
>> Ryan
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_keycloak-2Duser&d=DwICBA&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=EMs2e6afv3D1GQJO76Z9Fg&m=9_qBWrxq5tF_Bbe0PAmmj-8rJvJEqkjkYTpziWQCTcU&s=jJplqt7pC9jx8uJECGPSSPspXnqit8NW_PCQsYQLpug&e=
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_keycloak-2Duser&d=DwICAg&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=EMs2e6afv3D1GQJO76Z9Fg&m=ufW-OP9-MV3Q3mSloIGuJcHrBSGg7qKIebHqnDymvHw&s=6VMy3ja1363CkFlvHEdMpai2wE-QjiEQb3T7eh5nDNE&e=
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 


More information about the keycloak-user mailing list