1:36 a.m.
Hi Stian,
You proposed solution would not cover the use case where we can create
tenants at runtime as the realm config in the keycloak.json would be hard
coded into the war.
I had discussed this identical use case a while ago on this forum and Bill
was planning to refactor the adapters to support this use case.
Unfortunately he got caught up in other tasks and was not able to proceed
on this.
The discussion thread is here
http://lists.jboss.org/pipermail/keycloak-user/2014-March/000062.html
Basically what I believe Bill suggested which would meet this use case is
to:
1. Have a shared secret between clients for all realms.
2. The adapter would just extract the realm name from the request,
invoke on the keycloak server to get the public information about the realm
(i.e. public key) and then cache the information locally.
The key bit here is extracting the realm name from the request and then
pulling the realm info from the keycloak server.
I had a look at the keycloak source code and I believe the magic happens in
the KeycloakServletExtension class under the org.keycloak.adapters.undertow
package for my use case (since I deploy it on wildfly)
What I have got stumped is that this class gets loaded when my war is
deployed and I am wondering how I can do it per request (if the info is not
already cached locally)
Maybe with the imminent release of 1.0 (btw congrats for the great work to
everyone in the team and for Bill and your leadership), maybe we should
start thinking about this multi tenancy use case to be included in future
releases.
I believe that SaaS models are going to be popular and having this feature
added will make keycloak a major player in this space.
Cheers
Travis
8:15 a.m.
New subject: Multitenancy for WAR
Travis, I did do most of the work for this. I think I pinged you to see
if you still wanted the feature, but never followed through. I'm sorry.
All this would require a shared client secret, or public clients. It
would require you to extract the realm name somehow based on the current
HTTP request. Probably a URI pattern.
There is an AdapterDeploymentContext class. This class has a method:
KeycloakDeployment resolveDeployment(HttpFacade)
This method get's called every request. You would extend this class and
override resolveDeployment and create (and then cache) your
KeycloakDeployment based on the incoming HTTP request.
The only problem is that the current code has no way for you to plug in
a new implementation of the AdapterDeploymentContext.
On 9/4/2014 2:36 AM, Travis De Silva wrote:
Hi Stian,
You proposed solution would not cover the use case where we can create
tenants at runtime as the realm config in the keycloak.json would be
hard coded into the war.
I had discussed this identical use case a while ago on this forum and
Bill was planning to refactor the adapters to support this use case.
Unfortunately he got caught up in other tasks and was not able to
proceed on this.
The discussion thread is here
http://lists.jboss.org/pipermail/keycloak-user/2014-March/000062.html
Basically what I believe Bill suggested which would meet this use case
is to:
1. Have a shared secret between clients for all realms.
2. The adapter would just extract the realm name from the request,
invoke on the keycloak server to get the public information about
the realm (i.e. public key) and then cache the information locally.
The key bit here is extracting the realm name from the request and then
pulling the realm info from the keycloak server.
I had a look at the keycloak source code and I believe the magic happens
in the KeycloakServletExtension class under the
org.keycloak.adapters.undertow package for my use case (since I deploy
it on wildfly)
What I have got stumped is that this class gets loaded when my war is
deployed and I am wondering how I can do it per request (if the info is
not already cached locally)
Maybe with the imminent release of 1.0 (btw congrats for the great work
to everyone in the team and for Bill and your leadership), maybe we
should start thinking about this multi tenancy use case to be included
in future releases.
I believe that SaaS models are going to be popular and having this
feature added will make keycloak a major player in this space.
Cheers
Travis
_______________________________________________
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
6:17 p.m.
New subject: Multitenancy for WAR
Hi Bill,
Sorry for missing your ping as this is something that we definitely need. I
was going down the keycloak.js path (since we use AngularJS as our UI
layer) but doing it on the server side is so much more elegant.
Picking the realm name from the URI is the way to go. Maybe we have it as a
query parameter rather than within the path as then it is less invasive for
the war application.
I don't understand the keycloak code base enough to comment on how we can
deploy the new AdapterDeploymentContext but what if this feature is plugged
into the current AdapterDeploymentContext and this is a feature of the core
product?
Also with regard to getting realm information from the server using a shared
client secret, or public clients, another way to do this might be to
provide an alternate way to pick the keycloak.json file by storing it
outside the war in the file system and then based on the realm name in the
uri, pick the corresponding keycloak.json file and run the KeycloakDeployment.
We can name the the files as keycloak-{realmname}.json
Note we can keep the current functionality where it can pick it from within
the war but if the file is missing, currently its throwing an exception.
Maybe before we throw the exception, we also check the file system as well.
Then maybe we don't need to load this on request but can have a directory
scanner and whenever a new file is added or removed, it will automatically
pick it up. Sort of how the JBoss/Wildfly deployment scanner works. On each
request of course it will need to pick the correct realm to perform the
authentication.
This might be more elegant but once again I don't know enough of the core
keycloak code to comment if doing this is more complex than the other
option.
Obviously these changes will not go into 1.0 release but a subsequent
release (hopefully the first beta release after 1.0 :)
Therefore it might be good to give some thought and get this right. For me
this and the multi-lingual are the two key items that we need to tick off
to be able to use this in a multi tenancy environment.
Keen to know your thoughts.
Cheers
Travis
On Thu, Sep 4, 2014 at 11:15 PM, Bill Burke <bburke(a)redhat.com> wrote:
Travis, I did do most of the work for this. I think I pinged you to
see
if you still wanted the feature, but never followed through. I'm sorry.
All this would require a shared client secret, or public clients. It
would require you to extract the realm name somehow based on the current
HTTP request. Probably a URI pattern.
There is an AdapterDeploymentContext class. This class has a method:
KeycloakDeployment resolveDeployment(HttpFacade)
This method get's called every request. You would extend this class and
override resolveDeployment and create (and then cache) your
KeycloakDeployment based on the incoming HTTP request.
The only problem is that the current code has no way for you to plug in
a new implementation of the AdapterDeploymentContext.
On 9/4/2014 2:36 AM, Travis De Silva wrote:
> Hi Stian,
>
> You proposed solution would not cover the use case where we can create
> tenants at runtime as the realm config in the keycloak.json would be
> hard coded into the war.
>
> I had discussed this identical use case a while ago on this forum and
> Bill was planning to refactor the adapters to support this use case.
> Unfortunately he got caught up in other tasks and was not able to
> proceed on this.
>
> The discussion thread is here
> http://lists.jboss.org/pipermail/keycloak-user/2014-March/000062.html
>
> Basically what I believe Bill suggested which would meet this use case
> is to:
>
> 1. Have a shared secret between clients for all realms.
> 2. The adapter would just extract the realm name from the request,
> invoke on the keycloak server to get the public information about
> the realm (i.e. public key) and then cache the information locally.
>
> The key bit here is extracting the realm name from the request and then
> pulling the realm info from the keycloak server.
>
> I had a look at the keycloak source code and I believe the magic happens
> in the KeycloakServletExtension class under the
> org.keycloak.adapters.undertow package for my use case (since I deploy
> it on wildfly)
>
> What I have got stumped is that this class gets loaded when my war is
> deployed and I am wondering how I can do it per request (if the info is
> not already cached locally)
>
> Maybe with the imminent release of 1.0 (btw congrats for the great work
> to everyone in the team and for Bill and your leadership), maybe we
> should start thinking about this multi tenancy use case to be included
> in future releases.
>
> I believe that SaaS models are going to be popular and having this
> feature added will make keycloak a major player in this space.
>
> Cheers
> Travis
>
>
>
>
> _______________________________________________
> 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
9:14 a.m.
New subject: Multitenancy for WAR
I think it would be 1 day work for me, as again, I already refactored
the adapters to support this use case. It would just be a matter of:
* Making AdatperDeploymentContext pluggable
* Writing an AdapterDeploymentContext which could accept a URI pattern
to extract the name of the realm.
Once I have that in place, you guys can fork it and implement anything
you want. What I think I want to do, is keep this SPI private until
users like you have testdrived it.
On 9/4/2014 7:17 PM, Travis De Silva wrote:
Hi Bill,
Sorry for missing your ping as this is something that we definitely
need. I was going down the keycloak.js path (since we use AngularJS as
our UI layer) but doing it on the server side is so much more elegant.
Picking the realm name from the URI is the way to go. Maybe we have it
as a query parameter rather than within the path as then it is less
invasive for the war application.
I don't understand the keycloak code base enough to comment on how we
can deploy the new AdapterDeploymentContext but what if this feature is
plugged into the current AdapterDeploymentContext and this is a feature
of the core product?
Also with regard to getting realm information from the server using a
shared client secret, or public clients, another way to do this might be
to provide an alternate way to pick the keycloak.json file by storing it
outside the war in the file system and then based on the realm name in
the uri, pick the corresponding keycloak.json file and run the
KeycloakDeployment. We can name the the files as keycloak-{realmname}.json
Note we can keep the current functionality where it can pick it from
within the war but if the file is missing, currently its throwing an
exception. Maybe before we throw the exception, we also check the file
system as well.
Then maybe we don't need to load this on request but can have a
directory scanner and whenever a new file is added or removed, it will
automatically pick it up. Sort of how the JBoss/Wildfly deployment
scanner works. On each request of course it will need to pick the
correct realm to perform the authentication.
This might be more elegant but once again I don't know enough of the
core keycloak code to comment if doing this is more complex than the
other option.
Obviously these changes will not go into 1.0 release but a subsequent
release (hopefully the first beta release after 1.0 :)
Therefore it might be good to give some thought and get this right. For
me this and the multi-lingual are the two key items that we need to tick
off to be able to use this in a multi tenancy environment.
Keen to know your thoughts.
Cheers
Travis
On Thu, Sep 4, 2014 at 11:15 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Travis, I did do most of the work for this. I think I pinged you to see
if you still wanted the feature, but never followed through. I'm sorry.
All this would require a shared client secret, or public clients. It
would require you to extract the realm name somehow based on the current
HTTP request. Probably a URI pattern.
There is an AdapterDeploymentContext class. This class has a method:
KeycloakDeployment resolveDeployment(HttpFacade)
This method get's called every request. You would extend this class and
override resolveDeployment and create (and then cache) your
KeycloakDeployment based on the incoming HTTP request.
The only problem is that the current code has no way for you to plug in
a new implementation of the AdapterDeploymentContext.
On 9/4/2014 2:36 AM, Travis De Silva wrote:
> Hi Stian,
>
> You proposed solution would not cover the use case where we can
create
> tenants at runtime as the realm config in the keycloak.json would be
> hard coded into the war.
>
> I had discussed this identical use case a while ago on this forum and
> Bill was planning to refactor the adapters to support this use case.
> Unfortunately he got caught up in other tasks and was not able to
> proceed on this.
>
> The discussion thread is here
> http://lists.jboss.org/pipermail/keycloak-user/2014-March/000062.html
>
> Basically what I believe Bill suggested which would meet this use
case
> is to:
>
> 1. Have a shared secret between clients for all realms.
> 2. The adapter would just extract the realm name from the request,
> invoke on the keycloak server to get the public information about
> the realm (i.e. public key) and then cache the information
locally.
>
> The key bit here is extracting the realm name from the request
and then
> pulling the realm info from the keycloak server.
>
> I had a look at the keycloak source code and I believe the magic
happens
> in the KeycloakServletExtension class under the
> org.keycloak.adapters.undertow package for my use case (since I
deploy
> it on wildfly)
>
> What I have got stumped is that this class gets loaded when my war is
> deployed and I am wondering how I can do it per request (if the
info is
> not already cached locally)
>
> Maybe with the imminent release of 1.0 (btw congrats for the
great work
> to everyone in the team and for Bill and your leadership), maybe we
> should start thinking about this multi tenancy use case to be
included
> in future releases.
>
> I believe that SaaS models are going to be popular and having this
> feature added will make keycloak a major player in this space.
>
> Cheers
> Travis
>
>
>
>
> _______________________________________________
> 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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:24 p.m.
New subject: Multitenancy for WAR
sounds good. let me know once its done.
On Sat, Sep 6, 2014 at 12:14 AM, Bill Burke <bburke(a)redhat.com> wrote:
I think it would be 1 day work for me, as again, I already refactored
the
adapters to support this use case. It would just be a matter of:
* Making AdatperDeploymentContext pluggable
* Writing an AdapterDeploymentContext which could accept a URI pattern to
extract the name of the realm.
Once I have that in place, you guys can fork it and implement anything you
want. What I think I want to do, is keep this SPI private until users like
you have testdrived it.
On 9/4/2014 7:17 PM, Travis De Silva wrote:
> Hi Bill,
>
> Sorry for missing your ping as this is something that we definitely
> need. I was going down the keycloak.js path (since we use AngularJS as
> our UI layer) but doing it on the server side is so much more elegant.
>
> Picking the realm name from the URI is the way to go. Maybe we have it
> as a query parameter rather than within the path as then it is less
> invasive for the war application.
>
> I don't understand the keycloak code base enough to comment on how we
> can deploy the new AdapterDeploymentContext but what if this feature is
> plugged into the current AdapterDeploymentContext and this is a feature
> of the core product?
>
> Also with regard to getting realm information from the server using a
> shared client secret, or public clients, another way to do this might be
> to provide an alternate way to pick the keycloak.json file by storing it
> outside the war in the file system and then based on the realm name in
> the uri, pick the corresponding keycloak.json file and run the
> KeycloakDeployment. We can name the the files as keycloak-{realmname}.json
>
> Note we can keep the current functionality where it can pick it from
> within the war but if the file is missing, currently its throwing an
> exception. Maybe before we throw the exception, we also check the file
> system as well.
>
> Then maybe we don't need to load this on request but can have a
> directory scanner and whenever a new file is added or removed, it will
> automatically pick it up. Sort of how the JBoss/Wildfly deployment
> scanner works. On each request of course it will need to pick the
> correct realm to perform the authentication.
>
> This might be more elegant but once again I don't know enough of the
> core keycloak code to comment if doing this is more complex than the
> other option.
>
> Obviously these changes will not go into 1.0 release but a subsequent
> release (hopefully the first beta release after 1.0 :)
>
> Therefore it might be good to give some thought and get this right. For
> me this and the multi-lingual are the two key items that we need to tick
> off to be able to use this in a multi tenancy environment.
>
> Keen to know your thoughts.
>
> Cheers
> Travis
>
>
>
>
> On Thu, Sep 4, 2014 at 11:15 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> Travis, I did do most of the work for this. I think I pinged you to
> see
> if you still wanted the feature, but never followed through. I'm
> sorry.
>
> All this would require a shared client secret, or public clients. It
> would require you to extract the realm name somehow based on the
> current
> HTTP request. Probably a URI pattern.
>
> There is an AdapterDeploymentContext class. This class has a method:
>
> KeycloakDeployment resolveDeployment(HttpFacade)
>
> This method get's called every request. You would extend this class
> and
> override resolveDeployment and create (and then cache) your
> KeycloakDeployment based on the incoming HTTP request.
>
> The only problem is that the current code has no way for you to plug
> in
> a new implementation of the AdapterDeploymentContext.
>
> On 9/4/2014 2:36 AM, Travis De Silva wrote:
> > Hi Stian,
> >
> > You proposed solution would not cover the use case where we can
> create
> > tenants at runtime as the realm config in the keycloak.json would
> be
> > hard coded into the war.
> >
> > I had discussed this identical use case a while ago on this forum
> and
> > Bill was planning to refactor the adapters to support this use
> case.
> > Unfortunately he got caught up in other tasks and was not able to
> > proceed on this.
> >
> > The discussion thread is here
> > http://lists.jboss.org/pipermail/keycloak-user/2014-
> March/000062.html
> >
> > Basically what I believe Bill suggested which would meet this use
> case
> > is to:
> >
> > 1. Have a shared secret between clients for all realms.
> > 2. The adapter would just extract the realm name from the request,
> > invoke on the keycloak server to get the public information
> about
> > the realm (i.e. public key) and then cache the information
> locally.
> >
> > The key bit here is extracting the realm name from the request
> and then
> > pulling the realm info from the keycloak server.
> >
> > I had a look at the keycloak source code and I believe the magic
> happens
> > in the KeycloakServletExtension class under the
> > org.keycloak.adapters.undertow package for my use case (since I
> deploy
> > it on wildfly)
> >
> > What I have got stumped is that this class gets loaded when my war
> is
> > deployed and I am wondering how I can do it per request (if the
> info is
> > not already cached locally)
> >
> > Maybe with the imminent release of 1.0 (btw congrats for the
> great work
> > to everyone in the team and for Bill and your leadership), maybe we
> > should start thinking about this multi tenancy use case to be
> included
> > in future releases.
> >
> > I believe that SaaS models are going to be popular and having this
> > feature added will make keycloak a major player in this space.
> >
> > Cheers
> > Travis
> >
> >
> >
> >
> > _______________________________________________
> > 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
>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3780
days inactive
3781
days old
4 comments
2 participants
participants (2)
-
Bill Burke -
Travis De Silva