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:
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(a)jlab.org>
To: "Marek Posolda" <mposolda(a)redhat.com>
Cc: "keycloak-user" <keycloak-user(a)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(a)redhat.com>
To: "Ryan Slominski" <ryans(a)jlab.org>, "keycloak-user"
<keycloak-user(a)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(a)lists.jboss.org
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user