4:14 a.m.
Hi!
I searched Jira and the mailing lists if realm templates have been
discussed before, but didn't find anything. Apologies if I missed an
already existing thread.
What would you think of adding support for realm templates?
The idea would be similar to client templates. One could define common
properties in a realm template and create concrete realms based on the
template. Whenever any of the common properties need to be changed, it
would only be necessary to make the changes on the template instead of
changing individual realms separately. Changes to the template would
propagate to realms automatically.
I would like to see at least realm settings and roles being defined on the
template. Maybe also clients and groups. Identity providers would also be
useful. Keys, certificates, users and various credentials would naturally
be specific to each realm.
If possible it would be great if one could choose to override the settings
in the template so that the template would only define default values. But
if it complicates the implementation too much I'm sure the feature is just
as useful without this possibility.
I think this would make the life of SaaS application developers with realm
per tenant much easier as you would not need to write custom tools to
automate change propagation to realms.
Could this be something for 2.0?
Best regards,
Thomas
7:04 a.m.
Having links between realms like this is not great. It shouldn't matter if
two realms are on the same server or on different servers. In fact in a
SaaS environment you should most likely not have many tenants on a single
server and rather shard it.
It would also be a fairly tedious thing to implement. Realms would need
some inheritance, then there's the admin console to worry about. At the
moment there's not even a "shared" place for multiple realms, so no logical
place to create/edit realm templates.
Another thing is that in the future we plan to remove master realm concept
completely. Instead we'll have a trusted realm option that will use
identity brokering behind the covers. The idea is that a single admin can
manage multiple realms independently on what servers the realm are located
on. This would mean that an admin in reality can only manage a single
realm, but automatically authenticate to other realms to manage those as
well without re-authentication. There would be no cross-realm permissions
though, so no "master" realm admin that can manage realm templates.
On 18 May 2016 at 11:14, Thomas Raehalme <thomas.raehalme(a)aitiofinland.com>
wrote:
Hi!
I searched Jira and the mailing lists if realm templates have been
discussed before, but didn't find anything. Apologies if I missed an
already existing thread.
What would you think of adding support for realm templates?
The idea would be similar to client templates. One could define common
properties in a realm template and create concrete realms based on the
template. Whenever any of the common properties need to be changed, it
would only be necessary to make the changes on the template instead of
changing individual realms separately. Changes to the template would
propagate to realms automatically.
I would like to see at least realm settings and roles being defined on the
template. Maybe also clients and groups. Identity providers would also be
useful. Keys, certificates, users and various credentials would naturally
be specific to each realm.
If possible it would be great if one could choose to override the settings
in the template so that the template would only define default values. But
if it complicates the implementation too much I'm sure the feature is just
as useful without this possibility.
I think this would make the life of SaaS application developers with realm
per tenant much easier as you would not need to write custom tools to
automate change propagation to realms.
Could this be something for 2.0?
Best regards,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:52 a.m.
On Wed, May 18, 2016 at 3:04 PM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
Having links between realms like this is not great. It shouldn't
matter if
two realms are on the same server or on different servers. In fact in a
SaaS environment you should most likely not have many tenants on a single
server and rather shard it.
By sharding do you mean that the environment should have multiple
independent Keycloak instances/clusters to which tenants are distributed?
It would also be a fairly tedious thing to implement. Realms would need
some inheritance, then there's the admin console to worry about.
At the
moment there's not even a "shared" place for multiple realms, so no
logical
place to create/edit realm templates.
Oh I never presumed this would be easy task to do :-)
Another thing is that in the future we plan to remove master realm
concept
completely. Instead we'll have a trusted realm option that will use
identity brokering behind the covers. The idea is that a single admin can
manage multiple realms independently on what servers the realm are located
on. This would mean that an admin in reality can only manage a single
realm, but automatically authenticate to other realms to manage those as
well without re-authentication. There would be no cross-realm permissions
though, so no "master" realm admin that can manage realm templates.
Do you mean that in the future the current master realm will be
just-another-realm, but when creating new realms they automatically trust
the master?
Best regards,
Thomas
7:59 a.m.
On 18 May 2016 at 14:52, Thomas Raehalme <thomas.raehalme(a)aitiofinland.com>
wrote:
On Wed, May 18, 2016 at 3:04 PM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> Having links between realms like this is not great. It shouldn't matter
> if two realms are on the same server or on different servers. In fact in a
> SaaS environment you should most likely not have many tenants on a single
> server and rather shard it.
>
By sharding do you mean that the environment should have multiple
independent Keycloak instances/clusters to which tenants are distributed?
Yes. At first our plan was to have a single Keycloak support multiple
tenants in a SaaS environment. However, we decided that this level of
tenants would be better achieved by having completely separate instances.
It would also be a fairly tedious thing to implement. Realms would need
> some inheritance, then there's the admin console to worry about. At the
> moment there's not even a "shared" place for multiple realms, so no
logical
> place to create/edit realm templates.
>
Oh I never presumed this would be easy task to do :-)
I meant we're very unlikely to accept the feature due to the amount of
complexity that would be involved. It also has very little benefit in the
use-cases we've designed Keycloak for and wouldn't work when realms are
located on separate instances which we expect would be the norm.
> Another thing is that in the future we plan to remove master realm
> concept completely. Instead we'll have a trusted realm option that will use
> identity brokering behind the covers. The idea is that a single admin can
> manage multiple realms independently on what servers the realm are located
> on. This would mean that an admin in reality can only manage a single
> realm, but automatically authenticate to other realms to manage those as
> well without re-authentication. There would be no cross-realm permissions
> though, so no "master" realm admin that can manage realm templates.
>
Do you mean that in the future the current master realm will be
just-another-realm, but when creating new realms they automatically trust
the master?
There will be no special "master" realm at all. We've not fully figured out
the bootstrapping of new realms. Rather than having a "master" realm it
would be possible to link realms together which will enable cross-realm
management. One key aspect of this is that not only will you be able to
manage multiple realms within the Keycloak admin console, but you will also
be able to authenticate to your own applications that exist in different
realms.
Best regards,
Thomas
8:07 a.m.
On Wed, May 18, 2016 at 3:59 PM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
On 18 May 2016 at 14:52, Thomas Raehalme <thomas.raehalme(a)aitiofinland.com
> wrote:
>
> By sharding do you mean that the environment should have multiple
> independent Keycloak instances/clusters to which tenants are distributed?
>
Yes. At first our plan was to have a single Keycloak support multiple
tenants in a SaaS environment. However, we decided that this level of
tenants would be better achieved by having completely separate instances.
Ok, thanks for the clarification. I don't think from a developer point of
view it makes a big difference to have multiple instances if you're already
working with multiple realms. My concern, however, is how to manage all
those realms hence my original message. At the moment there is no tool to
support that, or at least I am not aware of one.
It would also be a fairly tedious thing to implement. Realms would need
>> some inheritance, then there's the admin console to worry
about. At the
>> moment there's not even a "shared" place for multiple realms, so no
logical
>> place to create/edit realm templates.
>>
>
> Oh I never presumed this would be easy task to do :-)
>
I meant we're very unlikely to accept the feature due to the amount of
complexity that would be involved. It also has very little benefit in the
use-cases we've designed Keycloak for and wouldn't work when realms are
located on separate instances which we expect would be the norm.
One important use case in my opinion is the possibility to ensure that in a
SaaS environment all realms contain the required data. If you, for example,
add a new role in your SaaS application, you'll need to make sure the role
is added to all realms (and assign it to users properly).
Another thing is that in the future we plan to remove master realm concept
> completely. Instead we'll have a trusted realm option that
will use
> identity brokering behind the covers. The idea is that a single admin can
> manage multiple realms independently on what servers the realm are located
> on. This would mean that an admin in reality can only manage a single
> realm, but automatically authenticate to other realms to manage those as
> well without re-authentication. There would be no cross-realm permissions
> though, so no "master" realm admin that can manage realm templates.
>
> Do you mean that in the future the current master realm will be
> just-another-realm, but when creating new realms they automatically trust
> the master?
>
There will be no special "master" realm at all. We've not fully figured
out the bootstrapping of new realms. Rather than having a "master" realm it
would be possible to link realms together which will enable cross-realm
management. One key aspect of this is that not only will you be able to
manage multiple realms within the Keycloak admin console, but you will also
be able to authenticate to your own applications that exist in different
realms.
How is that different from the currently available keycloak-oidc identity
provider?
Best regards,
Thomas
8:19 a.m.
On 18 May 2016 at 15:07, Thomas Raehalme <thomas.raehalme(a)aitiofinland.com>
wrote:
On Wed, May 18, 2016 at 3:59 PM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
>
> On 18 May 2016 at 14:52, Thomas Raehalme <
> thomas.raehalme(a)aitiofinland.com> wrote:
>>
>> By sharding do you mean that the environment should have multiple
>> independent Keycloak instances/clusters to which tenants are distributed?
>>
>
> Yes. At first our plan was to have a single Keycloak support multiple
> tenants in a SaaS environment. However, we decided that this level of
> tenants would be better achieved by having completely separate instances.
>
Ok, thanks for the clarification. I don't think from a developer point of
view it makes a big difference to have multiple instances if you're already
working with multiple realms. My concern, however, is how to manage all
those realms hence my original message. At the moment there is no tool to
support that, or at least I am not aware of one.
Fair point, but any solution would need to work with realms that are
located on the same instance as well as on different instances.
It would also be a fairly tedious thing to implement. Realms would need
>>> some inheritance, then there's the admin console to worry about. At the
>>> moment there's not even a "shared" place for multiple realms,
so no logical
>>> place to create/edit realm templates.
>>>
>>
>> Oh I never presumed this would be easy task to do :-)
>>
>
> I meant we're very unlikely to accept the feature due to the amount of
> complexity that would be involved. It also has very little benefit in the
> use-cases we've designed Keycloak for and wouldn't work when realms are
> located on separate instances which we expect would be the norm.
>
One important use case in my opinion is the possibility to ensure that in
a SaaS environment all realms contain the required data. If you, for
example, add a new role in your SaaS application, you'll need to make sure
the role is added to all realms (and assign it to users properly).
You could do that through admin rest endpoints
Another thing is that in the future we plan to remove master realm
>> concept completely. Instead we'll have a trusted realm option that will use
>> identity brokering behind the covers. The idea is that a single admin can
>> manage multiple realms independently on what servers the realm are located
>> on. This would mean that an admin in reality can only manage a single
>> realm, but automatically authenticate to other realms to manage those as
>> well without re-authentication. There would be no cross-realm permissions
>> though, so no "master" realm admin that can manage realm templates.
>>
>> Do you mean that in the future the current master realm will be
>> just-another-realm, but when creating new realms they automatically trust
>> the master?
>>
>
> There will be no special "master" realm at all. We've not fully
figured
> out the bootstrapping of new realms. Rather than having a "master" realm
it
> would be possible to link realms together which will enable cross-realm
> management. One key aspect of this is that not only will you be able to
> manage multiple realms within the Keycloak admin console, but you will also
> be able to authenticate to your own applications that exist in different
> realms.
>
How is that different from the currently available keycloak-oidc identity
provider?
It would use keycloak-oidc identity provider behind the covers, but the
bootstrapping would be a single click button. Rather than a button on login
form we'd also hide the button and use idp_hint to automatically "login" to
another realm.
Best regards,
Thomas
8:54 a.m.
This would need to be a community contribution. We (the RHT/Keycloak
open source devs) have too many things scheduled in queue right now and
I don't think there would be a lot of users that would request this feature.
On 5/18/16 9:19 AM, Stian Thorgersen wrote:
On 18 May 2016 at 15:07, Thomas Raehalme
<thomas.raehalme(a)aitiofinland.com
<mailto:thomas.raehalme@aitiofinland.com>> wrote:
On Wed, May 18, 2016 at 3:59 PM, Stian Thorgersen
<sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote:
On 18 May 2016 at 14:52, Thomas Raehalme
<thomas.raehalme(a)aitiofinland.com
<mailto:thomas.raehalme@aitiofinland.com>> wrote:
By sharding do you mean that the environment should have
multiple independent Keycloak instances/clusters to which
tenants are distributed?
Yes. At first our plan was to have a single Keycloak support
multiple tenants in a SaaS environment. However, we decided
that this level of tenants would be better achieved by having
completely separate instances.
Ok, thanks for the clarification. I don't think from a developer
point of view it makes a big difference to have multiple instances
if you're already working with multiple realms. My concern,
however, is how to manage all those realms hence my original
message. At the moment there is no tool to support that, or at
least I am not aware of one.
Fair point, but any solution would need to work with realms that are
located on the same instance as well as on different instances.
It would also be a fairly tedious thing to implement.
Realms would need some inheritance, then there's the
admin console to worry about. At the moment there's
not even a "shared" place for multiple realms, so no
logical place to create/edit realm templates.
Oh I never presumed this would be easy task to do :-)
I meant we're very unlikely to accept the feature due to the
amount of complexity that would be involved. It also has very
little benefit in the use-cases we've designed Keycloak for
and wouldn't work when realms are located on separate
instances which we expect would be the norm.
One important use case in my opinion is the possibility to ensure
that in a SaaS environment all realms contain the required data.
If you, for example, add a new role in your SaaS application,
you'll need to make sure the role is added to all realms (and
assign it to users properly).
You could do that through admin rest endpoints
Another thing is that in the future we plan to remove
master realm concept completely. Instead we'll have a
trusted realm option that will use identity brokering
behind the covers. The idea is that a single admin can
manage multiple realms independently on what servers the
realm are located on. This would mean that an admin in
reality can only manage a single realm, but automatically
authenticate to other realms to manage those as well
without re-authentication. There would be no cross-realm
permissions though, so no "master" realm admin that can
manage realm templates.
Do you mean that in the future the current master realm
will be just-another-realm, but when creating new realms
they automatically trust the master?
There will be no special "master" realm at all. We've not
fully figured out the bootstrapping of new realms. Rather than
having a "master" realm it would be possible to link realms
together which will enable cross-realm management. One key
aspect of this is that not only will you be able to manage
multiple realms within the Keycloak admin console, but you
will also be able to authenticate to your own applications
that exist in different realms.
How is that different from the currently available keycloak-oidc
identity provider?
It would use keycloak-oidc identity provider behind the covers, but
the bootstrapping would be a single click button. Rather than a button
on login form we'd also hide the button and use idp_hint to
automatically "login" to another realm.
Best regards,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:39 a.m.
IMO we shouldn't accept this if it was a community contribution as it would
add unnecessary complexity
On 18 May 2016 at 15:54, Bill Burke <bburke(a)redhat.com> wrote:
This would need to be a community contribution. We (the RHT/Keycloak
open
source devs) have too many things scheduled in queue right now and I don't
think there would be a lot of users that would request this feature.
On 5/18/16 9:19 AM, Stian Thorgersen wrote:
On 18 May 2016 at 15:07, Thomas Raehalme <thomas.raehalme(a)aitiofinland.com
> wrote:
>
>
> On Wed, May 18, 2016 at 3:59 PM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>>
>> On 18 May 2016 at 14:52, Thomas Raehalme <
>> <thomas.raehalme@aitiofinland.com>thomas.raehalme(a)aitiofinland.com>
>> wrote:
>>>
>>> By sharding do you mean that the environment should have multiple
>>> independent Keycloak instances/clusters to which tenants are distributed?
>>>
>>
>> Yes. At first our plan was to have a single Keycloak support multiple
>> tenants in a SaaS environment. However, we decided that this level of
>> tenants would be better achieved by having completely separate instances.
>>
>
> Ok, thanks for the clarification. I don't think from a developer point of
> view it makes a big difference to have multiple instances if you're already
> working with multiple realms. My concern, however, is how to manage all
> those realms hence my original message. At the moment there is no tool to
> support that, or at least I am not aware of one.
>
Fair point, but any solution would need to work with realms that are
located on the same instance as well as on different instances.
>
> It would also be a fairly tedious thing to implement. Realms would need
>>>> some inheritance, then there's the admin console to worry about. At
the
>>>> moment there's not even a "shared" place for multiple
realms, so no logical
>>>> place to create/edit realm templates.
>>>>
>>>
>>> Oh I never presumed this would be easy task to do :-)
>>>
>>
>> I meant we're very unlikely to accept the feature due to the amount of
>> complexity that would be involved. It also has very little benefit in the
>> use-cases we've designed Keycloak for and wouldn't work when realms are
>> located on separate instances which we expect would be the norm.
>>
>
> One important use case in my opinion is the possibility to ensure that in
> a SaaS environment all realms contain the required data. If you, for
> example, add a new role in your SaaS application, you'll need to make sure
> the role is added to all realms (and assign it to users properly).
>
You could do that through admin rest endpoints
>
>
> Another thing is that in the future we plan to remove master realm
>>> concept completely. Instead we'll have a trusted realm option that will
use
>>> identity brokering behind the covers. The idea is that a single admin can
>>> manage multiple realms independently on what servers the realm are located
>>> on. This would mean that an admin in reality can only manage a single
>>> realm, but automatically authenticate to other realms to manage those as
>>> well without re-authentication. There would be no cross-realm permissions
>>> though, so no "master" realm admin that can manage realm
templates.
>>>
>>> Do you mean that in the future the current master realm will be
>>> just-another-realm, but when creating new realms they automatically trust
>>> the master?
>>>
>>
>> There will be no special "master" realm at all. We've not fully
figured
>> out the bootstrapping of new realms. Rather than having a "master"
realm it
>> would be possible to link realms together which will enable cross-realm
>> management. One key aspect of this is that not only will you be able to
>> manage multiple realms within the Keycloak admin console, but you will also
>> be able to authenticate to your own applications that exist in different
>> realms.
>>
>
> How is that different from the currently available keycloak-oidc identity
> provider?
>
It would use keycloak-oidc identity provider behind the covers, but the
bootstrapping would be a single click button. Rather than a button on login
form we'd also hide the button and use idp_hint to automatically "login"
to
another realm.
>
> Best regards,
> Thomas
>
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3144
days inactive
3144
days old
7 comments
3 participants
participants (3)
-
Bill Burke -
Stian Thorgersen -
Thomas Raehalme