[keycloak-user] [EXTERNAL] Re: Trust between two standalone Keycloak Instances
luis.villaca at petrobras.com.br
luis.villaca at petrobras.com.br
Mon Jul 22 11:05:58 EDT 2019
Hi Aditya,
Related to this comment:
> I’ve successfully established an SSO by using KA as a broker and KB as an
IDP. But this is only a master slave kind-of an architecture. When I log in
to A, I’m automatically logged into B. But if I log into B, I won’t be
automatically logged into A. Is it possible for KA to be a broker for KB
and KB to be a broker for KA at the same time?
First, let me say Stan comments makes a lot of sense to me - I was also not
convinced yet that you really need different instances/realms.
It seems to me the transition for the calls between your products would be
handled fine with a single realm. Yet, I am sharing my (short) experience
if you do..
In my case, I created realms isolating calls to our corporate
authentication + authorization services (re-evaluating it btw). So I
created different realms, where each one maintains users with different
roles (related to different solutions we have - each solution holds many
systems). Those roles are shared among clients from each realm (e.g.
microservices).
I also created one authentication-only realm - in my case with a user
federation plugin that calls our corporate authentication Service (maybe
LDAP for you).
So all realms delegate authentication (via identity provider, pointing to
the same broker) to this authentication-only realm, and this way we achieve
SSO.
Regards,
Luis
De: "Aditya Bhole" <Aditya.Bhole at veritas.com>
Para: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
Data: 18/07/2019 19:23
Assunto: Re: [keycloak-user] [EXTERNAL] Re: Trust between two standalone
Keycloak Instances
Enviado por: keycloak-user-bounces at lists.jboss.org
Hi Stan,
We have 3 enterprise products deployed in their own environments. Now, some
of our clients use all three products, some use just one and some use any
two of them. Each product is a separate with its own bundled software and
not related to the others. So what we want to do is to include Keycloak in
each bundle. But there are cases where even from these unrelated products,
we need an option for cross product transition.
For that to happen, we need to establish trust between all these separate
Keycloak instances. So even if we deploy a new product with Keycloak in its
bundle, we would just need to establish trust with the existing system of
Keycloak Instances. So is there a way that a token generated by one of the
Keycloak instances is accepted by the other Keycloak instances?
Also, in domain mode, if we deploy two Keycloak instances separately as
master, later if we decide to keep one as master and make the other one a
slave, is that possible?
And about the local settings, say for example, if I had to connect an LDAP
for just one of the hosts, can that be done?
Thanks,
Aditya
On 7/17/19, 3:05 PM, "keycloak-user-bounces at lists.jboss.org on behalf of
Stan Silvert" <keycloak-user-bounces at lists.jboss.org on behalf of
ssilvert at redhat.com> wrote:
Yes, it can be done, but I still don't understand why you would want to
do it this way. You can also establish trust between two realms on the
same server. That way, you don't need multiple instances of Keycloak
to
have the apps be fully walled off from each other.
That being said, I still don't understand why you wouldn't just do it
the easy way. Are you saying that sometimes you want SSO and sometimes
you don't? I must be missing something from your use case.
Lastly, the domain features of WildFly are just used to centrally
manage
instances of the server. These servers can be configured any way you
want. I guess this depends on what you mean by "local settings".
On 7/16/2019 1:26 PM, Aditya Bhole wrote:
> I understand that deploying 3 clients under one realm will easily
enable SSO. Even if we keep the clients in different realms, cross-realm
trust can be established. But the use case of our prototype wants the
clients to be on different servers. I’ll try to explain as best as I can.
>
> Our company has 3 products deployed independently and these are
managed by different administrators. Sometimes these have to be integrated
with each other for seamless cross product experience at which time we
would want SSO between the individual product UIs. We intend to use
Keycloak as a broker for authentication and to achieve SSO. So that’s why I
wanted to know if trust between two standalone Keycloak instances can be
established.
>
> Also, if we deploy the domain controller, can there still be local
settings on the different Keycloak instances?
>
> Thanks,
> Aditya
>
> On 7/15/19, 12:25 PM, "keycloak-user-bounces at lists.jboss.org on
behalf of Stan Silvert" <keycloak-user-bounces at lists.jboss.org on behalf of
ssilvert at redhat.com> wrote:
>
> Why do you need each to have its own Keycloak instance? A usual
setup
> would define all three clients in the same realm under the same
Keycloak
> instance.
>
> On 7/15/2019 1:23 PM, Aditya Bhole wrote:
> > Hello,
> >
> > I’m new to Keycloak and building a prototype SSO framework for
my company. The use case is that my company has 3 clients; A, B and C. Now
each client is going to have its own Keycloak instance; KA, KB and KC. Now
what I want is when I login through client A I should be logged into client
B and C as well. And same goes for all the clients. So for this to happen,
is there a way of establishing trust between these three Keycloak instances
KA, KB and KC?
> > I’ve successfully established an SSO by using KA as a broker
and KB as an IDP. But this is only a master slave kind-of an architecture.
When I log in to A, I’m automatically logged into B. But if I log into B, I
won’t be automatically logged into A. Is it possible for KA to be a broker
for KB and KB to be a broker for KA at the same time?
> > TL;DR :
> > Is there a way where Keycloak only acts as a broker and trust
is established between multiple such Keycloak instances?
> >
> > I hope my question makes sense. Please point me in the right
direction if I’m looking at this in the wrong way.
> >
> > Thanks,
> > Aditya
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
"O emitente desta mensagem é responsável por seu conteúdo e endereçamento. Cabe ao destinatário cuidar quanto ao tratamento adequado. Sem a devida autorização, a divulgação, a reprodução, a distribuição ou qualquer outra ação em desconformidade com as normas internas do Sistema Petrobras são proibidas e passíveis de sanção disciplinar, cível e criminal."
"The sender of this message is responsible for its content and addressing. The receiver shall take proper care of it. Without due authorization, the publication, reproduction, distribution or the performance of any other action not conforming to Petrobras System internal policies and procedures is forbidden and liable to disciplinary, civil or criminal sanctions."
"El emisor de este mensaje es responsable por su contenido y direccionamiento. Cabe al destinatario darle el tratamiento adecuado. Sin la debida autorización, su divulgación, reproducción, distribución o cualquier otra acción no conforme a las normas internas del Sistema Petrobras están prohibidas y serán pasibles de sanción disciplinaria, civil y penal."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20190722/cf04eb82/attachment.gif
More information about the keycloak-user
mailing list