[keycloak-user] Organization Based Accounts and Permissions

Justin Henck cjhenck at live.com
Thu Aug 18 17:15:56 EDT 2016


Hi Pedro,
Thanks for the suggestions, this is great.  Out of curiosity, are we able to make Groups or Roles the owners of resources?  I couldn’t find much documentation on the “owner” function within the gitbooks at the moment.

Thanks,
Justin

On 8/17/16, 6:25 PM, "Pedro Igor Silva" <psilva at redhat.com> wrote:

    ----- Original Message -----
    From: "Pedro Igor Silva" <psilva at redhat.com>
    To: "Charles Henck" <cjhenck at live.com>
    Cc: keycloak-user at lists.jboss.org
    Sent: Wednesday, August 17, 2016 6:38:01 PM
    Subject: Re: [keycloak-user] Organization Based Accounts and Permissions
    
    ----- Original Message -----
    > From: "Charles Henck" <cjhenck at live.com>
    > To: keycloak-user at lists.jboss.org
    > Sent: Tuesday, August 16, 2016 4:49:01 PM
    > Subject: [keycloak-user] Organization Based Accounts and Permissions
    > 
    > 
    > 
    > Hello all,
    > 
    > I’m working on an organization-based service and want to have
    > resource-specific permissions that are restricted by (from a user
    > perspective) organization-specific roles. Since I’m not familiar with the
    > specific terminology, I’m thinking of something similar to how GitHub
    > manages their permissions:
    > 
    > 
    > 
    > - A single user can be a member of multiple organizations
    > 
    > - A user can have a different roles with different organizations that grant
    > them access to all of an organization's resources
    
    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.
    
    > 
    > - A user can have access to a specific resource
    > 
    > - That organization-specific role determines access to different organization
    > resources
    
    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 :)
    
    > 
    > 
    > 
    > Are there any best practices or patterns for this model?
    > 
    > 
    > 
    > Thanks!
    > 
    > Justin
    > 
    > _______________________________________________
    > keycloak-user mailing list
    > keycloak-user at lists.jboss.org
    > https://lists.jboss.org/mailman/listinfo/keycloak-user
    





More information about the keycloak-user mailing list