RE: my two cents on RBAC/authorization

[Prachi Damle <Pr...@citrix.com>]

Darren,

Thanks for the feedback and agreed that to make the RBAC solution pluggable, we would need to model it using standard authorization entities. As Min mentioned, this branch is to experiment how closely we can add a true RBAC model to current CloudStack code having account-domain hierarchy and static roles and gauge the effort. 

>From IAM docs and your explanation, Policy is a set of permissions and if it is not passed on then we assume one internally to process the authorization - hopefully we can add that layer later as well, on top of the first phase we are prototyping that focusses on defining Permissions for CloudStack and stores them directly to Db to facilitate read operations.

-Prachi

-----Original Message-----
From: Min Chen [mailto:min.chen@citrix.com] 
Sent: Sunday, September 29, 2013 12:04 PM
To: <de...@cloudstack.apache.org>
Cc: dev@cloudstack.apache.org
Subject: Re: my two cents on RBAC/authorization

RBAC branch was created by Prachi and me to do some quick prototype on rbac feature we are going to propose in the community soon. Since it is not ready yet, we haven't proposed and published FS on the ML.

In this prototype, we have group, accout, role, permission as our first class object. Unlike Amazon, cloudstack ACL is mainly done at Account level, so our Group will be a collection of accounts instead of users. Different from Darren suggested here, we didn't extract a separate Policy object to        
Group several permissions to a policy, because we didn't see a big benefit to store collections of permissions as a Json policy object compared to storing each individual permission into a permission table. Another reason why we store individual permission in db table is to facilitate implementing row-level permission filter for list Apis, where we have created DB views to determine entities to be returned. With a separate permission table, we can potentially join that table in db view for row filtering in read operation. In terms of integrating with third-party RBAC system, I don't see a big difference between re-creating policy object using cloudstack defined Json format and asking them to define those permissions through cloudstack provided permission grant Apis.

Thanks
-min

Sent from my iPhone

On Sep 28, 2013, at 8:51 PM, "Darren Shepherd" <da...@gmail.com> wrote:

> I've noticed there's a rbac branch and things are being committed 
> there.  I didn't see any documentation about the design or anything 
> (maybe it exists and I looked in the wrong place), so I'm just going 
> to give you my two cents on authorization systems.  Hopefully this 
> falls in line with what is being implemented, if not, at least we'll 
> avoid the awkward conversation when its finish when I say the code is 
> marginally useful and should be rewritten.
> 
> When talking about authorization there's a bunch of terms like 
> principal, permission, subject, action, policy, etc.  I want to focus 
> on policy.  Policy is central to an authorization system.  The policy 
> is the collection of permissions that grant or deny access to some 
> resource or action for a given subject.  RBAC is a really just a means 
> to generate a policy.  Once you know the user, group, roles, and the 
> permissions of those entities that aggregation of information forms 
> the policy.  You then take that policy and use it determine if the 
> given resource/action is granted/denied to a particular subject.
> 
> It is really important that policy is a first class object in an 
> authorization system.  This is important to understand because usually 
> in a big fat enterprise-y company, they really want you to enforce the 
> policy, but not necessarily maintain it.  For example, you'll go to 
> your fortune 500 company and they'll tell you they need RBAC.  So you 
> go and create an RBAC system.  The problem is that the fortune 500 
> company probably already has a RBAC system, and its probably AD based.
> So when they said they need RBAC, the really meant you need to enforce 
> RBAC.  If you implemented RBAC -> Policy -> Authorization, your good, 
> if you implemented RBAC - > Authorization, your kinda screwed. Now you 
> need to create a system to sync the two RBACs.  And keeping data in 
> two places and trying to sync them is never a good idea.  Now if you 
> implemented your system as having a policy as a first class object, 
> you can just swap your RBAC for theirs and all is still swell.
> 
> So if I was to implement this, this is how I'd do it.  (And if this 
> sounds a lot like IAM, its because it is.  If Amazon got anything 
> right, it's IAM).  The authenticator should be able to implement 
> another interface that allows it to supply a Policy object during 
> authentication.  This is logical in that the authentication systems 
> quite often hold authorization information too.  If the authenticator 
> doesn't implement the interface we fall back to generating the policy 
> ourself.  The policy is then consulted to see if the API command and 
> the resulting entities are granted/denied.  So far none of this has 
> anything to do with RBAC.  So the RBAC is implemented in that default 
> fallback implemenation that generates the policy.  You map the current 
> user/account to groups and roles and get the policies of those 
> entities to construct the policy.
> 
> Now for storing the policies I wouldn't do it in a traditional 
> normalized form.  All you need is tables for user/group/role and the 
> mappings for each.  The for user, group, and role you can specify a 
> policy JSON blob and that gets stored in the database as a mediumtext 
> field on the user/group/role row.  From an API perspective (just like 
> IAM), you just let people upload the JSON blobs for each.
> 
> So if we do it this way, we can have our own simple RBAC but then be 
> able to plug into far more complex and powerful authorization systems.
> Hopefully that all made sense.
> 
> Darren