<div dir="ltr">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.<div><br></div><div>Btw - regarding the Client Roles: I don't think you can't add one to a Role Policy in Clients > <span style="line-height:1.5">${client} > </span><span style="line-height:1.5">Authorization > </span><span style="line-height:1.5">Policies > </span><span style="line-height:1.5">Add Role Policy. Only Realm Roles show up in the search/drop down for Roles.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Thanks, Keith<br></span><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 20, 2016 at 4:23 PM Bill Burke <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Keycloak was written as an authentication server. Its initial
authorization features were quite limited to role-based apps.<br>
<br>
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.<br>
<br>
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".<br>
<br>
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.</div><div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<div>On 7/20/16 3:44 PM, Keith Dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>Tiers in picketlink allow for each tenant to have their own
set of groups and roles (though they have duplicate meanings
for each).</div>
<div><br>
</div>
<div>I'm open to any solutions, including revisiting one realm
per tenant (though I have some <a href="https://issues.jboss.org/browse/KEYCLOAK-3067" target="_blank">concerns</a> about
whether or not keycloak is meant to support 1k+ realms).</div>
<div><br>
</div>
<div>Is that sufficient explanation?</div>
<div><br>
</div>
<div>Thanks, Keith<br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Jul 20, 2016 at 2:18 PM Bill Burke
<<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Define "tenant" and what it accomplishes and how you
are using tiers to implement this functionality and I
might be able to help.<br>
</p>
</div>
<div bgcolor="#FFFFFF" text="#000000"> <br>
<div>On 7/20/16 2:41 PM, Keith Dev wrote:<br>
</div>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>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.<br>
<div><br>
</div>
<div>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 <a href="http://lists.jboss.org/pipermail/keycloak-dev/2013-July/000116.html" target="_blank">this</a> 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.</div>
<div><br>
</div>
<div>Advice?</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<pre>_______________________________________________
keycloak-user mailing list
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div></blockquote></div></div></div>