[keycloak-user] Multiple User Storage Providers

Marek Posolda mposolda at redhat.com
Wed May 2 06:54:43 EDT 2018


I don't have any good suggestion for it besides what you mentioned. 
Especially considering that Cross-Realm trust is not an option for you.

I think you should be able to achieve this, but you will need to do some 
customizations (maybe in both the default "browser" authentication flow 
as you need to detect correct identityProvider based on Kerberos ream 
and not sure if parameter "kc_idp_hint" is enough for your usecase. Also 
in the first-broker-login flow as I mentioned in the JIRA). Or with some 
tweaks on clients as you pointed.

Marek

On 01/05/18 20:19, Ryan Slominski wrote:
> 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=




More information about the keycloak-user mailing list