Re: [keycloak-user] Picketlink -> Keycloak

From: "Keith Dev" <keith.dev(a)pobox.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt;, 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.

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