1:41 p.m.
I'm moving a web application with REST services from Picketlink to
Keycloak. This is a multi-tentant application (1k+ tenants) where single
user accounts can belong to multiple tenants. In Picketlink, this was
accomplished using Tiers. So there is a single realm, but one Tier per
tenant. Its not clear what the analog is in Keycloak.
We considered multiple realms, but both the number of tenants and the hard
requirement to allow a single user cross tenants seems to make this a
nonstarter.
The best idea we have so far is to have a single realm, but create
namespaced security artifacts: e.g. Tenant1.Admins. This is not ideal as we
were hoping for more separation between tenants. I did see this
<http://lists.jboss.org/pipermail/keycloak-dev/2013-July/000116.html> which
suggests that Picketlink Tiers equate to Resources, but its not clear how.
Certainly there does not seem to be any separation of security artifacts
within a Resource per se.
Advice?
2:16 p.m.
Define "tenant" and what it accomplishes and how you are using tiers to
implement this functionality and I might be able to help.
On 7/20/16 2:41 PM, Keith Dev wrote:
I'm moving a web application with REST services from Picketlink
to
Keycloak. This is a multi-tentant application (1k+ tenants) where
single user accounts can belong to multiple tenants. In Picketlink,
this was accomplished using Tiers. So there is a single realm, but one
Tier per tenant. Its not clear what the analog is in Keycloak.
We considered multiple realms, but both the number of tenants and the
hard requirement to allow a single user cross tenants seems to make
this a nonstarter.
The best idea we have so far is to have a single realm, but create
namespaced security artifacts: e.g. Tenant1.Admins. This is not ideal
as we were hoping for more separation between tenants. I did see this
<http://lists.jboss.org/pipermail/keycloak-dev/2013-July/000116.html> which
suggests that Picketlink Tiers equate to Resources, but its not clear
how. Certainly there does not seem to be any separation of security
artifacts within a Resource per se.
Advice?
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:44 p.m.
Consider an independent contractor (user) that works for two companies
(tenant) on different projects (resource). Control of the project belongs
to the company, not the contractor, so the security artifacts (resources,
groups, roles) belong with the company. But we want to provide a user
interface to the contractor where they do not have to manage multiple
accounts.
Tiers in picketlink allow for each tenant to have their own set of groups
and roles (though they have duplicate meanings for each).
I'm open to any solutions, including revisiting one realm per tenant
(though I have some concerns
<https://issues.jboss.org/browse/KEYCLOAK-3067> about
whether or not keycloak is meant to support 1k+ realms).
Is that sufficient explanation?
Thanks, Keith
On Wed, Jul 20, 2016 at 2:18 PM Bill Burke <bburke(a)redhat.com> wrote:
Define "tenant" and what it accomplishes and how you are
using tiers to
implement this functionality and I might be able to help.
On 7/20/16 2:41 PM, Keith Dev wrote:
I'm moving a web application with REST services from Picketlink to
Keycloak. This is a multi-tentant application (1k+ tenants) where single
user accounts can belong to multiple tenants. In Picketlink, this was
accomplished using Tiers. So there is a single realm, but one Tier per
tenant. Its not clear what the analog is in Keycloak.
We considered multiple realms, but both the number of tenants and the hard
requirement to allow a single user cross tenants seems to make this a
nonstarter.
The best idea we have so far is to have a single realm, but create
namespaced security artifacts: e.g. Tenant1.Admins. This is not ideal as we
were hoping for more separation between tenants. I did see this
<http://lists.jboss.org/pipermail/keycloak-dev/2013-July/000116.html> which
suggests that Picketlink Tiers equate to Resources, but its not clear how.
Certainly there does not seem to be any separation of security artifacts
within a Resource per se.
Advice?
_______________________________________________
keycloak-user mailing
listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
4:23 p.m.
Keycloak was written as an authentication server. Its initial
authorization features were quite limited to role-based apps.
One realm manages a set of users, roles, groups,and clients
(applications). There is a realm-level namespace for roles. Each
client has a role namespace. Groups can be managed in a hierarchy and
associated with roles. Groups can have their own role mappings and
attributes. Users can join groups. Users can be assigned roles.
Keycloak 2.0 has an Authorization feature where you can define Resources
and access policies based on those resources. Companies could each be a
group. Then I think you can say things like "If user belong to group A
and role B he can access resource C".
Meh, doesn't really map well to your use case. What we've found is that
everybody has their own structure that is very different or slightly
different than anyone else.
On 7/20/16 3:44 PM, Keith Dev wrote:
Consider an independent contractor (user) that works for two
companies
(tenant) on different projects (resource). Control of the project
belongs to the company, not the contractor, so the security artifacts
(resources, groups, roles) belong with the company. But we want to
provide a user interface to the contractor where they do not have to
manage multiple accounts.
Tiers in picketlink allow for each tenant to have their own set of
groups and roles (though they have duplicate meanings for each).
I'm open to any solutions, including revisiting one realm per tenant
(though I have some concerns
<https://issues.jboss.org/browse/KEYCLOAK-3067> about whether or not
keycloak is meant to support 1k+ realms).
Is that sufficient explanation?
Thanks, Keith
On Wed, Jul 20, 2016 at 2:18 PM Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Define "tenant" and what it accomplishes and how you are using
tiers to implement this functionality and I might be able to help.
On 7/20/16 2:41 PM, Keith Dev wrote:
> I'm moving a web application with REST services from Picketlink
> to Keycloak. This is a multi-tentant application (1k+ tenants)
> where single user accounts can belong to multiple tenants. In
> Picketlink, this was accomplished using Tiers. So there is a
> single realm, but one Tier per tenant. Its not clear what the
> analog is in Keycloak.
>
> We considered multiple realms, but both the number of tenants and
> the hard requirement to allow a single user cross tenants seems
> to make this a nonstarter.
>
> The best idea we have so far is to have a single realm, but
> create namespaced security artifacts: e.g. Tenant1.Admins. This
> is not ideal as we were hoping for more separation between
> tenants. I did see this
> <http://lists.jboss.org/pipermail/keycloak-dev/2013-July/000116.html>
which
> suggests that Picketlink Tiers equate to Resources, but its not
> clear how. Certainly there does not seem to be any separation of
> security artifacts within a Resource per se.
>
> Advice?
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
4:52 p.m.
Yea - I've tried to swizzle things around to get something approaching what
we already have. Its not been straightforward, but I think with some
creative naming, we can get there.
Btw - regarding the Client Roles: I don't think you can't add one to a Role
Policy in Clients > ${client} > Authorization > Policies > Add Role Policy.
Only Realm Roles show up in the search/drop down for Roles.
Thanks, Keith
On Wed, Jul 20, 2016 at 4:23 PM Bill Burke <bburke(a)redhat.com> wrote:
Keycloak was written as an authentication server. Its initial
authorization features were quite limited to role-based apps.
One realm manages a set of users, roles, groups,and clients
(applications). There is a realm-level namespace for roles. Each client
has a role namespace. Groups can be managed in a hierarchy and associated
with roles. Groups can have their own role mappings and attributes. Users
can join groups. Users can be assigned roles.
Keycloak 2.0 has an Authorization feature where you can define Resources
and access policies based on those resources. Companies could each be a
group. Then I think you can say things like "If user belong to group A and
role B he can access resource C".
Meh, doesn't really map well to your use case. What we've found is that
everybody has their own structure that is very different or slightly
different than anyone else.
On 7/20/16 3:44 PM, Keith Dev wrote:
Consider an independent contractor (user) that works for two companies
(tenant) on different projects (resource). Control of the project belongs
to the company, not the contractor, so the security artifacts (resources,
groups, roles) belong with the company. But we want to provide a user
interface to the contractor where they do not have to manage multiple
accounts.
Tiers in picketlink allow for each tenant to have their own set of groups
and roles (though they have duplicate meanings for each).
I'm open to any solutions, including revisiting one realm per tenant
(though I have some concerns
<https://issues.jboss.org/browse/KEYCLOAK-3067> about whether or not
keycloak is meant to support 1k+ realms).
Is that sufficient explanation?
Thanks, Keith
On Wed, Jul 20, 2016 at 2:18 PM Bill Burke <bburke(a)redhat.com> wrote:
> Define "tenant" and what it accomplishes and how you are using tiers to
> implement this functionality and I might be able to help.
>
> On 7/20/16 2:41 PM, Keith Dev wrote:
>
> I'm moving a web application with REST services from Picketlink to
> Keycloak. This is a multi-tentant application (1k+ tenants) where single
> user accounts can belong to multiple tenants. In Picketlink, this was
> accomplished using Tiers. So there is a single realm, but one Tier per
> tenant. Its not clear what the analog is in Keycloak.
>
> We considered multiple realms, but both the number of tenants and the
> hard requirement to allow a single user cross tenants seems to make this a
> nonstarter.
>
> The best idea we have so far is to have a single realm, but create
> namespaced security artifacts: e.g. Tenant1.Admins. This is not ideal as we
> were hoping for more separation between tenants. I did see this
> <http://lists.jboss.org/pipermail/keycloak-dev/2013-July/000116.html> which
> suggests that Picketlink Tiers equate to Resources, but its not clear how.
> Certainly there does not seem to be any separation of security artifacts
> within a Resource per se.
>
> Advice?
>
>
> _______________________________________________
> keycloak-user mailing
listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
6:18 p.m.
----- Original Message -----
From: "Keith Dev" <keith.dev(a)pobox.com>
To: "Bill Burke" <bburke(a)redhat.com>, keycloak-user(a)lists.jboss.org
Sent: Wednesday, July 20, 2016 6:52:27 PM
Subject: Re: [keycloak-user] Picketlink -> Keycloak
Yea - I've tried to swizzle things around to get something approaching what
we already have. Its not been straightforward, but I think with some
creative naming, we can get there.
Btw - regarding the Client Roles: I don't think you can't add one to a Role
Policy in Clients > ${client} > Authorization > Policies > Add Role Policy.
Only Realm Roles show up in the search/drop down for Roles.
We are changing the role policy to include client roles :)
Regarding your use case, there is nothing similar to PL Tiers in Keycloak. Not 100% sure,
but I think you would be able to do that with role namespaces. @Stian can give you more
details about that feature.
About protected resources, they are really related with a client application. If I got
your design correctly, you probably have a single application serving different companies.
In this case, if each tenant has its own set of projects you are able to define policies
for each of these projects. Where you may have resources with a type (typed resources)
that is specific for a company and apply policies specific for the projects in that
company.
Your use case looks very interesting and made me think about some improvements to
authorization services. We could create a concept of resource groups and group hierarchy
(something already mentioned by Juca from Hawkular).
Regards.
Pedro Igor
Thanks, Keith
On Wed, Jul 20, 2016 at 4:23 PM Bill Burke < bburke(a)redhat.com > wrote:
Keycloak was written as an authentication server. Its initial authorization
features were quite limited to role-based apps.
One realm manages a set of users, roles, groups,and clients (applications).
There is a realm-level namespace for roles. Each client has a role
namespace. Groups can be managed in a hierarchy and associated with roles.
Groups can have their own role mappings and attributes. Users can join
groups. Users can be assigned roles.
Keycloak 2.0 has an Authorization feature where you can define Resources and
access policies based on those resources. Companies could each be a group.
Then I think you can say things like "If user belong to group A and role B
he can access resource C".
Meh, doesn't really map well to your use case. What we've found is that
everybody has their own structure that is very different or slightly
different than anyone else.
On 7/20/16 3:44 PM, Keith Dev wrote:
Consider an independent contractor (user) that works for two companies
(tenant) on different projects (resource). Control of the project belongs to
the company, not the contractor, so the security artifacts (resources,
groups, roles) belong with the company. But we want to provide a user
interface to the contractor where they do not have to manage multiple
accounts.
Tiers in picketlink allow for each tenant to have their own set of groups and
roles (though they have duplicate meanings for each).
I'm open to any solutions, including revisiting one realm per tenant (though
I have some concerns about whether or not keycloak is meant to support 1k+
realms).
Is that sufficient explanation?
Thanks, Keith
On Wed, Jul 20, 2016 at 2:18 PM Bill Burke < bburke(a)redhat.com > wrote:
Define "tenant" and what it accomplishes and how you are using tiers to
implement this functionality and I might be able to help.
On 7/20/16 2:41 PM, Keith Dev wrote:
I'm moving a web application with REST services from Picketlink to Keycloak.
This is a multi-tentant application (1k+ tenants) where single user accounts
can belong to multiple tenants. In Picketlink, this was accomplished using
Tiers. So there is a single realm, but one Tier per tenant. Its not clear
what the analog is in Keycloak.
We considered multiple realms, but both the number of tenants and the hard
requirement to allow a single user cross tenants seems to make this a
nonstarter.
The best idea we have so far is to have a single realm, but create namespaced
security artifacts: e.g. Tenant1.Admins. This is not ideal as we were hoping
for more separation between tenants. I did see this which suggests that
Picketlink Tiers equate to Resources, but its not clear how. Certainly there
does not seem to be any separation of security artifacts within a Resource
per se.
Advice?
_______________________________________________
keycloak-user mailing list keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
3461
days inactive
3461
days old
5 comments
3 participants
participants (3)
-
Bill Burke -
Keith Dev -
Pedro Igor Silva