Yes I agree we need them in KC. Was referring to more complex authz
scenarios and reqs.
On Tue, Aug 4, 2015 at 2:59 PM, Bill Burke <bburke(a)redhat.com> wrote:
We still want to have some concept of groups. I think I'm coming
to some
sort of design for them which I'll post soon.
On 8/4/2015 6:57 AM, Boleslaw Dawidowicz wrote:
>
> +1. The more I think about it I lean towards having something
> separate. Another component/server to handle more reach robust
> authorisation needs while being tightly integrated with authentication
> server.
>
> It is a pandora box and when you start collecting requirements you
> quickly reach permissions, inheritance or dynamic rule based
> resolution. Would have high impact on usability and simplicity.
>
> On Wed, Jul 29, 2015 at 9:05 AM, Stian Thorgersen <stian(a)redhat.com>
> wrote:
>>
>> Agree, Keycloak (as an authentication server) should be limited to
>> providing roles (and other claims/attributes, maybe we can groups and even
>> roles within groups).
>>
>> We could look at adding something more of an authorization server (UMA)
>> where a resource provider uses the users token to contact the authorization
>> server to check if a user has a specific permission on a specific resources.
>> It's an interesting challenge and maybe something we can look at in the
>> future, but I think it's going to be mid-end 2016 at least.
>>
>> ----- Original Message -----
>>>
>>> From: "Bill Burke" <bburke(a)redhat.com>
>>> To: keycloak-dev(a)lists.jboss.org
>>> Sent: Tuesday, 28 July, 2015 6:08:05 PM
>>> Subject: Re: [keycloak-dev] Hawkular requirements (was Re: RFC:
>>> organizations)
>>>
>>> I think it is appropriate to model resource access separately, outside
>>> of Keycloak. The reason for this is basically how SAML/OIDC and single
>>> sign in works. It should be:
>>>
>>> 1. User visits Hawkular
>>> 2. User is redirected to Keycloak to login
>>> 3. User logins in
>>> 4. User is redirected back to Hawkular with a set of assertions
>>>
>>> If you were using Keycloak to model resource access, then Hawkular would
>>> have to continuously hit Keycloak in the background to
>>>
>>> * create/destroy/modify resource definitions
>>> * enable/disable permissions of the user for each resource
>>> * verify permissions of the user for each resource
>>>
>>> I just don't think an authentication server should be used to manage
>>> application data. Would you require that a company's LDAP store start
>>> storing Hawkular specific metadata to manage all these resources? No.
>>> You would not. Which is why I think Keycloak should only be storing
>>> things like does this user belong to this group or organization. That's
>>> it. Keycloak should not be managing access to the resources of a
>>> specific application.
>>>
>>> On 7/28/2015 9:57 AM, Juraci Paixão Kröhling wrote:
>>>>
>>>> Sure. Please, keep in mind that we have two possible deployment
>>>> scenarios: SaaS and Hosted.
>>>>
>>>> For SaaS (and some specific customers on Hosted), we need to have multi
>>>> tenancy, so, data from one "organization" should be isolated
from
>>>> another. At the same time, we need users from one organization to
>>>> possibly have access to data from other organizations.
>>>>
>>>> Note that we use the same role names and semantics as Wildfly:
>>>>
https://docs.jboss.org/author/display/WFLY9/RBAC
>>>>
>>>> Case #1, simplest possible scenario:
>>>> - a new user registers on Hawkular SaaS and wants to monitor a website.
>>>> No one else should have access to the metrics collected for this user.
>>>>
>>>> Case #2, most complex scenario:
>>>> - Acme, Inc has several departments: Marketing, Sales and so on. Each
>>>> one has a small operations team, which is responsible for their
>>>> day-to-day activities (creating a database, adding an application
>>>> server, deploying an application, increasing memory, ...).
>>>> - A member of the Marketing department should not be able to
>>>> view/manage
>>>> resources from, say, Sales.
>>>> - Acme, Inc has a NOC, which is responsible for the 24x7 monitoring.
>>>> They should have read-only access to metrics from all machines of Acme,
>>>> Inc, no matter which department.
>>>>
>>>>
>>>> We are currently solving this by having "Hawkular Accounts" to
sit
>>>> between Keycloak and the Hawkular modules (Alerts, Metrics, Inventory,
>>>> ...) and providing a "Current Persona". This
"persona" is a
>>>> representation of the tenant + the rights that the user has for this
>>>> tenant. So, the Persona might be an User acting as Monitor on an
>>>> Organization, or might be an User acting on its own Resources as
>>>> SuperUser. Permission checking is performed on the business side by the
>>>> modules, by calling an API which is similar to PicketLink's
Permission
>>>> API.
>>>>
>>>> So, we have the following concepts on Hawkular Accounts:
>>>>
>>>> - Organization
>>>> - "Acme, Inc"
>>>>
>>>> - Roles
>>>> - SuperUser
>>>> - Monitor
>>>> - Auditor
>>>> - ...
>>>>
>>>> - User
>>>> - "jmuller"
>>>>
>>>> - Persona
>>>> - "jmuller"
>>>> - "jmuller" acting as "SuperUser" of "Acme,
Inc"
>>>>
>>>> - Resource
>>>> - "virtual-machine-1"
>>>> - "travel-request-webapp"
>>>>
>>>> - Operation
>>>> - "add-memory"
>>>> - "monitor-cpu"
>>>> - "deploy-war"
>>>> - "read-datasources"
>>>>
>>>> - Permission
>>>> - "SuperUser" can "add-memory" to
"virtual-machine-1"
>>>>
>>>> - Organization membership
>>>> - "jmuller" is "SuperUser" on "Acme,
Inc"
>>>> - "Acme, Inc" is "SuperUser" on "Acme
Sales"
>>>> - "Acme NOC" is "Monitor" on "Acme,
Inc"
>>>>
>>>>
>>>> On the simplest case (case 1):
>>>> - User is Persona. So, when the user registers and adds the website to
>>>> be monitored, the website is owned by the user (ie: SuperUser of
>>>> Resource is User).
>>>>
>>>> On the complex case (case 2):
>>>> - User jmuller registers and creates the organization "Acme,
Inc" and
>>>> is, therefore, the SuperUser of it.
>>>> - User jmuller switches the context to "Acme, Inc" on the UI
>>>> - Acme Sales is created as an Organization inside Acme, Inc (Acme, Inc
>>>> owns it)
>>>> - Acme Marketing is created as an Organization inside Acme, Inc (ditto)
>>>> - Acme NOC is created as an Organization inside Acme, Inc (ditto)
>>>> - User jmuller invites jdoe to be SuperUser of Acme Sales
>>>> - User jdoe switches the context to "Acme Sales" on the UI
>>>> - Acme Sales (via jdoe) creates the host "acme-sales-prod-1"
and is the
>>>> SuperUser of it.
>>>> - As jdoe is a SuperUser member of Acme Sales, jdoe is therefore
>>>> SuperUser of "acme-sales-prod-1"
>>>> - User jmuller invites jsmith to be SuperUser of Acme NOC
>>>> - Organization Acme NOC is granted Monitor on Acme, Inc
>>>> - As jsmith is a SuperUser of NOC, but as NOC is only Monitor on Acme,
>>>> Inc, then jsmith is also only Monitor on Acme Sales.
>>>> - User jmuller is SuperUser on "Acme, Inc", so, is also a
SuperUser of
>>>> "Acme Sales", "Acme Marketing", "Acme
NOC".
>>>> - User jim creates "Red Hat, Inc", which has no access to Acme,
Inc
>>>> data.
>>>>
>>>> When the user jsmith (SuperUser of NOC) selects "Acme Sales" on
the
>>>> Hawkular Accounts switcher, an HTTP header is sent with the request,
>>>> with the ID of the "Acme Sales" as the Persona-ID. When an
operation
>>>> needs to be done in a resource that is owned by Acme Sales, the
>>>> relevant
>>>> Hawkular module asks Hawkular Accounts whether the current persona can
>>>> perform the Operation on the Resource. On this case, jsmith is only
>>>> Monitor on Acme Sales, so, if it's a read only operation, the
>>>> permission
>>>> is granted.
>>>>
>>>> I realize that there are terms which are specific to Hawkular, but I
>>>> tried to make it as clear as possible for those who have no knowledge
>>>> of
>>>> those terms. In case something is not clear, let me know.
>>>>
>>>> - Juca.
>>>>
>>>>
>>>> On 07/28/2015 02:19 PM, Stian Thorgersen wrote:
>>>>>
>>>>> I think we've successfully managed to abstract ourselves
completely
>>>>> away
>>>>> from your real requirements ;)
>>>>>
>>>>> Can you start another thread listing your exact requirements? Then
we
>>>>> can
>>>>> see if it's possible to model it with existing roles, client
roles and
>>>>> composite roles.
>>>>>
>>>>> ----- Original Message -----
>>>>>>
>>>>>> From: "Juraci Paixão Kröhling"
<jpkroehling(a)redhat.com>
>>>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>>>> Cc: keycloak-dev(a)lists.jboss.org
>>>>>> Sent: Tuesday, 28 July, 2015 11:09:04 AM
>>>>>> Subject: Re: [keycloak-dev] RFC: organizations
>>>>>>
>>>>>> On 07/28/2015 10:31 AM, Stian Thorgersen wrote:
>>>>>>>
>>>>>>> I'll add a bit to this example:
>>>>>>>
>>>>>>> Within a realm there's 4 services (bearer-only clients):
>>>>>>>
>>>>>>> * Acme Email Service
>>>>>>> * Acme Monitor Service
>>>>>>> * Red Hat Email Service
>>>>>>> * Red Hat Monitor Service
>>>>>>
>>>>>>
>>>>>> Is there a way to have a relationship between Acme Email Service
and
>>>>>> Acme Monitor Service? Are they different clients? We'd need a
stable
>>>>>> ID
>>>>>> between related services, which would be our "tenant".
So, if user
>>>>>> jdoe
>>>>>> creates a resource in our application while acting as SuperUser
for
>>>>>> Acme, we have to store this resource with the information that
it
>>>>>> belongs to Acme, so that users of Red Hat wouldn't have
access to it.
>>>>>>
>>>>>>> Each client has one or more roles. For example Acme Email and
Red
>>>>>>> Hat
>>>>>>> email
>>>>>>> both have view-email, read-email and send-email.
>>>>>>>
>>>>>>> To model the above super users you'd add two composite
realm roles:
>>>>>>>
>>>>>>> * acme-super - add mapping on all roles for Acme Email and
Acme
>>>>>>> Monitor
>>>>>>> * redhat-super - add mapping on all roles for Red Hat Email
and Red
>>>>>>> Hat
>>>>>>> Monitor
>>>>>>
>>>>>>
>>>>>> Meaning that for each new "organization", a new set of
roles would
>>>>>> have
>>>>>> to be duplicated. Basically, acme-super and redhat-super are
exactly
>>>>>> the
>>>>>> same, except for the names.
>>>>>>
>>>>>> But if I get it right, this is how it would look like:
>>>>>>
>>>>>> - user jdoe registers, is "super" on the realm itself
>>>>>> - user jdoe creates Acme, and is acme-super there, effectively
being
>>>>>> super on the client
>>>>>> - user jsmith creates Red Hat, invites jdoe as
"monitor" there
>>>>>> - user jdoe is now super on the realm, acme-super on the Acme
client
>>>>>> and
>>>>>> redhat-monitor on the Red Hat client.
>>>>>>
>>>>>> So, if a request comes in to our backend for jdoe while using the
UI
>>>>>> as
>>>>>> Red Hat, our backend would see only "redhat-monitor" as
the role,
>>>>>> right?
>>>>>>
>>>>>>> A user can now have a role mapping on acme-super to get all
roles
>>>>>>> for
>>>>>>> Acme
>>>>>>> clients, or you can add role mappings to individual roles
within
>>>>>>> each
>>>>>>> client.
>>>>>>
>>>>>>
>>>>>> This means that I would be able to be Super User on Acme, but
only
>>>>>> Monitor on Red Hat, right?
>>>>>>
>>>>>>> That's what you want isn't it?
>>>>>>
>>>>>>
>>>>>> I think it could work, yes, but that doesn't feel right, to
be
>>>>>> honest.
>>>>>> It seems like we'd be doing some workarounds to implement a
concept
>>>>>> that
>>>>>> doesn't quite exist on Keycloak, which would cause a massive
data
>>>>>> duplication. For one realm containing two clients and 8 roles
each,
>>>>>> this
>>>>>> seems doable, but for one realm containing 2.000 clients (nested
or
>>>>>> not)
>>>>>> and 8 roles each, that *sounds* like a
>>>>>> maintenance/migration/performance
>>>>>> nightmare.
>>>>>>
>>>>>>> Further you can also utilize scope on applications
(confidential for
>>>>>>> server-side web app, or public for client-side web apps) to
limit
>>>>>>> the
>>>>>>> roles a application can obtain. For example the HTML5
application
>>>>>>> 'Acme
>>>>>>> Email Reader' could either have a scope on all roles
within 'Acme
>>>>>>> Email
>>>>>>> Service' or 'acme-super'. It should probably not
have scope on any
>>>>>>> roles
>>>>>>> for 'Red Hat Email'.
>>>>>>
>>>>>>
>>>>>> Sounds like a bonus feature, but I don't think this would
bring any
>>>>>> benefit for us. We have only one frontend and one backend (with
>>>>>> several
>>>>>> modules). So, the same application available to Acme is available
to
>>>>>> Red
>>>>>> Hat.
>>>>>>
>>>>>> - Juca.
>>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>>
http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>>
https://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
>
>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com