[keycloak-user] Organization Based Accounts and Permissions
Pedro Igor Silva
psilva at redhat.com
Fri Aug 19 10:39:43 EDT 2016
As you said, you can solve that using employee type specific scopes. But yes, that would increase your scope list.
I think you can achieve what you want by having a scope permission "Manage Employee Permission" for both add and edit scopes. For instance, a permission that apply two policies that must be satisfied:
* Only Consultant Policy (Role-based mapping to Consultant type)
* Not "Temp" Policy (Robe-based mapping to Temp type with "Logic" == "Negative")
In theory, when evaluating the permission KC should give you a DENY for those scopes if you have both "Consultant" and "Temp" roles. If you have "Consultant" only, you can do everything. If you have only "Temp" you get a DENY as well.
I've created three users (roles as client roles):
- User A with Consultant role
- User B with Temp role
- User C with both Consultant and Temp roles
I've attached an example based on what I understood from your description. There are other ways to achieve that too, but for now let's start with that. I'm using upstream version.
----- Original Message -----
From: "Ushanas Shastri" <ushanas.shastri at viteos.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "Charles Henck" <cjhenck at live.com>, keycloak-user at lists.jboss.org
Sent: Friday, August 19, 2016 11:11:15 AM
Subject: RE: [keycloak-user] Organization Based Accounts and Permissions
Classification: INTERNAL
Hello,
I agree with the idea that one should not know what access mechanisms are used.
Let me explain my needs again, and maybe there's a way to model this in KC.
- One user has access to multiple actions for the same Resource, but depending on some property of the Resource, the actions can vary.
Resources All Actions possible on the Resource
Employee Add, View, Edit
Now there are multiple "Employee" , and one of the Employee properties is Employee Type. Now, I want to setup permissions that go as follows:
User A can Add, View and Edit Employee where Employee Type is "Consultant"
User A can only View Employee where Employee Type is "Temp"
It's clear what Resource and Scope should be, but what do we model for Employee Type? We thought of Groups, but that's at a realm level, and not at a client level, so ended up using Client Role, i.e. we created client roles for each Employee Type.
Maybe there's a better way, we could create scopes that were Consultant:Add instead of Add. This would increase the number of scopes, but the current structure would work for us.
Thank you for looking into this.
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 at viteos.com
-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com]
Sent: Friday, August 19, 2016 6:41 PM
To: Ushanas Shastri
Cc: Charles Henck; keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Organization Based Accounts and Permissions
----- Original Message -----
> From: "Ushanas Shastri" <ushanas.shastri at viteos.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Charles Henck" <cjhenck at live.com>, keycloak-user at 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 at viteos.com
>
> -----Original Message-----
> From: Pedro Igor Silva [mailto:psilva at redhat.com]
> Sent: Thursday, August 18, 2016 5:55 PM
> To: Ushanas Shastri
> Cc: Charles Henck; keycloak-user at 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 at viteos.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Charles Henck" <cjhenck at live.com>, keycloak-user at 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 at viteos.com
>
> -----Original Message-----
> From: Pedro Igor Silva [mailto:psilva at redhat.com]
> Sent: Thursday, August 18, 2016 5:25 PM
> To: Ushanas Shastri
> Cc: Charles Henck; keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] Organization Based Accounts and
> Permissions
>
> ----- Original Message -----
> > From: "Ushanas Shastri" <ushanas.shastri at viteos.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>, "Charles Henck"
> > <cjhenck at live.com>
> > Cc: keycloak-user at 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
>
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: employee-authz-service.json
Type: application/json
Size: 1796 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160819/072e9729/attachment.bin
More information about the keycloak-user
mailing list