[keycloak-user] Picketlink -> Keycloak

[Keith Dev]

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 at 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 at 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 at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160720/c2a7a0e8/attachment-0001.html