[keycloak-user] Organization Based Accounts and Permissions
Pedro Igor Silva
psilva at redhat.com
Fri Aug 19 09:11:09 EDT 2016
----- 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
>
More information about the keycloak-user
mailing list