3:54 p.m.
Hi,
first of all, congrats on the beta 1 release!
Here's my question: I have a WAR with a REST API that I'm securing with
Keycloak. Now I'd like to add multitenancy support.
If I understand the concept in keycloak correctly, I would somehow have to
have several realms in the keycloak.json and the web.xml of the war, right?
However there is just one realm-name attribute in the web.xml and the
structure of keycloak.json also looks like it is intended for one realm. Am
I missing something?
Cheers,
Nils
4:04 p.m.
Somebody else was asking for this feature. We may have to add it beta 2
even though I wanted to have a feature freeze.
How did you expect it to work? One guy wanted to discover realm per
request via parsing the URL. Another guy just wanted multi-realm
support for bearer-only services.
On 5/29/2014 4:54 PM, Nils Preusker wrote:
Hi,
first of all, congrats on the beta 1 release!
Here's my question: I have a WAR with a REST API that I'm securing with
Keycloak. Now I'd like to add multitenancy support.
If I understand the concept in keycloak correctly, I would somehow have
to have several realms in the keycloak.json and the web.xml of the war,
right? However there is just one realm-name attribute in the web.xml and
the structure of keycloak.json also looks like it is intended for one
realm. Am I missing something?
Cheers,
Nils
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:28 a.m.
Hi Bill,
what I was thinking of was tenants as nested element within a realm.
We'd like to be able to add tenants at runtime. That's where I see a
problem with multi-realm support, since realms are "hardcoded" in the
keycloak.json. So if you add a realm in the admin-console, with multi-realm
support you'd still have to modify the deployed WAR by adding the new realm
to the keycloak.json file.
I was thinking of a structure like this:
|- realm
| |-users
| |-realm-level-user-1
| |-...
|-tenants
| |-tenant-1
| | |-users
| | | |-tenant-level-user-1
| | | |-...
Let me know what you think!
Cheers,
Nils
On Thu, May 29, 2014 at 11:04 PM, Bill Burke <bburke(a)redhat.com> wrote:
Somebody else was asking for this feature. We may have to add it
beta 2
even though I wanted to have a feature freeze.
How did you expect it to work? One guy wanted to discover realm per
request via parsing the URL. Another guy just wanted multi-realm
support for bearer-only services.
On 5/29/2014 4:54 PM, Nils Preusker wrote:
> Hi,
>
> first of all, congrats on the beta 1 release!
>
> Here's my question: I have a WAR with a REST API that I'm securing with
> Keycloak. Now I'd like to add multitenancy support.
>
> If I understand the concept in keycloak correctly, I would somehow have
> to have several realms in the keycloak.json and the web.xml of the war,
> right? However there is just one realm-name attribute in the web.xml and
> the structure of keycloak.json also looks like it is intended for one
> realm. Am I missing something?
>
> Cheers,
> Nils
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
11:05 a.m.
I don't what the different between a tenant and a realm would be in your
example.
On 5/30/2014 5:28 AM, Nils Preusker wrote:
Hi Bill,
what I was thinking of was tenants as nested element within a realm.
We'd like to be able to add tenants at runtime. That's where I see a
problem with multi-realm support, since realms are "hardcoded" in the
keycloak.json. So if you add a realm in the admin-console, with
multi-realm support you'd still have to modify the deployed WAR by
adding the new realm to the keycloak.json file.
I was thinking of a structure like this:
|- realm
| |-users
| |-realm-level-user-1
| |-...
|-tenants
| |-tenant-1
| | |-users
| | | |-tenant-level-user-1
| | | |-...
Let me know what you think!
Cheers,
Nils
On Thu, May 29, 2014 at 11:04 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Somebody else was asking for this feature. We may have to add it beta 2
even though I wanted to have a feature freeze.
How did you expect it to work? One guy wanted to discover realm per
request via parsing the URL. Another guy just wanted multi-realm
support for bearer-only services.
On 5/29/2014 4:54 PM, Nils Preusker wrote:
> Hi,
>
> first of all, congrats on the beta 1 release!
>
> Here's my question: I have a WAR with a REST API that I'm
securing with
> Keycloak. Now I'd like to add multitenancy support.
>
> If I understand the concept in keycloak correctly, I would
somehow have
> to have several realms in the keycloak.json and the web.xml of
the war,
> right? However there is just one realm-name attribute in the
web.xml and
> the structure of keycloak.json also looks like it is intended for one
> realm. Am I missing something?
>
> Cheers,
> Nils
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:12 p.m.
Hi Bill,
I guess you are right, there isn't really a difference. It would just be
important to be able to add realms at runtime. Are you suggesting to have
nested realms (just replacing tenant with realm in my previous example)?
Does that make more sense?
Cheers,
Nils
On Fri, May 30, 2014 at 6:05 PM, Bill Burke <bburke(a)redhat.com> wrote:
I don't what the different between a tenant and a realm would be
in your
example.
On 5/30/2014 5:28 AM, Nils Preusker wrote:
> Hi Bill,
>
> what I was thinking of was tenants as nested element within a realm.
>
> We'd like to be able to add tenants at runtime. That's where I see a
> problem with multi-realm support, since realms are "hardcoded" in the
> keycloak.json. So if you add a realm in the admin-console, with
> multi-realm support you'd still have to modify the deployed WAR by
> adding the new realm to the keycloak.json file.
>
> I was thinking of a structure like this:
>
> |- realm
> | |-users
> | |-realm-level-user-1
> | |-...
> |-tenants
> | |-tenant-1
> | | |-users
> | | | |-tenant-level-user-1
> | | | |-...
>
> Let me know what you think!
> Cheers,
> Nils
>
>
>
>
>
>
>
>
> On Thu, May 29, 2014 at 11:04 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> Somebody else was asking for this feature. We may have to add it
beta 2
> even though I wanted to have a feature freeze.
>
> How did you expect it to work? One guy wanted to discover realm per
> request via parsing the URL. Another guy just wanted multi-realm
> support for bearer-only services.
>
>
> On 5/29/2014 4:54 PM, Nils Preusker wrote:
> > Hi,
> >
> > first of all, congrats on the beta 1 release!
> >
> > Here's my question: I have a WAR with a REST API that I'm
> securing with
> > Keycloak. Now I'd like to add multitenancy support.
> >
> > If I understand the concept in keycloak correctly, I would
> somehow have
> > to have several realms in the keycloak.json and the web.xml of
> the war,
> > right? However there is just one realm-name attribute in the
> web.xml and
> > the structure of keycloak.json also looks like it is intended for
one
> > realm. Am I missing something?
> >
> > Cheers,
> > Nils
> >
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org <mailto:
keycloak-user(a)lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
1:16 p.m.
Sorry, I just noticed that my example was wrong...
here is what I meant:
|- realm
| |-users
| | |-realm-level-user-1
| | |-...
| |-tenants
| | |-tenant-1
| | | |-users
| | | | |-tenant-level-user-1
| | | | |-...
However, nested realms would be an alternative I guess.
Cheers,
Nils
On Fri, May 30, 2014 at 8:12 PM, Nils Preusker <n.preusker(a)gmail.com> wrote:
Hi Bill,
I guess you are right, there isn't really a difference. It would just be
important to be able to add realms at runtime. Are you suggesting to have
nested realms (just replacing tenant with realm in my previous example)?
Does that make more sense?
Cheers,
Nils
On Fri, May 30, 2014 at 6:05 PM, Bill Burke <bburke(a)redhat.com> wrote:
> I don't what the different between a tenant and a realm would be in your
> example.
>
> On 5/30/2014 5:28 AM, Nils Preusker wrote:
> > Hi Bill,
> >
> > what I was thinking of was tenants as nested element within a realm.
> >
> > We'd like to be able to add tenants at runtime. That's where I see a
> > problem with multi-realm support, since realms are "hardcoded" in the
> > keycloak.json. So if you add a realm in the admin-console, with
> > multi-realm support you'd still have to modify the deployed WAR by
> > adding the new realm to the keycloak.json file.
> >
> > I was thinking of a structure like this:
> >
> > |- realm
> > | |-users
> > | |-realm-level-user-1
> > | |-...
> > |-tenants
> > | |-tenant-1
> > | | |-users
> > | | | |-tenant-level-user-1
> > | | | |-...
> >
> > Let me know what you think!
> > Cheers,
> > Nils
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, May 29, 2014 at 11:04 PM, Bill Burke <bburke(a)redhat.com
> > <mailto:bburke@redhat.com>> wrote:
> >
> > Somebody else was asking for this feature. We may have to add it
> beta 2
> > even though I wanted to have a feature freeze.
> >
> > How did you expect it to work? One guy wanted to discover realm per
> > request via parsing the URL. Another guy just wanted multi-realm
> > support for bearer-only services.
> >
> >
> > On 5/29/2014 4:54 PM, Nils Preusker wrote:
> > > Hi,
> > >
> > > first of all, congrats on the beta 1 release!
> > >
> > > Here's my question: I have a WAR with a REST API that I'm
> > securing with
> > > Keycloak. Now I'd like to add multitenancy support.
> > >
> > > If I understand the concept in keycloak correctly, I would
> > somehow have
> > > to have several realms in the keycloak.json and the web.xml of
> > the war,
> > > right? However there is just one realm-name attribute in the
> > web.xml and
> > > the structure of keycloak.json also looks like it is intended
> for one
> > > realm. Am I missing something?
> > >
> > > Cheers,
> > > Nils
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org <mailto:
> keycloak-user(a)lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org
> >
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
2:13 p.m.
Why do you need to add realms at runtime? You haven't adequately
described your use case.
On 5/30/2014 2:12 PM, Nils Preusker wrote:
Hi Bill,
I guess you are right, there isn't really a difference. It would just be
important to be able to add realms at runtime. Are you suggesting to
have nested realms (just replacing tenant with realm in my previous
example)?
Does that make more sense?
Cheers,
Nils
On Fri, May 30, 2014 at 6:05 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
I don't what the different between a tenant and a realm would be in your
example.
On 5/30/2014 5:28 AM, Nils Preusker wrote:
> Hi Bill,
>
> what I was thinking of was tenants as nested element within a realm.
>
> We'd like to be able to add tenants at runtime. That's where I see a
> problem with multi-realm support, since realms are "hardcoded" in
the
> keycloak.json. So if you add a realm in the admin-console, with
> multi-realm support you'd still have to modify the deployed WAR by
> adding the new realm to the keycloak.json file.
>
> I was thinking of a structure like this:
>
> |- realm
> | |-users
> | |-realm-level-user-1
> | |-...
> |-tenants
> | |-tenant-1
> | | |-users
> | | | |-tenant-level-user-1
> | | | |-...
>
> Let me know what you think!
> Cheers,
> Nils
>
>
>
>
>
>
>
>
> On Thu, May 29, 2014 at 11:04 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>
> <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> wrote:
>
> Somebody else was asking for this feature. We may have to
add it beta 2
> even though I wanted to have a feature freeze.
>
> How did you expect it to work? One guy wanted to discover
realm per
> request via parsing the URL. Another guy just wanted multi-realm
> support for bearer-only services.
>
>
> On 5/29/2014 4:54 PM, Nils Preusker wrote:
> > Hi,
> >
> > first of all, congrats on the beta 1 release!
> >
> > Here's my question: I have a WAR with a REST API that I'm
> securing with
> > Keycloak. Now I'd like to add multitenancy support.
> >
> > If I understand the concept in keycloak correctly, I would
> somehow have
> > to have several realms in the keycloak.json and the web.xml of
> the war,
> > right? However there is just one realm-name attribute in the
> web.xml and
> > the structure of keycloak.json also looks like it is
intended for one
> > realm. Am I missing something?
> >
> > Cheers,
> > Nils
> >
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
<mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
<mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:59 p.m.
Hi Bill,
our use case is as follows: we are developing an application that is
deployed as a software as a service solution. Each customer gets their own
"application instance", but all instances are served by the same WAR. Since
some customers have several instances (i.e. for departments or divisions),
it would not be accurate to say customer = realm. So we need another level,
which is what I mean when I say tenant. The users would then be
sub-elements of the tenants. However, there is one special scenario: some
customers wish to have the same users in multiple tenants.
Finally, we want to be able to add customers and instances (or tenants) at
runtime.
Mapped to my sketch from before, customers could be represented by realm
(if there is multi-realm support), "application instances" are tenants and
users can be created both on realm and on tenant level.
What do you think?
Cheers,
Nils
On Fri, May 30, 2014 at 9:13 PM, Bill Burke <bburke(a)redhat.com> wrote:
Why do you need to add realms at runtime? You haven't
adequately
described your use case.
On 5/30/2014 2:12 PM, Nils Preusker wrote:
> Hi Bill,
>
> I guess you are right, there isn't really a difference. It would just be
> important to be able to add realms at runtime. Are you suggesting to
> have nested realms (just replacing tenant with realm in my previous
> example)?
>
> Does that make more sense?
> Cheers,
> Nils
>
>
> On Fri, May 30, 2014 at 6:05 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> I don't what the different between a tenant and a realm would be in
your
> example.
>
> On 5/30/2014 5:28 AM, Nils Preusker wrote:
> > Hi Bill,
> >
> > what I was thinking of was tenants as nested element within a
realm.
> >
> > We'd like to be able to add tenants at runtime. That's where I
see a
> > problem with multi-realm support, since realms are "hardcoded"
in
the
> > keycloak.json. So if you add a realm in the admin-console, with
> > multi-realm support you'd still have to modify the deployed WAR by
> > adding the new realm to the keycloak.json file.
> >
> > I was thinking of a structure like this:
> >
> > |- realm
> > | |-users
> > | |-realm-level-user-1
> > | |-...
> > |-tenants
> > | |-tenant-1
> > | | |-users
> > | | | |-tenant-level-user-1
> > | | | |-...
> >
> > Let me know what you think!
> > Cheers,
> > Nils
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, May 29, 2014 at 11:04 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>
> > <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>>
wrote:
> >
> > Somebody else was asking for this feature. We may have to
> add it beta 2
> > even though I wanted to have a feature freeze.
> >
> > How did you expect it to work? One guy wanted to discover
> realm per
> > request via parsing the URL. Another guy just wanted
multi-realm
> > support for bearer-only services.
> >
> >
> > On 5/29/2014 4:54 PM, Nils Preusker wrote:
> > > Hi,
> > >
> > > first of all, congrats on the beta 1 release!
> > >
> > > Here's my question: I have a WAR with a REST API that
I'm
> > securing with
> > > Keycloak. Now I'd like to add multitenancy support.
> > >
> > > If I understand the concept in keycloak correctly, I would
> > somehow have
> > > to have several realms in the keycloak.json and the
web.xml of
> > the war,
> > > right? However there is just one realm-name attribute in
the
> > web.xml and
> > > the structure of keycloak.json also looks like it is
> intended for one
> > > realm. Am I missing something?
> > >
> > > Cheers,
> > > Nils
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>>
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org <mailto:
keycloak-user(a)lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:35 p.m.
It just seems to me that tenant is a concept specific to your
application and not the security model. Why can't a realm manage
multiple instances?
On 5/31/2014 2:59 PM, Nils Preusker wrote:
Hi Bill,
our use case is as follows: we are developing an application that is
deployed as a software as a service solution. Each customer gets their
own "application instance", but all instances are served by the same
WAR. Since some customers have several instances (i.e. for departments
or divisions), it would not be accurate to say customer = realm. So we
need another level, which is what I mean when I say tenant. The users
would then be sub-elements of the tenants. However, there is one special
scenario: some customers wish to have the same users in multiple tenants.
Finally, we want to be able to add customers and instances (or tenants)
at runtime.
Mapped to my sketch from before, customers could be represented by realm
(if there is multi-realm support), "application instances" are tenants
and users can be created both on realm and on tenant level.
What do you think?
Cheers,
Nils
On Fri, May 30, 2014 at 9:13 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Why do you need to add realms at runtime? You haven't adequately
described your use case.
On 5/30/2014 2:12 PM, Nils Preusker wrote:
> Hi Bill,
>
> I guess you are right, there isn't really a difference. It would
just be
> important to be able to add realms at runtime. Are you suggesting to
> have nested realms (just replacing tenant with realm in my previous
> example)?
>
> Does that make more sense?
> Cheers,
> Nils
>
>
> On Fri, May 30, 2014 at 6:05 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>
> <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> wrote:
>
> I don't what the different between a tenant and a realm would
be in your
> example.
>
> On 5/30/2014 5:28 AM, Nils Preusker wrote:
> > Hi Bill,
> >
> > what I was thinking of was tenants as nested element
within a realm.
> >
> > We'd like to be able to add tenants at runtime. That's
where I see a
> > problem with multi-realm support, since realms are
"hardcoded" in the
> > keycloak.json. So if you add a realm in the admin-console,
with
> > multi-realm support you'd still have to modify the
deployed WAR by
> > adding the new realm to the keycloak.json file.
> >
> > I was thinking of a structure like this:
> >
> > |- realm
> > | |-users
> > | |-realm-level-user-1
> > | |-...
> > |-tenants
> > | |-tenant-1
> > | | |-users
> > | | | |-tenant-level-user-1
> > | | | |-...
> >
> > Let me know what you think!
> > Cheers,
> > Nils
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, May 29, 2014 at 11:04 PM, Bill Burke
<bburke(a)redhat.com <mailto:bburke@redhat.com>
> <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>
> > <mailto:bburke@redhat.com <mailto:bburke@redhat.com>
<mailto:bburke@redhat.com <mailto:bburke@redhat.com>>>> wrote:
> >
> > Somebody else was asking for this feature. We may have to
> add it beta 2
> > even though I wanted to have a feature freeze.
> >
> > How did you expect it to work? One guy wanted to discover
> realm per
> > request via parsing the URL. Another guy just wanted
multi-realm
> > support for bearer-only services.
> >
> >
> > On 5/29/2014 4:54 PM, Nils Preusker wrote:
> > > Hi,
> > >
> > > first of all, congrats on the beta 1 release!
> > >
> > > Here's my question: I have a WAR with a REST API
that I'm
> > securing with
> > > Keycloak. Now I'd like to add multitenancy support.
> > >
> > > If I understand the concept in keycloak correctly,
I would
> > somehow have
> > > to have several realms in the keycloak.json and the
web.xml of
> > the war,
> > > right? However there is just one realm-name
attribute in the
> > web.xml and
> > > the structure of keycloak.json also looks like it is
> intended for one
> > > realm. Am I missing something?
> > >
> > > Cheers,
> > > Nils
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
> <mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>
> <mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
> <mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>>
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
> <mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>
> <mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
> <mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
<mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
<mailto:keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:02 a.m.
I guess that would work. It does add some load to the database, since we'll
have to check permissions on domain object level, but that will be
necessary in some form anyway (i.e. user may modify objects of type X only
if they belong to him etc.).
The only issue is that we might need to be able to assign different roles
to the same user in different application instances. I don't really see a
way to implement that with the suggested approach. However, I'm also not
really sure we'll need it and we could have the customer create two users
if the roles are different anyway.
Just out of curiosity and since it is briefly mentioned in the user guide,
what is your understanding of multitenancy and what are the use cases you
are planning to support? ("Multitenancy support. You can host and manage
multiple realms for multiple organizations.")
Cheers,
Nils
On Sat, May 31, 2014 at 9:35 PM, Bill Burke <bburke(a)redhat.com> wrote:
It just seems to me that tenant is a concept specific to your
application and not the security model. Why can't a realm manage
multiple instances?
On 5/31/2014 2:59 PM, Nils Preusker wrote:
> Hi Bill,
>
> our use case is as follows: we are developing an application that is
> deployed as a software as a service solution. Each customer gets their
> own "application instance", but all instances are served by the same
> WAR. Since some customers have several instances (i.e. for departments
> or divisions), it would not be accurate to say customer = realm. So we
> need another level, which is what I mean when I say tenant. The users
> would then be sub-elements of the tenants. However, there is one special
> scenario: some customers wish to have the same users in multiple tenants.
>
> Finally, we want to be able to add customers and instances (or tenants)
> at runtime.
>
> Mapped to my sketch from before, customers could be represented by realm
> (if there is multi-realm support), "application instances" are tenants
> and users can be created both on realm and on tenant level.
>
> What do you think?
>
> Cheers,
> Nils
>
>
> On Fri, May 30, 2014 at 9:13 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> Why do you need to add realms at runtime? You haven't adequately
> described your use case.
>
> On 5/30/2014 2:12 PM, Nils Preusker wrote:
> > Hi Bill,
> >
> > I guess you are right, there isn't really a difference. It would
> just be
> > important to be able to add realms at runtime. Are you suggesting
to
> > have nested realms (just replacing tenant with realm in my
previous
> > example)?
> >
> > Does that make more sense?
> > Cheers,
> > Nils
> >
> >
> > On Fri, May 30, 2014 at 6:05 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>
> > <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>>
wrote:
> >
> > I don't what the different between a tenant and a realm would
> be in your
> > example.
> >
> > On 5/30/2014 5:28 AM, Nils Preusker wrote:
> > > Hi Bill,
> > >
> > > what I was thinking of was tenants as nested element
> within a realm.
> > >
> > > We'd like to be able to add tenants at runtime. That's
> where I see a
> > > problem with multi-realm support, since realms are
> "hardcoded" in the
> > > keycloak.json. So if you add a realm in the admin-console,
> with
> > > multi-realm support you'd still have to modify the
> deployed WAR by
> > > adding the new realm to the keycloak.json file.
> > >
> > > I was thinking of a structure like this:
> > >
> > > |- realm
> > > | |-users
> > > | |-realm-level-user-1
> > > | |-...
> > > |-tenants
> > > | |-tenant-1
> > > | | |-users
> > > | | | |-tenant-level-user-1
> > > | | | |-...
> > >
> > > Let me know what you think!
> > > Cheers,
> > > Nils
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, May 29, 2014 at 11:04 PM, Bill Burke
> <bburke(a)redhat.com <mailto:bburke@redhat.com>
> > <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>
> > > <mailto:bburke@redhat.com <mailto:bburke@redhat.com>
> <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>>>
wrote:
> > >
> > > Somebody else was asking for this feature. We may
have to
> > add it beta 2
> > > even though I wanted to have a feature freeze.
> > >
> > > How did you expect it to work? One guy wanted to
discover
> > realm per
> > > request via parsing the URL. Another guy just wanted
> multi-realm
> > > support for bearer-only services.
> > >
> > >
> > > On 5/29/2014 4:54 PM, Nils Preusker wrote:
> > > > Hi,
> > > >
> > > > first of all, congrats on the beta 1 release!
> > > >
> > > > Here's my question: I have a WAR with a REST API
> that I'm
> > > securing with
> > > > Keycloak. Now I'd like to add multitenancy
support.
> > > >
> > > > If I understand the concept in keycloak correctly,
> I would
> > > somehow have
> > > > to have several realms in the keycloak.json and the
> web.xml of
> > > the war,
> > > > right? However there is just one realm-name
> attribute in the
> > > web.xml and
> > > > the structure of keycloak.json also looks like it is
> > intended for one
> > > > realm. Am I missing something?
> > > >
> > > > Cheers,
> > > > Nils
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > keycloak-user mailing list
> > > > keycloak-user(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> > <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>>
> > <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> > <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>>>
> > > >
https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > >
> > >
> > > --
> > > Bill Burke
> > > JBoss, a division of Red Hat
> > > http://bill.burkecentral.com
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> > <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>>
> > <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> > <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>>>
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>>
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>
> <mailto:keycloak-user@lists.jboss.org
> <mailto:keycloak-user@lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org <mailto:
keycloak-user(a)lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
6:28 a.m.
We already support some form of multi-tenancy. One keycloak server can
serve up multiple realms.
For multitenant-apps was thinking of a app or service that needs to
support multiple isolated realms.
For bearer-only services, there would just be a list of realms that are
supported and the keycloak adapter would just look into the bearer token
to know which realm to validate the token with. For browser apps, they
need to be able to know which realm you are authenticating against, so I
thought the desired realm would be extracted from the URL.
I balk at your use-case because I don't like the idea of cross-realm users.
On 6/1/2014 4:02 AM, Nils Preusker wrote:
The only issue is that we might need to be able to assign different
roles to the same user in different application instances.
What you could do, is not use the keycloak adapter and just hand code
your interactions via our oauth client api. Then your application
service could figure out which realm and application instance the user
was logging however it wanted and and pass that information along when
you start the oauth protocol flow. Following me?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:57 a.m.
Hi Bill,
The more I think about it the more it makes sense to me that the tenant or application
instance is indeed part of the applications data model and not part of keycloak.
Especially since we want to add tenants at runtime, it wouldn't be possible to have a
check without hitting the db.
About cross realm users, I totally agree! I also don't like the idea and I'm
hoping and guessing that we won't really need it in the end.
Thanks for the discussion!
Nils
On 01 Jun 2014, at 13:28, Bill Burke <bburke(a)redhat.com>
wrote:
We already support some form of multi-tenancy. One keycloak server can
serve up multiple realms.
For multitenant-apps was thinking of a app or service that needs to
support multiple isolated realms.
For bearer-only services, there would just be a list of realms that are
supported and the keycloak adapter would just look into the bearer token
to know which realm to validate the token with. For browser apps, they
need to be able to know which realm you are authenticating against, so I
thought the desired realm would be extracted from the URL.
I balk at your use-case because I don't like the idea of cross-realm users.
> On 6/1/2014 4:02 AM, Nils Preusker wrote:
> The only issue is that we might need to be able to assign different
> roles to the same user in different application instances.
What you could do, is not use the keycloak adapter and just hand code
your interactions via our oauth client api. Then your application
service could figure out which realm and application instance the user
was logging however it wanted and and pass that information along when
you start the oauth protocol flow. Following me?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
12:01 p.m.
Hi Bill,
it's been a while since we discussed this but I thought I'd add my question
to this thread since it is related. I'm now looking into authorizing
requests based on domain specific permissions.
Here's the use case:
We have one war that serves as a REST-back-end for a JavaScript
application. We've successfully secured the application (AngularJS with
keycloak.js in the front-end, WAR on Wildfly 8 with JAX-RS/ RestEasy in the
back-end) with keycloak (beta-2). Now, instead of using the role mapping in
the OAuth token, we'd like to be able to determine the users' role mappings
based on a path parameter in the HTTP request to the REST-back-end.
For example, if the URL is '/my-app/1/some-resource', we need to check
whether the user has an account in 'my-app 1' (which is an entry in the
applications database) and add the respective roles (also from the
applications database), if the URL is /my-app/2/... the same needs to
happen for 'my-app 2' etc.
The idea would be to add some kind of security interceptor which extracts
the keycloak user id, matches the id to the domain user (user from e.g.
my-app 1), and adds the role mapping of the domain user. Since we'd like to
continue using the EJB annotations (RolesAllowed etc.), we'd need to make
sure those domain users' roles are propagated to the security context.
So the question is, would you recommend extending the keycloak login
module? Or can you think of an easier way like e.g. a web filter?
Cheers!
Nils
My question is whether to extend the wildfly adapter (KeycloakLoginModule)
or to
On Sun, Jun 1, 2014 at 5:57 PM, Nils Preusker <n.preusker(a)gmail.com> wrote:
Hi Bill,
The more I think about it the more it makes sense to me that the tenant or
application instance is indeed part of the applications data model and not
part of keycloak. Especially since we want to add tenants at runtime, it
wouldn't be possible to have a check without hitting the db.
About cross realm users, I totally agree! I also don't like the idea and
I'm hoping and guessing that we won't really need it in the end.
Thanks for the discussion!
Nils
> On 01 Jun 2014, at 13:28, Bill Burke <bburke(a)redhat.com> wrote:
>
> We already support some form of multi-tenancy. One keycloak server can
> serve up multiple realms.
>
>
> For multitenant-apps was thinking of a app or service that needs to
> support multiple isolated realms.
>
> For bearer-only services, there would just be a list of realms that are
> supported and the keycloak adapter would just look into the bearer token
> to know which realm to validate the token with. For browser apps, they
> need to be able to know which realm you are authenticating against, so I
> thought the desired realm would be extracted from the URL.
>
> I balk at your use-case because I don't like the idea of cross-realm
users.
>
>
>> On 6/1/2014 4:02 AM, Nils Preusker wrote:
>> The only issue is that we might need to be able to assign different
>> roles to the same user in different application instances.
>
> What you could do, is not use the keycloak adapter and just hand code
> your interactions via our oauth client api. Then your application
> service could figure out which realm and application instance the user
> was logging however it wanted and and pass that information along when
> you start the oauth protocol flow. Following me?
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
2:32 a.m.
This sounds like a feature that our adapter should provide so I would say if you can come
up with a decent way to add it, then we'd probably be more than happy to pull it in.
We could enable multi-tenancy support in keycloak.json by allowing multiple sets of
configs with one or more url-patterns to match what config to use. For example:
[
{
"realm" : "example",
"resource" : "app1",
...
"url-pattern" : [ "/app1/*", "/myapp/*" ]
},
{
"realm" : "example2",
"resource" : "app2",
...
"url-pattern" : [ "http://app2.org/*" ]
}
]
----- Original Message -----
From: "Nils Preusker" <n.preusker(a)gmail.com>
To: keycloak-user(a)lists.jboss.org
Sent: Tuesday, 12 August, 2014 7:01:33 PM
Subject: Re: [keycloak-user] Multitenancy for WAR
Hi Bill,
it's been a while since we discussed this but I thought I'd add my question
to this thread since it is related. I'm now looking into authorizing
requests based on domain specific permissions.
Here's the use case:
We have one war that serves as a REST-back-end for a JavaScript application.
We've successfully secured the application (AngularJS with keycloak.js in
the front-end, WAR on Wildfly 8 with JAX-RS/ RestEasy in the back-end) with
keycloak (beta-2). Now, instead of using the role mapping in the OAuth
token, we'd like to be able to determine the users' role mappings based on a
path parameter in the HTTP request to the REST-back-end.
For example, if the URL is '/my-app/1/some-resource', we need to check
whether the user has an account in 'my-app 1' (which is an entry in the
applications database) and add the respective roles (also from the
applications database), if the URL is /my-app/2/... the same needs to happen
for 'my-app 2' etc.
The idea would be to add some kind of security interceptor which extracts the
keycloak user id, matches the id to the domain user (user from e.g. my-app
1), and adds the role mapping of the domain user. Since we'd like to
continue using the EJB annotations (RolesAllowed etc.), we'd need to make
sure those domain users' roles are propagated to the security context.
So the question is, would you recommend extending the keycloak login module?
Or can you think of an easier way like e.g. a web filter?
Cheers!
Nils
My question is whether to extend the wildfly adapter (KeycloakLoginModule) or
to
On Sun, Jun 1, 2014 at 5:57 PM, Nils Preusker < n.preusker(a)gmail.com > wrote:
Hi Bill,
The more I think about it the more it makes sense to me that the tenant or
application instance is indeed part of the applications data model and not
part of keycloak. Especially since we want to add tenants at runtime, it
wouldn't be possible to have a check without hitting the db.
About cross realm users, I totally agree! I also don't like the idea and I'm
hoping and guessing that we won't really need it in the end.
Thanks for the discussion!
Nils
> On 01 Jun 2014, at 13:28, Bill Burke < bburke(a)redhat.com > wrote:
>
> We already support some form of multi-tenancy. One keycloak server can
> serve up multiple realms.
>
>
> For multitenant-apps was thinking of a app or service that needs to
> support multiple isolated realms.
>
> For bearer-only services, there would just be a list of realms that are
> supported and the keycloak adapter would just look into the bearer token
> to know which realm to validate the token with. For browser apps, they
> need to be able to know which realm you are authenticating against, so I
> thought the desired realm would be extracted from the URL.
>
> I balk at your use-case because I don't like the idea of cross-realm users.
>
>
>> On 6/1/2014 4:02 AM, Nils Preusker wrote:
>> The only issue is that we might need to be able to assign different
>> roles to the same user in different application instances.
>
> What you could do, is not use the keycloak adapter and just hand code
> your interactions via our oauth client api. Then your application
> service could figure out which realm and application instance the user
> was logging however it wanted and and pass that information along when
> you start the oauth protocol flow. Following me?
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:45 a.m.
Hi Stian,
thanks for your reply. We've actually come up with a totally different
approach in the meantime. We now ask our back-end for a domain specific
token every time an object that requires a custom role mapping is selected
in the UI. We then replace the token in keycloak.js. The back-end uses
keycloak-core in order to create tokens (inspired by
https://github.com/liveoak-io/liveoak/blob/master/modules/keycloak/src/te...
).
Cheers,
Nils
On Tue, Aug 26, 2014 at 9:32 AM, Stian Thorgersen <stian(a)redhat.com> wrote:
This sounds like a feature that our adapter should provide so I would
say
if you can come up with a decent way to add it, then we'd probably be more
than happy to pull it in.
We could enable multi-tenancy support in keycloak.json by allowing
multiple sets of configs with one or more url-patterns to match what config
to use. For example:
[
{
"realm" : "example",
"resource" : "app1",
...
"url-pattern" : [ "/app1/*", "/myapp/*" ]
},
{
"realm" : "example2",
"resource" : "app2",
...
"url-pattern" : [ "http://app2.org/*" ]
}
]
----- Original Message -----
> From: "Nils Preusker" <n.preusker(a)gmail.com>
> To: keycloak-user(a)lists.jboss.org
> Sent: Tuesday, 12 August, 2014 7:01:33 PM
> Subject: Re: [keycloak-user] Multitenancy for WAR
>
> Hi Bill,
>
> it's been a while since we discussed this but I thought I'd add my
question
> to this thread since it is related. I'm now looking into authorizing
> requests based on domain specific permissions.
>
> Here's the use case:
> We have one war that serves as a REST-back-end for a JavaScript
application.
> We've successfully secured the application (AngularJS with keycloak.js in
> the front-end, WAR on Wildfly 8 with JAX-RS/ RestEasy in the back-end)
with
> keycloak (beta-2). Now, instead of using the role mapping in the OAuth
> token, we'd like to be able to determine the users' role mappings based
on a
> path parameter in the HTTP request to the REST-back-end.
>
> For example, if the URL is '/my-app/1/some-resource', we need to check
> whether the user has an account in 'my-app 1' (which is an entry in the
> applications database) and add the respective roles (also from the
> applications database), if the URL is /my-app/2/... the same needs to
happen
> for 'my-app 2' etc.
>
> The idea would be to add some kind of security interceptor which
extracts the
> keycloak user id, matches the id to the domain user (user from e.g.
my-app
> 1), and adds the role mapping of the domain user. Since we'd like to
> continue using the EJB annotations (RolesAllowed etc.), we'd need to make
> sure those domain users' roles are propagated to the security context.
>
> So the question is, would you recommend extending the keycloak login
module?
> Or can you think of an easier way like e.g. a web filter?
>
> Cheers!
> Nils
>
>
>
>
>
>
>
>
>
>
>
>
> My question is whether to extend the wildfly adapter
(KeycloakLoginModule) or
> to
>
>
> On Sun, Jun 1, 2014 at 5:57 PM, Nils Preusker < n.preusker(a)gmail.com >
wrote:
>
>
> Hi Bill,
>
> The more I think about it the more it makes sense to me that the tenant
or
> application instance is indeed part of the applications data model and
not
> part of keycloak. Especially since we want to add tenants at runtime, it
> wouldn't be possible to have a check without hitting the db.
>
> About cross realm users, I totally agree! I also don't like the idea and
I'm
> hoping and guessing that we won't really need it in the end.
>
> Thanks for the discussion!
> Nils
>
> > On 01 Jun 2014, at 13:28, Bill Burke < bburke(a)redhat.com > wrote:
> >
> > We already support some form of multi-tenancy. One keycloak server can
> > serve up multiple realms.
> >
> >
> > For multitenant-apps was thinking of a app or service that needs to
> > support multiple isolated realms.
> >
> > For bearer-only services, there would just be a list of realms that are
> > supported and the keycloak adapter would just look into the bearer
token
> > to know which realm to validate the token with. For browser apps, they
> > need to be able to know which realm you are authenticating against, so
I
> > thought the desired realm would be extracted from the URL.
> >
> > I balk at your use-case because I don't like the idea of cross-realm
users.
> >
> >
> >> On 6/1/2014 4:02 AM, Nils Preusker wrote:
> >> The only issue is that we might need to be able to assign different
> >> roles to the same user in different application instances.
> >
> > What you could do, is not use the keycloak adapter and just hand code
> > your interactions via our oauth client api. Then your application
> > service could figure out which realm and application instance the user
> > was logging however it wanted and and pass that information along when
> > you start the oauth protocol flow. Following me?
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
4086
days inactive
4175
days old
14 comments
3 participants
participants (3)
-
Bill Burke -
Nils Preusker -
Stian Thorgersen