From: "Ushanas Shastri" <ushanas.shastri(a)viteos.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: "Charles Henck" <cjhenck(a)live.com>, keycloak-user(a)lists.jboss.org
Sent: Friday, August 19, 2016 9:59:47 AM
Subject: RE: [keycloak-user] Organization Based Accounts and Permissions
Classification: INTERNAL
Hello,
The requirement is that users can access either, neither or both, completely
based on what their client role is.
User A is mapped to Client Role 1 and Client Role 2
For Client Role 1, User A has some permissions, but for Client Role 2, the
permissions are different. So, we've created one permission for each
resource/scope combination, and have created policies based on client role,
and then we attach the user to the client role. All of this works perfectly,
it's just that the entitlement API response is correct, but not ideal.
That is what I want to take a closer look. In theory, you don't need to know about the
roles that granted access to a permission. The idea is the opposite, your application
should not be aware about the access control mechanisms that were used. Instead, you
should just rely on the resource/scopes that were granted, so you can manage
permissions/policies as you want and avoid coupling.
Please, give me some time to try out your config. Will try to look at it today.
Thanks.
I would want the response JSON authorization to state that for a given
resource and scope is allowed for a set of client roles.
The authorization settings are attached. I was unable to export the realm
config (through the export feature on the command line).
Regards, Ushanas.
Viteos Fund Services Ltd |
www.viteos.com
Direct : +91-22-61082230 | US : +1- 888-821-7561 extn 240
Cell : +91-9820225580
Email : ushanas.shastri(a)viteos.com
-----Original Message-----
From: Pedro Igor Silva [mailto:psilva@redhat.com]
Sent: Thursday, August 18, 2016 5:55 PM
To: Ushanas Shastri
Cc: Charles Henck; keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] Organization Based Accounts and Permissions
Can you attach export your authorization settings ? Would like to understand
better what you are doing. The realm config would also help.
Also, your requirement is that an user can only access one resource or
another, but never both ?
----- Original Message -----
From: "Ushanas Shastri" <ushanas.shastri(a)viteos.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: "Charles Henck" <cjhenck(a)live.com>, keycloak-user(a)lists.jboss.org
Sent: Thursday, August 18, 2016 9:05:00 AM
Subject: RE: [keycloak-user] Organization Based Accounts and Permissions
Classification: INTERNAL
Thank you!
I have looked at both examples, and we tried to create resources as being
types.
Where we're stuck is that we need one additional parameterized context, which
we thought we'd achieve by creating client roles.
So, the idea is that scope based permissions apply for a given client role.
There are no issues setting this up in KC, but the Entitlement API returns
a representation that does not combine resource, scopes *and* client roles.
It combines resources and scopes, but client roles are a separate list.
The JSON (a part of it) looks like this
"resource_access": {
"servlet-authz-app": {
"roles": [
"Setup1",
"Setup2"
]
}
},
"authorization": {
"permissions": [
{
"scopes": [
"view"
],
"resource_set_id": "35750d56-d32a-4106-8b63-882e998ec545",
"resource_set_name": "Account Setup"
},
{
"scopes": [
"view"
],
"resource_set_id": "11389916-6cac-41af-95f1-8409019a84b3",
"resource_set_name": "Investor Setup"
}
]
}
The way its setup, is that this user can do view scope for resource "Account
Setup" for only client role "Setup1", and cannot do scope view for
resource
"Account Setup" for client role "Setup2".
If the authorization property put relevant client roles inside permissions,
it would do everything we needed.
Regards, Ushanas.
Viteos Fund Services Ltd |
www.viteos.com Direct : +91-22-61082230 | US : +1-
888-821-7561 extn 240 Cell : +91-9820225580 Email :
ushanas.shastri(a)viteos.com
-----Original Message-----
From: Pedro Igor Silva [mailto:psilva@redhat.com]
Sent: Thursday, August 18, 2016 5:25 PM
To: Ushanas Shastri
Cc: Charles Henck; keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] Organization Based Accounts and Permissions
----- Original Message -----
> From: "Ushanas Shastri" <ushanas.shastri(a)viteos.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>, "Charles
Henck"
> <cjhenck(a)live.com>
> Cc: keycloak-user(a)lists.jboss.org
> Sent: Thursday, August 18, 2016 4:13:18 AM
> Subject: RE: [keycloak-user] Organization Based Accounts and
> Permissions
>
> Classification: INTERNAL
> Hello,
>
> I don’t mean to hijack this thread, but I've had similar requirements,
> and would love some advice.
>
> Do you create Resources based on Features (menus in an application) or
> based on actual data. For e.g. if Bank Account Maintenance is a
> feature that allows you to create/update bank account information, do
> you create a Resource in KC for each bank account in the system, and
> then give permissions/policies on it, or do you create one Bank
> Account resource as indicative of the type Bank Account?
>
The idea is that you can do both: feature and/or resource.
That is the reason behind our Protection API (based on UMA spec). It provides
an API that allows client applications acting as a resource server (your
service) to create "resources instances" whose owner could be an user. But
nothing stops you to still have a typed resource (eg.: type Bank Account)
and apply general permissions/policies to it. Take a look at that
"authz/photoz" example application, there we try to demonstrate that. There
you have a general purpose "Album Resource" and every time an user creates a
new album it is also created a corresponding resource in the server. In this
case, the new resource is going to inherit the permissions applied to the
"Album Resource".
For the feature-based resource scenario, you may take a look to
"authz/servlet-authz-app". There we try to demonstrate how you can protect
resources and actions/scopes in order to build, for instance, a dynamic menu
with the permissions granted by the server.
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or
privilege is waived or lost by any mis-transmission. If you receive this
message in error, please immediately delete it and all copies of it from
your system, destroy any hard copies of it and notify the sender. You must
not, directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. Viteos Capital
Market Services Ltd.and any of its subsidiaries each reserve the right to
monitor all e-mail communications through its networks. Any views expressed
in this message are those of the individual sender, except where the message
states otherwise and the sender is authorized to state them to be the views
of any such entity
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or
privilege is waived or lost by any mis-transmission. If you receive this
message in error, please immediately delete it and all copies of it from
your system, destroy any hard copies of it and notify the sender. You must
not, directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient. Viteos Capital
Market Services Ltd.and any of its subsidiaries each reserve the right to
monitor all e-mail communications through its networks. Any views expressed
in this message are those of the individual sender, except where the message
states otherwise and the sender is authorized to state them to be the views
of any such entity