Commands.properties will stay as it is for now, acl_api_permission will be auto-populated based on this commands.properties file. So developers do not need to update the DB when they add a new api.
-min On 9/29/13 6:10 PM, "Darren Shepherd" <darren.s.sheph...@gmail.com> wrote: >So this will replace the commands.properties. If one adds a new api, >will they need to update the DB? > >Darren > >On Sep 29, 2013, at 5:15 PM, Min Chen <min.c...@citrix.com> wrote: > >>> >>> >>> >>> One random question, I'm interested in knowing what the relationship >>> between commands.props and this new rbac thing will be. >> >> We have categorized two types of permission, one is API level permission >> to work with current ApiChecker (what kind of APIs are allowed to be >> accessed by a particular role), the other is entity level permission >>(what >> access type we want to grant to a group on a particular entity >>instance). >> Previous commands.properties will be stored in acl_api_permission table >>to >> indicate what APIs can be accessed by a particular role. Out-of-box, we >> have Admin, DomainAdmin, and User roles to match with current >>Account_type. >> >> Thanks >> -min >> >> >>> >>> Darren >>> >>>> On Sep 29, 2013, at 4:28 PM, Darren Shepherd >>>> <darren.s.sheph...@gmail.com> wrote: >>>> >>>> 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 >>
