Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of min.chen@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Min Chen <min.chen@citrix.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Subject: Re: my two cents on RBAC/authorization
Thread-Topic: my two cents on RBAC/authorization
Thread-Index: AQHOvMc2noghxNwG1UiICLfhXN7MsZndE99WgAC/NYCAAAMQgP//lI8A
Date: Mon, 30 Sep 2013 00:15:13 +0000
Message-ID: <CE6E0A01.4AC9E%min.chen@citrix.com>
In-Reply-To: <A21B3A58-4437-4D61-9626-ACD7E120F2A4@gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.6.130613
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EFA15DA99FA8C843B39945FBEBBF33F4@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

>
>
>
>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.shepherd@gmail.com> wrote:
>>=20
>> 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
>>=20
>> Darren
>>=20
>>> On Sep 29, 2013, at 12:04 PM, Min Chen <min.chen@citrix.com> wrote:
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Thanks
>>> -min
>>>=20
>>> Sent from my iPhone
>>>=20
>>>> On Sep 28, 2013, at 8:51 PM, "Darren Shepherd"
>>>><darren.s.shepherd@gmail.com> wrote:
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> Darren