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? 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: keycloak-user-bounces(a)lists.jboss.org [mailto:keycloak-user-bounces@lists.jboss.org] On Behalf Of Pedro Igor Silva Sent: Thursday, August 18, 2016 3:56 AM To: Charles Henck Cc: keycloak-user(a)lists.jboss.org Subject: Re: [keycloak-user] Organization Based Accounts and Permissions ----- Original Message ----- From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Charles Henck" <cjhenck(a)live.com&gt; Cc: keycloak-user(a)lists.jboss.org Sent: Wednesday, August 17, 2016 6:38:01 PM Subject: Re: [keycloak-user] Organization Based Accounts and Permissions ----- Original Message ----- If the organizations each represent a separated realm, you won't be able to share users. In Keycloak, an user belongs to a single realm. I think that with some creative naming for roles (and groups), you can get there. You can address these two by using our authorization services. Or even writing a plenty of "ifs" in your application based on the information carried by a token. I would suggest you to give a try to the authorization services :) For instance, let's say you have a "Organization A Resource". This resource is associated with a "Organization A Resource Permission". Here the "Organization A Resource" represents any resource in Organization A and "Organization A Resource Permission" represents all the policies you want to enforce to any resource that belongs to Organization A. In this case, you can apply different types of policies to these resources, for instance, only users with role "organization-a-role" are allowed. You may also have a "Charles Resource", which was created by your service using the Protection API. In this case, your service may specify that "Charles Resource" belongs to Charles (resource owner) and apply permissions/policies to this resource that define that only Charles is allowed to access. Going further, let's say that you want to give temporary access to your resource to someone. You may create a "Temporary Access Policy" that specifies which users (user-based policy) are allowed to access your resource. Another thing you can do is perform access decisions based on the actions that you can perform on your resource. Let's say that everybody can see your resource, but only the resource owner (you) can edit or delete it. I'm really thinking about pushing a new example application with a permission model similar to github, it will be fun :) _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user 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