9:22 p.m.
I was initially under the impression that I can configure realms as
tenants and use KeyCloak for applications that are designed for multi
tenancy.
But now I have discovered that this is not possible, at least not possible
to do it on demand. I hope I am wrong and someone can correct me.
Basically what I was trying to do was, when someone signs up to my
application platform, I was going to create a realm programmatically via
the API. Hence the feature request I raised to have a realm level admin
https://issues.jboss.org/browse/KEYCLOAK-292
But that means, I will then have to either configure my Wildfly
standalone.xml config with the new realm or add the installation json to my
war and redeploy it. This is obviously not ideal for a on demand multi
tenant application.
Maybe using Roles and create unique roles per tenant which hopefully I can
do programatically via the API. I think I might be able to get something
going like this but it just feels very hacky and not elegant.
Is there any other elegant way? Is Keycloak designed for multi tenancy
environments?
Cheers
Travis
9:46 p.m.
I just read the discussions on KEYCLOAK-292 on the developer mailing list.
http://lists.jboss.org/pipermail/keycloak-dev/2014-February/001378.html
The concept of creating an application under the keycloak-admin realm for
each realm created looks interesting.
When it comes to multi tenancy, I think the issue is around the application
installation process. If there is a way where we don't have to provide
individual application level keycloak.json's or WildFly/JBoss subsystem
XML's, then we are getting closer to multi tenancy. I am thinking can this
be done at a keycloak top level or the ability to use wildcards for the
resource elements in the json.
Is LiveOak a multi tenancy platform? Wondering if they would need such a
feature.
On Sun, Feb 23, 2014 at 2:22 PM, Travis De Silva <traviskds(a)gmail.com>wrote:
I was initially under the impression that I can configure realms as
tenants and use KeyCloak for applications that are designed for multi
tenancy.
But now I have discovered that this is not possible, at least not possible
to do it on demand. I hope I am wrong and someone can correct me.
Basically what I was trying to do was, when someone signs up to my
application platform, I was going to create a realm programmatically via
the API. Hence the feature request I raised to have a realm level admin
https://issues.jboss.org/browse/KEYCLOAK-292
But that means, I will then have to either configure my Wildfly
standalone.xml config with the new realm or add the installation json to my
war and redeploy it. This is obviously not ideal for a on demand multi
tenant application.
Maybe using Roles and create unique roles per tenant which hopefully I can
do programatically via the API. I think I might be able to get something
going like this but it just feels very hacky and not elegant.
Is there any other elegant way? Is Keycloak designed for multi tenancy
environments?
Cheers
Travis
7:08 a.m.
On 2/22/2014 10:46 PM, Travis De Silva wrote:
I just read the discussions on KEYCLOAK-292 on the developer mailing
list.
http://lists.jboss.org/pipermail/keycloak-dev/2014-February/001378.html
The concept of creating an application under the keycloak-admin realm
for each realm created looks interesting.
When it comes to multi tenancy, I think the issue is around the
application installation process. If there is a way where we don't have
to provide individual application level keycloak.json's or WildFly/JBoss
subsystem XML's, then we are getting closer to multi tenancy. I am
thinking can this be done at a keycloak top level or the ability to use
wildcards for the resource elements in the json.
The application itself needs to be able to handle multiple realms at
once? How would you choose which realm to belong to when initiating a
login? Can you elaborate a bit more on what the flow would look like
(what you want) when interacting with your applications?
Aerogear UPS might be in a similar position as you too, so this is
something I'd like to solve sooner rather than later.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:18 a.m.
On 2/23/2014 8:08 AM, Bill Burke wrote:
On 2/22/2014 10:46 PM, Travis De Silva wrote:
> I just read the discussions on KEYCLOAK-292 on the developer mailing
> list.
> http://lists.jboss.org/pipermail/keycloak-dev/2014-February/001378.html
>
> The concept of creating an application under the keycloak-admin realm
> for each realm created looks interesting.
>
> When it comes to multi tenancy, I think the issue is around the
> application installation process. If there is a way where we don't have
> to provide individual application level keycloak.json's or WildFly/JBoss
> subsystem XML's, then we are getting closer to multi tenancy. I am
> thinking can this be done at a keycloak top level or the ability to use
> wildcards for the resource elements in the json.
>
The application itself needs to be able to handle multiple realms at
once? How would you choose which realm to belong to when initiating a
login? Can you elaborate a bit more on what the flow would look like
(what you want) when interacting with your applications?
Aerogear UPS might be in a similar position as you too, so this is
something I'd like to solve sooner rather than later.
Please respond to above, but this was some of my thoughts with Aerogear
which may be related:
http://lists.jboss.org/pipermail/keycloak-dev/2014-February/001292.html
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
1:28 p.m.
yes the application itself needs to handle multiple realms at once. We are
going with a shared application multi tenancy model.
Basically the flow I had in mind was:
Tenant Registration Process
Each tenant will get their own url
When a new tenant signs up, they can specify their url.
We would then create the realm for the client in Keycloak (via API calls)
and associate the realm id to the url (either in keycloak or our
application)
Login process for users of the tenant
When a user logs in via their tenant specific url, we will intercept that
request in a filter and using the Authorization header grab the token and
accordingly handle the authorization. If user has not logged in, we will
redirect to keycloak for authentication
I had a look at your thoughts on how to do this with Aerogear. If I
understand the concept correctly, with the UPS + Keycloak in one bundle
option, we have to update the jboss wildfly config on the fly whenever we
get new tenants. I did not think of this option and not sure if this could
be done with wildfly without having to restart wildfly, but even if that is
possible, that means we are going to have a large list of wildfly adapter
profiles and I don't think that is practical. Just think even if we get 200
tenants, this is going to make it very complicated. Also I think the
concept is one war per realm so this might not even be possible for a
single application multi tenant model.
I think the ideal would be to have one wildfly adapter config per Keycloak
instance. (i.e. don't go to the realm level) If you want to keep the
existing and also cater to what I am suggesting, then some wildcard method
to config would do.
Having said that, now I am wondering if by using the Per war configuration
(and not using the wildfly adapter) if I could achieve what I want since
from the keycloak docs, it looks like you can configure keycloak per war
without specifying any realm specific settings. (at least for now
the realm-name element is supposed to be ignored.)
Not sure if I have complicated this further or if this is doable. But if we
can plug in multi tenancy that would be a massive win for Keycloak
considering that everything is now moving to the cloud.
On Mon, Feb 24, 2014 at 12:18 AM, Bill Burke <bburke(a)redhat.com> wrote:
On 2/23/2014 8:08 AM, Bill Burke wrote:
>
>
> On 2/22/2014 10:46 PM, Travis De Silva wrote:
>> I just read the discussions on KEYCLOAK-292 on the developer mailing
>> list.
>> http://lists.jboss.org/pipermail/keycloak-dev/2014-February/001378.html
>>
>> The concept of creating an application under the keycloak-admin realm
>> for each realm created looks interesting.
>>
>> When it comes to multi tenancy, I think the issue is around the
>> application installation process. If there is a way where we don't have
>> to provide individual application level keycloak.json's or WildFly/JBoss
>> subsystem XML's, then we are getting closer to multi tenancy. I am
>> thinking can this be done at a keycloak top level or the ability to use
>> wildcards for the resource elements in the json.
>>
>
> The application itself needs to be able to handle multiple realms at
> once? How would you choose which realm to belong to when initiating a
> login? Can you elaborate a bit more on what the flow would look like
> (what you want) when interacting with your applications?
>
> Aerogear UPS might be in a similar position as you too, so this is
> something I'd like to solve sooner rather than later.
Please respond to above, but this was some of my thoughts with Aerogear
which may be related:
http://lists.jboss.org/pipermail/keycloak-dev/2014-February/001292.html
--
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
7:31 p.m.
So you want to bind a URL to a specific adapter configuration?
<secured-deployment> might have a <url-pattern> and/or keycloak.json
might be expanded to do the same.
url-pattern could be /foo/bar/*
or even /foo/bar/{realm}/* and keycloak adapter would pull and match a
realm configuration based on this?
More comments inline
On 2/24/2014 2:28 PM, Travis De Silva wrote:
I had a look at your thoughts on how to do this with Aerogear. If I
understand the concept correctly, with the UPS + Keycloak in one bundle
option, we have to update the jboss wildfly config on the fly whenever
we get new tenants. I did not think of this option and not sure if this
could be done with wildfly without having to restart wildfly, but even
if that is possible, that means we are going to have a large list of
wildfly adapter profiles and I don't think that is practical. Just think
even if we get 200 tenants, this is going to make it very complicated.
Also I think the concept is one war per realm so this might not even be
possible for a single application multi tenant model.
There's just no way around a large number of adapter profiles in your
scenario. Each realm has its own public key in which to verify tokens
with. Each of these public keys must be known to the adapter.
FYI: Originally we were going to have Keycloak as a SaaS option hosted
as one server on Openshift sso.keycloak.org or something. Users would
have been able to register and create their own realms. It was decided
that users might be a little scared of the idea of one database holding
everybody's security metadata, so the idea switched to writing a
cartridge which you could configure solely for your organization. I
guess what I'm saying is that a cartridge approach might be best in most
scenarios. Still I want to support your usecase as best we can.
BTW, I really appreciate the feedback. Without users trying our stuff
and giving us ideas on how they would like to use Keycloak, we'll never
be successful. Thanks.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:57 p.m.
My comments inline.
On Tue, Feb 25, 2014 at 12:31 PM, Bill Burke <bburke(a)redhat.com> wrote:
So you want to bind a URL to a specific adapter configuration?
<secured-deployment> might have a <url-pattern> and/or keycloak.json
might be expanded to do the same.
url-pattern could be /foo/bar/*
or even /foo/bar/{realm}/* and keycloak adapter would pull and match a
realm configuration based on this?
yes something like this would do.
More comments inline
On 2/24/2014 2:28 PM, Travis De Silva wrote:
>
> I had a look at your thoughts on how to do this with Aerogear. If I
> understand the concept correctly, with the UPS + Keycloak in one bundle
> option, we have to update the jboss wildfly config on the fly whenever
> we get new tenants. I did not think of this option and not sure if this
> could be done with wildfly without having to restart wildfly, but even
> if that is possible, that means we are going to have a large list of
> wildfly adapter profiles and I don't think that is practical. Just think
> even if we get 200 tenants, this is going to make it very complicated.
> Also I think the concept is one war per realm so this might not even be
> possible for a single application multi tenant model.
>
There's just no way around a large number of adapter profiles in your
scenario. Each realm has its own public key in which to verify tokens
with. Each of these public keys must be known to the adapter.
What about the Per war configuration? I didn't see realm level config in
there? So won't that work?
FYI: Originally we were going to have Keycloak as a SaaS option hosted
as one server on Openshift sso.keycloak.org or something. Users
would
have been able to register and create their own realms. It was decided
that users might be a little scared of the idea of one database holding
everybody's security metadata, so the idea switched to writing a
cartridge which you could configure solely for your organization. I
guess what I'm saying is that a cartridge approach might be best in most
scenarios. Still I want to support your usecase as best we can.
I agree that you guys made the right call. Its the devs who would have
built applications on your SaaS platform who would have had issues with
that approach. But in our case, end users would not have an issue,
especially with the Social Login which ensures that we don't retain their
credentials.
Also I appreciate you trying to support this use case. I also don't think
you can support all use cases but if there is workarounds or hocks to
handle this, then devs like us can work around it. It's ok not to have
these features out of the box but at least if there is a way that is great.
BTW, I really appreciate the feedback. Without users trying our
stuff
and giving us ideas on how they would like to use Keycloak, we'll never
be successful. Thanks.
Thanks for the comment. You might not be aware but I have been following
you from your angry Bill days and I think you are one smart dude and with
guys like you, Keycloak is in good hands :)
--
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
10:10 a.m.
On 2/24/2014 8:57 PM, Travis De Silva wrote:
My comments inline.
On Tue, Feb 25, 2014 at 12:31 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
So you want to bind a URL to a specific adapter configuration?
<secured-deployment> might have a <url-pattern> and/or keycloak.json
might be expanded to do the same.
url-pattern could be /foo/bar/*
or even /foo/bar/{realm}/* and keycloak adapter would pull and match a
realm configuration based on this?
yes something like this would do.
More comments inline
On 2/24/2014 2:28 PM, Travis De Silva wrote:
>
> I had a look at your thoughts on how to do this with Aerogear. If I
> understand the concept correctly, with the UPS + Keycloak in one
bundle
> option, we have to update the jboss wildfly config on the fly
whenever
> we get new tenants. I did not think of this option and not sure
if this
> could be done with wildfly without having to restart wildfly, but
even
> if that is possible, that means we are going to have a large list of
> wildfly adapter profiles and I don't think that is practical.
Just think
> even if we get 200 tenants, this is going to make it very
complicated.
> Also I think the concept is one war per realm so this might not
even be
> possible for a single application multi tenant model.
>
There's just no way around a large number of adapter profiles in your
scenario. Each realm has its own public key in which to verify tokens
with. Each of these public keys must be known to the adapter.
What about the Per war configuration? I didn't see realm level config in
there? So won't that work?
Not sure what you mean. Right now, each war can only be bound to one
realm. I can change the adapter so that you could map URL patterns as
stated earlier, but the realm configuration (public key, URL) has to be
available somewhere.
Maybe just providing the URL of the keycloak server could be enough for
the adapter? It pulls the realm name from the request URI, does a REST
request to the server to see if the realm exists and pulls down
information about the realm, then caches this information in memory.
When you create a realm and the application profile within that realm,
you can just make sure that each of these realm/application combos has
the same client secret. (Or we could provide an option to allow public
non-confidential clients).
Another thing we could do (and what I want to do anyways) is to provide
colocation aware adapters that can interact with the keycloak apis
directly intra-JVM if the keycloak server is deployed on the same
machine. This would help implement a multi-tenant adapter.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12:56 a.m.
My comments are inline.
On Wed, Feb 26, 2014 at 3:10 AM, Bill Burke <bburke(a)redhat.com> wrote:
On 2/24/2014 8:57 PM, Travis De Silva wrote:
> My comments inline.
>
>
> On Tue, Feb 25, 2014 at 12:31 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> So you want to bind a URL to a specific adapter configuration?
> <secured-deployment> might have a <url-pattern> and/or
keycloak.json
> might be expanded to do the same.
>
> url-pattern could be /foo/bar/*
>
> or even /foo/bar/{realm}/* and keycloak adapter would pull and match
a
> realm configuration based on this?
>
> yes something like this would do.
>
> More comments inline
>
> On 2/24/2014 2:28 PM, Travis De Silva wrote:
> >
> > I had a look at your thoughts on how to do this with Aerogear. If
I
> > understand the concept correctly, with the UPS + Keycloak in one
> bundle
> > option, we have to update the jboss wildfly config on the fly
> whenever
> > we get new tenants. I did not think of this option and not sure
> if this
> > could be done with wildfly without having to restart wildfly, but
> even
> > if that is possible, that means we are going to have a large list
of
> > wildfly adapter profiles and I don't think that is practical.
> Just think
> > even if we get 200 tenants, this is going to make it very
> complicated.
> > Also I think the concept is one war per realm so this might not
> even be
> > possible for a single application multi tenant model.
> >
>
> There's just no way around a large number of adapter profiles in your
> scenario. Each realm has its own public key in which to verify
tokens
> with. Each of these public keys must be known to the adapter.
>
>
> What about the Per war configuration? I didn't see realm level config in
> there? So won't that work?
>
Not sure what you mean. Right now, each war can only be bound to one
realm. I can change the adapter so that you could map URL patterns as
stated earlier, but the realm configuration (public key, URL) has to be
available somewhere.
My bad. Sorry. Got confused with many applications under one realm concept.
But forgot that it is still still the same realm :(
Maybe just providing the URL of the keycloak server could be enough
for
the adapter? It pulls the realm name from the request URI, does a REST
request to the server to see if the realm exists and pulls down
information about the realm, then caches this information in memory.
When you create a realm and the application profile within that realm,
you can just make sure that each of these realm/application combos has
the same client secret. (Or we could provide an option to allow public
non-confidential clients).
Another thing we could do (and what I want to do anyways) is to provide
colocation aware adapters that can interact with the keycloak apis
directly intra-JVM if the keycloak server is deployed on the same
machine. This would help implement a multi-tenant adapter.
This is a good idea. I assume that we can co locate the keycloak server in
a cluster environment as well right since keycloak itself does not keep any
state?
Another idea that I was thinking is can't we have a adapter that gets the
realm info from a persistent store like a DB. So if we are using a
database, in the adapter we can configure the database connection settings
so it will pull the realm info from the DB based on the url. Note that the
DB is not within keycloak but in the application side. I am thinking on the
lines of how the org.jboss.security.auth.spi.databaseserverloginmodule
works. Based on a user input for the login credentials, it will get the
info from the db and authenticate. In our case, there is no user input but
we associate the url as the input. Putting the realm info to a db will
enable us to handle larger number of realms and we can do this dynamically
as well without having to add it to the standalone.xml config.
But you will need to make the change to bind one war to multiple realms. As
you indicated earlier, currently its one war one realm. Not sure if this is
just a adapter association or goes deeper into Keycloak.
Is this crazy idea? If so, then maybe the colocation option is more
elegant than the url patterns.
--
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
7:47 a.m.
On 2/26/2014 1:56 AM, Travis De Silva wrote:
This is a good idea. I assume that we can co locate the keycloak
server
in a cluster environment as well right since keycloak itself does not
keep any state?
We keep access code and related metadata in memory between requests at
the moment :( We're planning on stuffing all information needed within
the access code so the token service can be completely stateless and
clusterable. We're probably a month+ away from doing that work though.
Another idea that I was thinking is can't we have a adapter that
gets
the realm info from a persistent store like a DB. So if we are using a
database, in the adapter we can configure the database connection
settings so it will pull the realm info from the DB based on the url.
Note that the DB is not within keycloak but in the application side. I
am thinking on the lines of how
the org.jboss.security.auth.spi.databaseserverloginmodule works. Based
on a user input for the login credentials, it will get the info from the
db and authenticate. In our case, there is no user input but we
associate the url as the input. Putting the realm info to a db will
enable us to handle larger number of realms and we can do this
dynamically as well without having to add it to the standalone.xml config.
But you will need to make the change to bind one war to multiple realms.
As you indicated earlier, currently its one war one realm. Not sure if
this is just a adapter association or goes deeper into Keycloak.
It would require a bunch of refactoring. The code is ugly. Honestly, I
want to refactor this code anyways as there's not much shared code
between AS7 and wildfly adapters.
Is this crazy idea? If so, then maybe the colocation option is more
elegant than the url patterns.
Really depends on how you want to deploy keycloak.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:31 p.m.
As per your future plans, if we can get a stateless keycloak co-location
option and also enable external config in a DB when you refactor the
adapter code, that should cover the needs of most developers who want to go
beyond the out of the box solutions.
BTW, I hope with the above changes it would be possible to associate one
war with multiple realms and this is not a core keycloak structure design
issue.
On Thu, Feb 27, 2014 at 12:47 AM, Bill Burke <bburke(a)redhat.com> wrote:
On 2/26/2014 1:56 AM, Travis De Silva wrote:
> This is a good idea. I assume that we can co locate the keycloak server
> in a cluster environment as well right since keycloak itself does not
> keep any state?
>
>
We keep access code and related metadata in memory between requests at the
moment :( We're planning on stuffing all information needed within the
access code so the token service can be completely stateless and
clusterable. We're probably a month+ away from doing that work though.
Another idea that I was thinking is can't we have a adapter that gets
> the realm info from a persistent store like a DB. So if we are using a
> database, in the adapter we can configure the database connection
> settings so it will pull the realm info from the DB based on the url.
> Note that the DB is not within keycloak but in the application side. I
> am thinking on the lines of how
> the org.jboss.security.auth.spi.databaseserverloginmodule works. Based
> on a user input for the login credentials, it will get the info from the
> db and authenticate. In our case, there is no user input but we
> associate the url as the input. Putting the realm info to a db will
> enable us to handle larger number of realms and we can do this
> dynamically as well without having to add it to the standalone.xml config.
>
> But you will need to make the change to bind one war to multiple realms.
> As you indicated earlier, currently its one war one realm. Not sure if
> this is just a adapter association or goes deeper into Keycloak.
>
>
It would require a bunch of refactoring. The code is ugly. Honestly, I
want to refactor this code anyways as there's not much shared code between
AS7 and wildfly adapters.
Is this crazy idea? If so, then maybe the colocation option is more
> elegant than the url patterns.
>
>
Really depends on how you want to deploy keycloak.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:07 a.m.
On 2/27/2014 11:31 PM, Travis De Silva wrote:
As per your future plans, if we can get a stateless keycloak co-location
option and also enable external config in a DB when you refactor the
adapter code, that should cover the needs of most developers who want to
go beyond the out of the box solutions.
BTW, I hope with the above changes it would be possible to associate one
war with multiple realms and this is not a core keycloak structure
design issue.
How soon you need this by? Yesterday? ;)
Like I said earlier, I don't think colocation is necessarily a
requirement if we a) provided an option for public clients (don't
require a client secret) or b) you had a shared secret between clients
for all realms. 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), then cache this information locally.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
2:57 p.m.
On Sat, Mar 1, 2014 at 1:07 AM, Bill Burke <bburke(a)redhat.com> wrote:
On 2/27/2014 11:31 PM, Travis De Silva wrote:
>
> As per your future plans, if we can get a stateless keycloak co-location
> option and also enable external config in a DB when you refactor the
> adapter code, that should cover the needs of most developers who want to
> go beyond the out of the box solutions.
>
> BTW, I hope with the above changes it would be possible to associate one
> war with multiple realms and this is not a core keycloak structure
> design issue.
>
>
How soon you need this by? Yesterday? ;)
In our project, I was going to build the security model with social login
and was on the verge of using an open source social login library to start
building it when like god sent the keycloak project appeared :) So I am not
the one to demand and happy with the little miracles that come my way.
Having said that, yesterday would be great :) But seriously if your Jira
roadmap is sort of an indicator and beta 1 would be released end of Match,
that timeframe is fine for us :)
Like I said earlier, I don't think colocation is necessarily a requirement
if we a) provided an option for public clients (don't require a client
secret) or b) you had a shared secret between clients for all realms. 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), then cache this information locally.
I guess a shared secret would do. Just wondering why we can't use the
keycloak-admin realm as the top level realm and use it's secret to get the
realm info to be cached locally and from that point onwards, it falls into
the current keycloak flow.
I am assuming that the individual keycloak realm admins (as per the change
done by Stin on KEYCLOAK-292 <https://issues.jboss.org/browse/KEYCLOAK-292>)
will not be able to view the keycloak-admin realm info.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:11 a.m.
I'll work on refactoring the adapters next week to help support this.
Maybe if I get things cleaned up enough and provide some bare bones
support for multi-tenancy you could take it over to help drive for your
requirements?
On 2/28/2014 3:57 PM, Travis De Silva wrote:
On Sat, Mar 1, 2014 at 1:07 AM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
On 2/27/2014 11:31 PM, Travis De Silva wrote:
As per your future plans, if we can get a stateless keycloak
co-location
option and also enable external config in a DB when you refactor the
adapter code, that should cover the needs of most developers who
want to
go beyond the out of the box solutions.
BTW, I hope with the above changes it would be possible to
associate one
war with multiple realms and this is not a core keycloak structure
design issue.
How soon you need this by? Yesterday? ;)
In our project, I was going to build the security model with social
login and was on the verge of using an open source social login library
to start building it when like god sent the keycloak project appeared :)
So I am not the one to demand and happy with the little miracles that
come my way. Having said that, yesterday would be great :) But seriously
if your Jira roadmap is sort of an indicator and beta 1 would be
released end of Match, that timeframe is fine for us :)
Like I said earlier, I don't think colocation is necessarily a
requirement if we a) provided an option for public clients (don't
require a client secret) or b) you had a shared secret between
clients for all realms. 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), then cache
this information locally.
I guess a shared secret would do. Just wondering why we can't use the
keycloak-admin realm as the top level realm and use it's secret to get
the realm info to be cached locally and from that point onwards, it
falls into the current keycloak flow.
I am assuming that the individual keycloak realm admins (as per the
change done by Stin on KEYCLOAK-292
<https://issues.jboss.org/browse/KEYCLOAK-292>) will not be able to view
the keycloak-admin realm info.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:05 a.m.
yes that sounds great. Thanks Bill
On Sun, Mar 2, 2014 at 3:11 AM, Bill Burke <bburke(a)redhat.com> wrote:
I'll work on refactoring the adapters next week to help support
this.
Maybe if I get things cleaned up enough and provide some bare bones support
for multi-tenancy you could take it over to help drive for your
requirements?
On 2/28/2014 3:57 PM, Travis De Silva wrote:
>
> On Sat, Mar 1, 2014 at 1:07 AM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
>
>
> On 2/27/2014 11:31 PM, Travis De Silva wrote:
>
>
> As per your future plans, if we can get a stateless keycloak
> co-location
> option and also enable external config in a DB when you refactor
> the
> adapter code, that should cover the needs of most developers who
> want to
> go beyond the out of the box solutions.
>
> BTW, I hope with the above changes it would be possible to
> associate one
> war with multiple realms and this is not a core keycloak structure
> design issue.
>
>
> How soon you need this by? Yesterday? ;)
>
>
> In our project, I was going to build the security model with social
> login and was on the verge of using an open source social login library
> to start building it when like god sent the keycloak project appeared :)
> So I am not the one to demand and happy with the little miracles that
> come my way. Having said that, yesterday would be great :) But seriously
> if your Jira roadmap is sort of an indicator and beta 1 would be
> released end of Match, that timeframe is fine for us :)
>
>
> Like I said earlier, I don't think colocation is necessarily a
> requirement if we a) provided an option for public clients (don't
> require a client secret) or b) you had a shared secret between
> clients for all realms. 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), then cache
> this information locally.
>
>
> I guess a shared secret would do. Just wondering why we can't use the
> keycloak-admin realm as the top level realm and use it's secret to get
> the realm info to be cached locally and from that point onwards, it
> falls into the current keycloak flow.
>
> I am assuming that the individual keycloak realm admins (as per the
> change done by Stin on KEYCLOAK-292
> <https://issues.jboss.org/browse/KEYCLOAK-292>) will not be able to view
>
> the keycloak-admin realm info.
>
> Bill
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
6:41 p.m.
Travis. Where are you deploying to? Wildfly? JBoss EAP? Gonna try
and work on your extension tomorrow to see if I can get it in by Alpha 3
deadline.
On 3/2/2014 5:05 AM, Travis De Silva wrote:
yes that sounds great. Thanks Bill
On Sun, Mar 2, 2014 at 3:11 AM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
I'll work on refactoring the adapters next week to help support
this. Maybe if I get things cleaned up enough and provide some bare
bones support for multi-tenancy you could take it over to help drive
for your requirements?
On 2/28/2014 3:57 PM, Travis De Silva wrote:
On Sat, Mar 1, 2014 at 1:07 AM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>
<mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> wrote:
On 2/27/2014 11:31 PM, Travis De Silva wrote:
As per your future plans, if we can get a stateless
keycloak
co-location
option and also enable external config in a DB when you
refactor the
adapter code, that should cover the needs of most
developers who
want to
go beyond the out of the box solutions.
BTW, I hope with the above changes it would be possible to
associate one
war with multiple realms and this is not a core
keycloak structure
design issue.
How soon you need this by? Yesterday? ;)
In our project, I was going to build the security model with social
login and was on the verge of using an open source social login
library
to start building it when like god sent the keycloak project
appeared :)
So I am not the one to demand and happy with the little miracles
that
come my way. Having said that, yesterday would be great :) But
seriously
if your Jira roadmap is sort of an indicator and beta 1 would be
released end of Match, that timeframe is fine for us :)
Like I said earlier, I don't think colocation is necessarily a
requirement if we a) provided an option for public clients
(don't
require a client secret) or b) you had a shared secret between
clients for all realms. 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), then
cache
this information locally.
I guess a shared secret would do. Just wondering why we can't
use the
keycloak-admin realm as the top level realm and use it's secret
to get
the realm info to be cached locally and from that point onwards, it
falls into the current keycloak flow.
I am assuming that the individual keycloak realm admins (as per the
change done by Stin on KEYCLOAK-292
<https://issues.jboss.org/__browse/KEYCLOAK-292
<https://issues.jboss.org/browse/KEYCLOAK-292>>) will not be
able to view
the keycloak-admin realm info.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10:48 p.m.
for now Wildfly would do. It would be great if this can be part of Alpha 3
:)
On Tue, Mar 11, 2014 at 10:41 AM, Bill Burke <bburke(a)redhat.com> wrote:
Travis. Where are you deploying to? Wildfly? JBoss EAP? Gonna try
and
work on your extension tomorrow to see if I can get it in by Alpha 3
deadline.
On 3/2/2014 5:05 AM, Travis De Silva wrote:
> yes that sounds great. Thanks Bill
>
>
> On Sun, Mar 2, 2014 at 3:11 AM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> I'll work on refactoring the adapters next week to help support
> this. Maybe if I get things cleaned up enough and provide some bare
> bones support for multi-tenancy you could take it over to help drive
> for your requirements?
>
>
> On 2/28/2014 3:57 PM, Travis De Silva wrote:
>
>
> On Sat, Mar 1, 2014 at 1:07 AM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>
> <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> wrote:
>
>
>
> On 2/27/2014 11:31 PM, Travis De Silva wrote:
>
>
> As per your future plans, if we can get a stateless
> keycloak
> co-location
> option and also enable external config in a DB when you
> refactor the
> adapter code, that should cover the needs of most
> developers who
> want to
> go beyond the out of the box solutions.
>
> BTW, I hope with the above changes it would be possible
> to
> associate one
> war with multiple realms and this is not a core
> keycloak structure
> design issue.
>
>
> How soon you need this by? Yesterday? ;)
>
>
> In our project, I was going to build the security model with
> social
> login and was on the verge of using an open source social login
> library
> to start building it when like god sent the keycloak project
> appeared :)
> So I am not the one to demand and happy with the little miracles
> that
> come my way. Having said that, yesterday would be great :) But
> seriously
> if your Jira roadmap is sort of an indicator and beta 1 would be
> released end of Match, that timeframe is fine for us :)
>
>
> Like I said earlier, I don't think colocation is necessarily
> a
> requirement if we a) provided an option for public clients
> (don't
> require a client secret) or b) you had a shared secret
> between
> clients for all realms. 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), then
> cache
> this information locally.
>
>
> I guess a shared secret would do. Just wondering why we can't
> use the
> keycloak-admin realm as the top level realm and use it's secret
> to get
> the realm info to be cached locally and from that point onwards,
> it
> falls into the current keycloak flow.
>
> I am assuming that the individual keycloak realm admins (as per
> the
> change done by Stin on KEYCLOAK-292
> <https://issues.jboss.org/__browse/KEYCLOAK-292
>
> <https://issues.jboss.org/browse/KEYCLOAK-292>>) will not be
> able to view
>
> the keycloak-admin realm info.
>
> Bill
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:56 a.m.
What are developers deploying to your platform? Are they deploying WARs?
A couple of ideas:
* You could use the admin api (or model api) to create the realms for you. Then you could
use the management interfaces to WildFly to add the KC config for a WAR before deploying
it. You can access the management api through rest, or you can also call it directly from
a WAR (see
http://management-platform.blogspot.in/2012/07/co-located-management-clie...). If
developers are deploying WARs you probably want to do this any ways as I'd imagine
you'd want more control of the deployment process than just dumping into
standalone/deployments?
* Adapters aren't that complex, so you can create your own (or fork one of ours) that
would then let you pull config from where you'd like. For example instead of storing
config in keycloak.json you could save this in a database or something.
If you describe in a bit more detail exactly what you're trying to achieve, and also
propose ideas/changes to KC, that would be great :)
With regards to LiveOak it's going to be multi-tenant, but we have recently decided
that the container itself won't be. A single container instance can contain multiple
apps, but not multiple tenants. Instead we'll leverage OpenShift and create separate
gears for each tenant. There's just to many issues with having multi-tenancy within a
single process (shared cpu, security, custom code, etc, etc.) and with technologies such
as Docker creating an container instance per-tenant is light weight.
Cheers,
Stian
----- Original Message -----
From: "Travis De Silva" <traviskds(a)gmail.com>
To: keycloak-user(a)lists.jboss.org
Sent: Sunday, 23 February, 2014 3:46:19 AM
Subject: Re: [keycloak-user] Multi Tenancy
I just read the discussions on KEYCLOAK-292 on the developer mailing list.
http://lists.jboss.org/pipermail/keycloak-dev/2014-February/001378.html
The concept of creating an application under the keycloak-admin realm for
each realm created looks interesting.
When it comes to multi tenancy, I think the issue is around the application
installation process. If there is a way where we don't have to provide
individual application level keycloak.json's or WildFly/JBoss subsystem
XML's, then we are getting closer to multi tenancy. I am thinking can this
be done at a keycloak top level or the ability to use wildcards for the
resource elements in the json.
Is LiveOak a multi tenancy platform? Wondering if they would need such a
feature.
On Sun, Feb 23, 2014 at 2:22 PM, Travis De Silva < traviskds(a)gmail.com >
wrote:
I was initially under the impression that I can configure realms as tenants
and use KeyCloak for applications that are designed for multi tenancy.
But now I have discovered that this is not possible, at least not possible to
do it on demand. I hope I am wrong and someone can correct me.
Basically what I was trying to do was, when someone signs up to my
application platform, I was going to create a realm programmatically via the
API. Hence the feature request I raised to have a realm level admin
https://issues.jboss.org/browse/KEYCLOAK-292
But that means, I will then have to either configure my Wildfly
standalone.xml config with the new realm or add the installation json to my
war and redeploy it. This is obviously not ideal for a on demand multi
tenant application.
Maybe using Roles and create unique roles per tenant which hopefully I can do
programatically via the API. I think I might be able to get something going
like this but it just feels very hacky and not elegant.
Is there any other elegant way? Is Keycloak designed for multi tenancy
environments?
Cheers
Travis
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
10:47 p.m.
My comments are inline
On Tue, Feb 25, 2014 at 8:56 PM, Stian Thorgersen <stian(a)redhat.com> wrote:
What are developers deploying to your platform? Are they deploying
WARs?
Yes its WARs. Actually it would be just one war at present that consist of
all our service layer application code. (i.e. JAX-RS, EJB3, JPA, Camel and
related component libraries)
A couple of ideas:
* You could use the admin api (or model api) to create the realms for you.
Then you could use the management interfaces to WildFly to add the KC
config for a WAR before deploying it. You can access the management api
through rest, or you can also call it directly from a WAR (see
http://management-platform.blogspot.in/2012/07/co-located-management-clie...).
If developers are deploying WARs you probably want to do this any ways as
I'd imagine you'd want more control of the deployment process than just
dumping into standalone/deployments?
This is an option but not very elegant. Ideally I would prefer to handle
this from our application side without having to interact with the
application sever config, in this case Wildfly.
* Adapters aren't that complex, so you can create your own (or fork one of
ours) that would then let you pull config from where you'd like.
For
example instead of storing config in keycloak.json you could save this in a
database or something.
I guess if there is no other way, then this maybe the way to do it. Where I
can pick the realm public keys from our application DB. But would like to
explore what Bill is suggesting a bit more. If we could use wildcard uri
mappings. Will reply to his post in more detail on my thoughts.
If you describe in a bit more detail exactly what you're trying to
achieve, and also propose ideas/changes to KC, that would be great :
With regards to LiveOak it's going to be multi-tenant, but we
have
recently decided that the container itself won't be. A single container
instance can contain multiple apps, but not multiple tenants. Instead we'll
leverage OpenShift and create separate gears for each tenant. There's just
to many issues with having multi-tenancy within a single process (shared
cpu, security, custom code, etc, etc.) and with technologies such as Docker
creating an container instance per-tenant is light weight.
Yes in your model, you are spinning up separate gears (and since OpenShift
at present uses AWS separate instances). This is one way to do multi
tenancy and yes I agree with technologies such as Docker makes it more
seamless but still this would not be the most cost effective option for our
potential clients.
With our model, its actually very simple. We have one application code
(that can run in a WildFly HA environment with Infinispan etc) , one DB
with sharding. Tenants are separated by a tenant ID in the DB. Since ours
is a application for a specific domain, we can do this. For example what
the servicenow.com guys have done for IT service desks. Not sure of their
architecture but basically all tenants get the same feature set with
customisable templates allowing tenants to pick the features and
functionality that they need.
I understand this does not make sense for a platform like LiveOak, as you
guys are creating a generic platform for developers like us to develop and
deploy diverse applications for mobile and web clients. (BTW, I am excited
about the LiveOak BaaS project as well. Have developed iOS and Android push
notifications and it was really messy, especially with iOS)
Since our application is not generic but specific to a domain and business
function, its more cost effective to manage your tenants in a single
application/db. Also if your target market segment is the small business,
and you want to keep the cost low for them to subscribe to our platform,
our model makes sense. Also with all the elasticity that you get with cloud
computing today (***cough** AWS), we can scale up and down based on usage
demand.
Cheers,
Stian
----- Original Message -----
> From: "Travis De Silva" <traviskds(a)gmail.com>
> To: keycloak-user(a)lists.jboss.org
> Sent: Sunday, 23 February, 2014 3:46:19 AM
> Subject: Re: [keycloak-user] Multi Tenancy
>
> I just read the discussions on KEYCLOAK-292 on the developer mailing
list.
> http://lists.jboss.org/pipermail/keycloak-dev/2014-February/001378.html
>
> The concept of creating an application under the keycloak-admin realm for
> each realm created looks interesting.
>
> When it comes to multi tenancy, I think the issue is around the
application
> installation process. If there is a way where we don't have to provide
> individual application level keycloak.json's or WildFly/JBoss subsystem
> XML's, then we are getting closer to multi tenancy. I am thinking can
this
> be done at a keycloak top level or the ability to use wildcards for the
> resource elements in the json.
>
> Is LiveOak a multi tenancy platform? Wondering if they would need such a
> feature.
>
>
> On Sun, Feb 23, 2014 at 2:22 PM, Travis De Silva < traviskds(a)gmail.com >
> wrote:
>
>
>
> I was initially under the impression that I can configure realms as
tenants
> and use KeyCloak for applications that are designed for multi tenancy.
>
> But now I have discovered that this is not possible, at least not
possible to
> do it on demand. I hope I am wrong and someone can correct me.
>
> Basically what I was trying to do was, when someone signs up to my
> application platform, I was going to create a realm programmatically via
the
> API. Hence the feature request I raised to have a realm level admin
> https://issues.jboss.org/browse/KEYCLOAK-292
>
> But that means, I will then have to either configure my Wildfly
> standalone.xml config with the new realm or add the installation json to
my
> war and redeploy it. This is obviously not ideal for a on demand multi
> tenant application.
>
> Maybe using Roles and create unique roles per tenant which hopefully I
can do
> programatically via the API. I think I might be able to get something
going
> like this but it just feels very hacky and not elegant.
>
> Is there any other elegant way? Is Keycloak designed for multi tenancy
> environments?
>
> Cheers
> Travis
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
3955
days inactive
3971
days old
18 comments
3 participants
participants (3)
-
Bill Burke -
Stian Thorgersen -
Travis De Silva