I look forward to the proposal. Based on your short comments and the artifacts I've seen so, I'll warn you that I'll probably disagree strongly with the implement
Darren > On Sep 29, 2013, at 12:04 PM, Min Chen <min.c...@citrix.com> wrote: > > 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" <darren.s.sheph...@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
